OSL going forward...

[Friederich Munch]

I've been working on compiling OSL source with the clang libraries for a couple of benefits:

  More complete tooling:

    Using clang's AST rewriters one can go from OSL -> GLSL.

    Generation of native object code which can be debugged 

    GPU options to generate CUDA, OpenCL, and hopefully SPIR-V binaries.

  Adding C++ syntax:

    Swizzling.

    Initializer lists.

    Consolidated vector2/vector3/vector4 types.

    Methods calls for vector and struct types.

Besides the GPU/GLSL, ideally I'm trying for a library that could output

dynamic libraries with embedded LLVM-IR which could then be run without

the JIT or runtime optimized with it.

I've submitted a couple of patches that add the first three language

additions to OSL, but would like to get a sense of interest on the larger goals

above to help move forward. (Particularly in relation to the language additions:

if it's just better to do a separate implementation outright; keeping source

compatibility would then be dependent on whether the additions are wanted).

Thanks.

[Master Zap]

Ok, I'm very very interested, especially around the GPU/GLSL side of things. Please tell me more!

/Z

[Dan Kripac]

Hey Friederich,

I saw your PRs go into OSL, I'm definitely interested.

We are using OSL for our pattern generation for path tracing but we'd love to be able to push into realtime preview tools for tweaks to the pattern networks via the GPU.

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osl-dev+unsubscribe@googlegroups.com.
To post to this group, send email to osl...@googlegroups.com.
Visit this group at https://groups.google.com/group/osl-dev.
For more options, visit https://groups.google.com/d/optout.

[Larry Gritz]

There's a lot to unpack here. Let me just throw out a whole bunch of comments and see where it takes us.

(Aside: You use a few names. What do you want us to call you?)

First, please do clarify and elaborate! I know we'd all like to hear what you have in mind, at a couple more levels of detail deeper than you have gone. 

Take everything I say below with a grain of salt, I may be making assumptions about your approach that lead to concerns that are unwarranted and may not be problems when I understand more thoroughly what you have in mind.

I think lots of us are interested in the topics of Cuda, OpenCL, SPIR-V, GLSL, debuggable code.

Language-wise, I very much like the idea of adding initializer lists and struct methods. I'm lukewarm about swizzling but can live with it if the community has consensus that it would be good. We already recently (1.9) added vector2/vector4 implemented in OSL itself, and unless there's a real problem with that approach, I prefer the current style of implementation as library/header rather than making it a core language type (I've never been a fan of the overly-large type zoo of GLSL/etc).

My biggest concern is that converting into IR at the oslc stage is contrary to the primary use pattern -- which is that multiple "shaders" are assembled into a "group" (connected graph of individual shaders) and optimized like crazy BEFORE being turned into IR. This optimization stage is the only way that we have to tame the immense OSL shader networks people use in production, and it's the key to making OSL run faster than the equivalent separately-compiled C++. I am fairly confident that LLVM's optimizer would not find a lot of the key optimizations we exploit, simply because LLVM IR is too low level to recognize the situations that we can exploit with the higher level (oso-like) representation and detailed knowledge of the semantics and expectations of shaders.

So, as for some of the things you mentioned to aim for, you should know about two very important large-scale projects that are underway:

1. Intel (with help from Pixar) has made substantial progress on a new IR-generating module (i.e., taking over after we have done our "runtime optimization") that instead of generating scalar IR as usual to shade a single point, generates SIMD IR to shade batches (probably of 16) points. It's aimed primarily at AVX-512 to really shine, but we are hoping to have give a performance advantage for AVX as well (we're assuming that SSE, pre-AVX hardware, won't be worth the trouble). I believe -- authors, correct me if I'm wrong? -- that in the course of this work, they have also implemented debug info (i.e. the proper association of source lines and symbols to the generated machine code).

2. NVIDIA has built a prototype that takes our existing IR generation and targets Cuda hardware -- primarily for OptiX, but I think it should be within epsilon of being a general Cuda-generator, and I'm guessing probably largely overlaps with what's necessary to target OpenCL or SPIR-V.

The sum of work put into these projects is pretty substantial, so we want to be careful not to derail that by changing the overall scheme of where and when we convert to LLVM IR and let LLVM take over.

Aside: This is a good reminder for the authors of those sub-projects that they've worked far too long in private gardens, and instead should be submitting and committing them in reasonable-sized chunks as they went. People like Friederich/Roman should be contributing to your efforts, not spending time designing overhauls that are redundant to or will inhibit your work.

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to osl-dev+u...@googlegroups.com.

To post to this group, send email to osl...@googlegroups.com.
Visit this group at https://groups.google.com/group/osl-dev.
For more options, visit https://groups.google.com/d/optout.

--

Larry Gritz

l...@larrygritz.com

[Friederich Munch]

Thanks for the prompt reply, connectivity issues during travel didn't allow the same kindness....

To be clear it's still quite a prototpe, and while I've gotten CUDA & debugging to work it's been with isolated shaders, not networks.

The focus at this point is getting GLSL transformation done for viewport rendering, which likekly can be easily shared back into OSL.

I'm aware of the NVIDIA and Pixar projects, but as noted they've been announced but not materialized in public.  I'm not trying to be disparaging (or announce yet another one that isn't public), but wanted to get a better sense of whether language additions/changes are palpable before relying on them.

On the language features, it's good to know that there's some common ground.

Already gotten initializer lists and simple method calling to work, so I'll clean up & submit some pull requests when I get a chance.

Builtin vector types are of particular importance to me as not having it a guaranteed type makes generating GLSL that much more difficult.

I'm not advocating a swath of ivec, uvec, bvec, etc.  Just core float based vector 2,3,4. And assuming there is a backend that outputs to SIMD IR, doesn't it become beneficial to have a strict contract on the alignment/size so that those types can also benefit and not make the runtime optimizer & LLVM-codegen jobs that much more difficult? In a header based approach, whose to say some enterprising youth hasn't done this:

  struct color4 { string key; int value; color rgb; float a; };

Swizzling; I understand being lukewarm about, but component wise access is something I feel would benefit the language.

Cf.r is just a more convenient and obvious notation in a local context (the ambiguity of Cf[0] requires a bit more knowledge of what Cf is).  Once that was done, swizzling was trivial to add, and has the benefit if builtin vector types get added, they would be backward compatible with the current implementation (as well as not needing to manage additional intermediate shaders for MaterialX). It also makes some code more way more concise:

  color   c = Cf.r; // c is obviously an RGB of the red-channel.

  color4 b = c4.bgra;

vs:

  color   c = Cf[0]; // What is c now, is Cf an array or a color?

  color4 b = { color(a.rgb[2], a.rgb[1], a.rgb[0]), a.a }; // Tha't a lot of typing and not necessarily particularly easy to read.

And finally about the early IR generation. That wasn't to be taken as a proposal for OSL per-se but more context as to what is trying to be accomplished with the language itself (outside the context of shading, something more akin to VEX).  Assuming a network of shader/nodes whose source will never change: load the binaries/IR and immediately start processing (no JIT), in the background a new llvm::Module is built from the network of all node's IRs and constant parameters, on which LLVM optimization passes are run.

Whether or not it optimizes as well and the overhead is certainly a concern; though I feel porting the runtime optimizations to LLVM passes wouldn't be too painful.

Additional optimization strategies also become possible, like having the pre-compiled version provide profile-guided optimizations after a few runs.