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

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

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

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 =

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"

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

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

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] =

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

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

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

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

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

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 finally have it all building on windows and can run the testshade program. I had to create some new OSL_DLLPUBLIC defines and place them around, OSLCOMP_DLLPUBLIC, OSLEXEC_DLLPUBLIC liboslcomp

Thanks, that was just the info I needed! A few libraries in macports were left overs from a Leopard universal binary build. I uninstalled a pile of libraries, working backwards from the link errors;

If someone wants to write a MacPorts Portfile for OIIO I can commit it. That should make building OSL that much easier. Regards, Blair Nick Porcino wrote:

Reviewers: osl-dev_googlegroups.com, Description: Several additional warnings and some new errors occur when trying to compile OSL using g++-4.4.1. Errors were due to: - header rearrangements which

You could do what Google Protocol Buffers does and determine which hash map to use at configure time. It works with g++ 3.4.x all the way up to 4.4.x. See the m4 file

hash map to 4.4.x. See IMHO this seems to be a bit of overkill, and my preferred option would be just to specify that >=boost-1.36 was necessary. However I know that may not be an option for