Yeah, I believe that's fixed in the patch. From what I can tell, the latest visual studio has a native unordered_map implementation, but my preference for boost is just because it's consistent across

Actually my error was strchr returning a char* instead of a const char*. osolex.l line# 260

I too recieved an error from strcmp in oslex.l/cpp when building with visual studio. Visual studio has not deprecated hash_map from what i can tell, but a boost solution would work there as well. Does

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

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

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

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:

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;

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

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 =