Date
1 - 8 of 8
Individual layer execution
Larry Gritz
Per today's TSC meeting...
The PR that originally added the per-layer execution is this one from 2015: https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/pull/553
Unfortunately, though this has "now you can do this if you need the flexibility" explanation, it ultimately does not spell out a use case or say whose request it was that it be added. This is as close as we get:
The "all in one shot" approach still works just fine, and is probably the usual way of doing things. But for renderer that need even more control over which layers are executed and when, this provides an alternate calling sequence that gives more flexibility.
Our renderer just uses the "one-shot" approach. At this time, I cannot think of a good use case for the renderer taking control of individual layer execution. I honestly don't remember why we did this.
Since it's just unnecessary complication, and has no useful corresponding functionality on the GPU, my current recommendation is that we mark execute_init(), execute_layer() and execute_cleanup() as deprecated in the main branch, even on the CPU, and move toward eventually phasing them out and capitalizing on any simplifications that result.
Larry Gritz
The only think I can think of is this:
execute() unconditionally executes all nodes that produce renderer outputs (which may in turn lazily execute upstream layers).
Maybe we thought that if different nodes produced different renderer outputs, there would be a time that we only wanted a particular output to be produced, and could force just that layer (and its necessary predecessors, lazily) to be executed?
But as far as I know, we never took advantage of that flexibility.
If somebody depends on this functionality, speak up. Otherwise, I will consider it slated for deprecation.
On Oct 13, 2022, at 3:40 PM, Larry Gritz <lg@...> wrote:Per today's TSC meeting...The PR that originally added the per-layer execution is this one from 2015: https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/pull/553Unfortunately, though this has "now you can do this if you need the flexibility" explanation, it ultimately does not spell out a use case or say whose request it was that it be added. This is as close as we get:The "all in one shot" approach still works just fine, and is probably the usual way of doing things. But for renderer that need even more control over which layers are executed and when, this provides an alternate calling sequence that gives more flexibility.Our renderer just uses the "one-shot" approach. At this time, I cannot think of a good use case for the renderer taking control of individual layer execution. I honestly don't remember why we did this.Since it's just unnecessary complication, and has no useful corresponding functionality on the GPU, my current recommendation is that we mark execute_init(), execute_layer() and execute_cleanup() as deprecated in the main branch, even on the CPU, and move toward eventually phasing them out and capitalizing on any simplifications that result.
This does ring some bells now. I think it was part of one of our big refactorings of shaders and we were thinking of exploring a model where the renderer would be able to pull on only certain outputs. We probably had some particular graph topology in mind that would have required this, but after getting the right set of closures in place, we stuck to the pure OSL solution and never really looked at this API.
Definitely sounds safe to remove.
On Thu, Oct 13, 2022 at 3:40 PM Larry Gritz <lg@...> wrote:
Per today's TSC meeting...The PR that originally added the per-layer execution is this one from 2015: https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/pull/553Unfortunately, though this has "now you can do this if you need the flexibility" explanation, it ultimately does not spell out a use case or say whose request it was that it be added. This is as close as we get:The "all in one shot" approach still works just fine, and is probably the usual way of doing things. But for renderer that need even more control over which layers are executed and when, this provides an alternate calling sequence that gives more flexibility.Our renderer just uses the "one-shot" approach. At this time, I cannot think of a good use case for the renderer taking control of individual layer execution. I honestly don't remember why we did this.Since it's just unnecessary complication, and has no useful corresponding functionality on the GPU, my current recommendation is that we mark execute_init(), execute_layer() and execute_cleanup() as deprecated in the main branch, even on the CPU, and move toward eventually phasing them out and capitalizing on any simplifications that result.
Thomas METAIS
Hi,
We use execute_layer to execute a subset of a shaderGroup.
For instance we can have the displacement and the material defined in the same graph, and they can share some branches. But we don't want to evaluate the material part when we compute the displace.
If it's a burden to maintain we can think of another solution, but execute layer is quite useful for this use case.
Cheers,
Thomas METAIS
We use execute_layer to execute a subset of a shaderGroup.
For instance we can have the displacement and the material defined in the same graph, and they can share some branches. But we don't want to evaluate the material part when we compute the displace.
If it's a burden to maintain we can think of another solution, but execute layer is quite useful for this use case.
Cheers,
Thomas METAIS
Stephen Friedman
+1 to what Thomas said about executing a subset for a particular "context/stage/mode" of rendering. We currently have a bit more complicated way of doing this as we mix C++ and OSL shaders together, but I personally had hopes and dreams of eventually simplifying it down to just use execute_layer.
--Stephen
Zap Andersson
Correct me when (not if) I'm wrong, but wouldn't compiling your shader graph twice, once only asking for the displacement output, and once asking for the material outputs, give you the same thing, indvidually optimized? Might even end up being more run-time efficient (but slightly less compile time efficient)?
/Z
Lee Kerley
Thats exactly what we do zap, we see two smaller and faster materials.
On Wed, Oct 19, 2022 at 12:09 AM Zap Andersson via lists.aswf.io <zap.andersson=autodesk.com@...> wrote:
Correct me when (not if) I'm wrong, but wouldn't compiling your shader graph twice, once only asking for the displacement output, and once asking for the material outputs, give you the same thing, indvidually optimized? Might even end up being more run-time efficient (but slightly less compile time efficient)?
/Z
Stephen Friedman
Indeed Zap has hit on separate shaders one of the big reasons why what we have is more complicated, and the compile time being the reason you may not want this.
On Wed, Oct 19, 2022 at 9:12 AM Lee Kerley <lkerley@...> wrote:
Thats exactly what we do zap, we see two smaller and faster materials.On Wed, Oct 19, 2022 at 12:09 AM Zap Andersson via lists.aswf.io <zap.andersson=autodesk.com@...> wrote:Correct me when (not if) I'm wrong, but wouldn't compiling your shader graph twice, once only asking for the displacement output, and once asking for the material outputs, give you the same thing, indvidually optimized? Might even end up being more run-time efficient (but slightly less compile time efficient)?
/Z