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 =

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