In the last OSL TSC meeting, we were discussing the continued role of the setmessage/getmessage functions.

Now, let's put aside how getmessage("trace", ...) doubles as a way to retrieve information from the more recent previous call to trace(). Let's consider that just syntactic sugar for a different (and potentially still useful) operation for now.

The question is about the original role of set/getmessage: that one layer in a complicated shader network could call setmessage("key", data) to write some data to a shared (per-shade) blackboard, and then a different layer that executes later in the same shader graph could call getmessage("key", destination) to retrieve that data.

As a historical note, this was kind of borrowed from old RSL message passing that was (in the non-physical days) used for all sorts of back door communications between surfaces and lights, which were treated as kind of a coroutine. OSL, from its earliest design goals, doesn't run lights concurrently with surface shaders, so it obviously can't be used for that purpose.

We make the following observations:

1. This feature is a big pain to implement for the GPU back ends, and adds a lot of complexity for something rarely or never used.

2. Given the "lazy evaluation" we prefer for shader graphs, it can be tricky to ensure that the early layer that's expected to set the message is actually run before the later layer that's expected to retrieve it, so maybe it has always been error-prone and marginally useful ever since we added the lazy evaluation.

3. It's probably cleaner and more direct to simply do communication between layers in the usual manner of connecting one's outputs to another's inputs.

4. Among the renderers and studios represented at the last TSC meeting, everybody says that their current shader libraries and practices do not rely on this set/getmessage facility.

So before we commit to not worrying about implementing it for GPU, and possibly phasing it out of the language entirely at some point, we wanted to open to wider discussion and ask anybody who is currently using these functions (again, for purposes OTHER than retrieving trace results) to please speak up now and let us know.


--
Larry Gritz
lg@...