For me the biggest issue is the cost to maintain and support this, it adds a lot of visible and hidden code complexity.

This implements a small subset of OSL, and the parts that are missing are the most difficult to implement. And so the question is then how would this evolve? Would you leave it more or less at this subset, or would you actually target a full re-implementation of OSL in Cycles?

Because I'm just not sure if the limited developer time should be spent on doing that, handling bug fixes, documenting which subset works, keeping it updated as OSL evolves, having to keep this working when they want to bigger shading system changes, etc. It's almost adding a third shading system next to SVM and OSL, and having two is already problematic.

As I explained before, I think this is not the ideal way to add OSL support on the GPU. Performance will not be great because SVM really isn't optimized to be used to execute such granular instructions, and by compiling OSO straight to SVM it's missing all the smart OSL optimizations.

So I'm wondering where you see this going. Right now it provides an easier way for programmers to create certain procedural patterns on the GPU. But a lot of such clever procedurals tend to be nice demos but not used by much by artists in practice, and performance of these scripts could be quite poor. So I feel like for something like this to be worth the cost, it would need to move beyond that, and I'm not sure how that would happen.

In D1745#39286, @Brecht Van Lommel (brecht) wrote:

For me the biggest issue is the cost to maintain and support this, it adds a lot of visible and hidden code complexity.

This implements a small subset of OSL, and the parts that are missing are the most difficult to implement. And so the question is then how would this evolve? Would you leave it more or less at this subset, or would you actually target a full re-implementation of OSL in Cycles?

Because I'm just not sure if the limited developer time should be spent on doing that, handling bug fixes, documenting which subset works, keeping it updated as OSL evolves, having to keep this working when they want to bigger shading system changes, etc. It's almost adding a third shading system next to SVM and OSL, and having two is already problematic.

As I explained before, I think this is not the ideal way to add OSL support on the GPU. Performance will not be great because SVM really isn't optimized to be used to execute such granular instructions, and by compiling OSO straight to SVM it's missing all the smart OSL optimizations.

So I'm wondering where you see this going. Right now it provides an easier way for programmers to create certain procedural patterns on the GPU. But a lot of such clever procedurals tend to be nice demos but not used by much by artists in practice, and performance of these scripts could be quite poor. So I feel like for something like this to be worth the cost, it would need to move beyond that, and I'm not sure how that would happen.

This a proof of concept, I wondered if it could be done, and the answer as it stands is 'partially'. Where to go from here was really up to you guys and the reason why i posted this WIP patch. If you go 'nah we'll never accept this' i'll go on my merry way and do something else, if you go 'we could see this work, if you improve X & Y & Z' i'd happily work on that too.

Perf wise i'm not overly worried, sure osl does some nice tricks behind the scenes such as unrolling loops and some constant folding, (and i've seen some 'dead' instructions with no clear purpose in some oso's which llvm will most likely get rid of) but do feel that most of those optimizations are rather isa specific, (i contemplated compiling oso to ptx and trying to force feed that to cuda, but that path just contained too many unknowns to be comfortable with) I do suspect that most artists will use osl on specific elements in their scene, just to get some functionality regular nodes does not expose, and from what i can tell, the svm implementation is pretty much always faster than rendering the whole scene in OSL.

While it seems like a lot of 'hidden' code / third shading system, It's really just the oso->svm translation that is specific to this patch, every thing else is exposed in regular svm nodes, The pretty much doubling of math operations in the math node ? I'm fairly sure a regular nodes user could find a good use for them, more noise types? regular nodes users would *love* them. (I think there's actually a ticket somewhere for implementing the gabor noise in svm, doesn't look like someone picked it up yet though) So even if we don't go though with an osl script node for svm, I think parts of the patch are very usable for end users.

My biggest worry about maintaining this is chasing after osl releases to keep this up to date, unless the oso format gets formalized and documented by them, i have very little interest and making this patch 'officially supported' but it feel this is a discussion we should have with the osl people after we decide this is a direction we want to go in. (I'd hate for them to pour time into formalizing and documenting, only to go 'nah we decided not to do this')

I'd love a full implementation (minus the impossible bits like printf) and if that's hard, let it be hard! However given the time i already put in, I decided to get some feedback first to see if i am wasting my time here. So this is more of a 'Is this going to work for you guys?' than a 'here's a patch, it's your problem now!' kind of thing.

For the record: printf is quite doable for the compute model 2.0 and above, which covers all the officially supported platforms. But good luck supporting attributes query, ray tracing and such.. Feature complete OSL on SVM isn't really doable in the nice and fast-to-render way.

As for math node -- those operations are quite specific, never seen artists asking for such an operations actually.

Noise textures -- IMO we should on;y distribute reasonable set of textures really commonly used by artists, leaving all the rest cases to either node groups or OSL shaders. Surely one might raise a concern about OSL being slower than SVM, but that's the issue to be addressed.

this would be cool .. coding via scriptnode is kiss like for procedural-texture-fun ( i wish there could be cycles gpu-power and microdisplacement to :)