Fair enough. Vectorization does imply unrolling the loop (by a factor of 4 for SSE), though loop unrolling can sometimes be a useful optimization without hardware vectorization. The active index

I guess i was thinking of the vectorization being a type of unrolling, not really in the correct sense i guess. Where it was expanding it by say by 4 or how ever wide the vector operator is, reducing

No, the active index case isn't vectorized by the compiler anyway. No. In a SIMD shader machine I generally expect that creating the runstate representation (whatever it may be) from the results of

LGTM Having dev-osl@imagework usually works for me, but I don't see this mail. http://codereview.appspot.com/193063/show

I have been trying to get the shaders test to build but I have run into lots of issues with linking dependencies, exports imports etc. The projects cmake generates for example oslquery uses source

That's interesting, it kind of relates to my original question if the compiler was able to apply SIMD operations to the loop. When you disabled vectorization did it effect the active index case? Are

Right, here's the initialization code for some sparse on-states: // Four isolated flags turned on. std::fill((Runflag*)r, r+len, (Runflag)Runflag_Off); r[0] = r[50] = r[100] = r[150] =

LGTM http://codereview.appspot.com/186262/show

Reviewers: osl-dev_googlegroups.com, Description: We were missing the derivatives in the I field which is important for background shader. This little patch fixes the problem. Please review this at

I want to point out that Chris F tested out the "all on", "random on", and "alternating on/off" cases. There's one more case that may be important, which is a few isolated "on" points with big "off"

I like this idea too. What we were discussing yesterday was something like: index: [ 0 1 2 3 4 5 6 7 8 9 ] flags: [ 0 0 1 1 1 1 0 0 1 0 ] active_points: [ 2 3 4 5 8 ] for (int i =

As a uni student who is keen on the OSL open source release, I'm glad to be reading these discussions - particularly questions and answers. They're the source of knowledge, freely shared insights. It

Thanks, that makes sense. I know compilers are getting smarter all the time but wasn't sure if they were there yet. The cache and memory coherence makes sense, and then sorting things like that would

It's not really referring to hardware SIMD, but just that we are shading many points at once, "in lock-step." In other words, if you had many points to shade, you could do it in this order: point

Is there a good resource on this topic? I did some googling and didn't see what i was looking for. Where is the actual SIMD taking place? Is the compiler figuring it out from the loop and setting up

Awesome, Chris. Would you believe we were just talking internally about this topic yesterday? We were considering the amount of waste if there were big gaps of "off" points in the middle. But I

Hi all, I've been looking through the OSL source a little, and I'm interested to see that you're using runflags for the SIMD state. I know that's a really conventional solution, but there's an

Thanks so far for the answers, I'm looking forward to seeing OSL progress. Good stuff! Regards, Daniel

Er, I'm not sure. I think this is exactly the kind of thing we will be working out over the next few weeks. When we actually implemented surface integrators, we discovered all sorts of issues we

Meh, I just realized my ambiguous use of "integrator". In this case I meant "party integrating OSL into their system"... Regards, Daniel