When dinosaurs roamed the earth, OIIO's TextureSystem API assumed it might be used for many different types of renderers, and so we had placeholders for shadow mapping calls (and related parameters in

Wondering if anybody would object to the following changes to minimum dependencies -- only for master branch going forward and the NEXT major release of OSL (obviously not dropping support from releas

Are you saying you've fully figured it out? -- Larry Gritz lg@...

It sure smells like you have two threads simultaneously messing with the same closure pool, which should never happen. Are you EXTRA SURE that the threads are each using their own distinct ShadingCont

With a debug build, can you get a stack trace at the point that the assertion is hit? That looks like an assertion in SimplePool::alloc(). But I'm not sure what could go wrong. Maybe something that co

And I've merged this PR into master now, so hopefully this will be fixed. -- lg -- Larry Gritz lg@...

I'm not "justifying" necessarily, I'm just explaining how things came to be in this state. From the beginning, OSL needed OIIO for its image handling, the TextureSystem, and also a lot of great utilit

Happy monthly release day! We have tagged "v1.11.15.0" and moved the "release" branch marker to that position. This is the latest supported production release of OSL. It guarantees API, ABI, and link

Yes, and also there is a branch called "release" that at all times points to the latest supported release. (We move the branch marker whenever we tag releases.) Yes, exactly. From the point of view of

First, please note that the SymLocation stuff is very hot off the presses, and only is present in OSL master, not yet in any officially supported release. It may be better to use the older find_symbol

I think all that shows is that the first "nvidia-smi" in your PATH is the one that is from Cuda 11.4, so it's showing you what it knows. I doubt that nvidia-smi comprehensively searches your entire sy

You say you have Cuda 11.4, but the error message says: > error: GPU arch sm_75 is supported by CUDA versions between 10.0 and 11.0 (inclusive), but installation at /usr/local/cuda is 7.0. Maybe you h

Apologies for the delay. How about this? https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/pull/1397 I tought it would be safe to do what we did -- the derived classes don't in fact ove

Hi, Patrick. Answers inline. Neato! vector and color are built-in types for 3-vector and 3-color. Aesthetically, I never liked having types in a shading language for vector4 (what are they for?) and c

So, underneath, it's really all flattened to just a simple list of shaders in the group (that's why we sometimes call them "layers"). Connections can only go from outputs of earlier numbered layers to

This is great, Mario! -- Larry Gritz lg@...

Since it's directly against ASWF Open Source Days presentations. I'm not aware of any emergencies that require an in-person discussion this week. I propose that we skip this week, resume as usual 2 we

Just to directly answer a few of Patrick's questions that I hadn't responded to: The call is supported for PTX, but (currently) not any of the transformations that require OCIO support. So you can tra

We allow transformation between arbitrary color spaces, falling back on OCIO when encountering names we don't know (but figure might be in the user's color config). But this was intended originally as

I've certainly seen many examples of shaders where colors are transformed in and out of color spaces for particular computations, but usually it's for artistic control, like using a color space such a