You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Further to the extensive discussion in #65, a core goal would be to share shader code between the CPU and GPU, allowing ray-tracing, AI, etc. to be run on the CPU where compute shaders are not available, or even to maximise throughput by utilising both the CPU and GPU.
The ShaderBuiltins for VertexID, InstanceID, DispatchThreadID, GroupThreadID, IsFrontFace allow shader code to access these variables in an 'OpenGL style' as opposed to the 'Direct3D' style where the variables are passed into shaders as parameters.
For example DispatchThreadID is simply replaced with gl_GlobalInvocationID in OpenGL, but is added as an input parameter to the compute shader e.g.
Although, this is a valid sylistic choice, as the aspiration is to be able to ultimately execute CS from the CPU it would be much easier to achieve that goal replacing code such as:
// Current 'OpenGL' style[ComputeShader(1,1,1)]publicvoidCS(){uintindex=DispatchThreadID.X;
...}
with a pattern like:
// Proposed 'Direct3D' style - with parameter name matching[ComputeShader(1,1,1)]publicvoidCS(UInt3dispatchThreadID){uintindex=dispatchThreadID.X;
...}
or, to future proof, prevent collisions, be less 'magic' and far more intelligible to consumers, allow a semantic attribute that supports parameter attachment:
// Proposed 'Direct3D' style - with semantic attribute indicating which parameter is the dispatch id[ComputeShader(1,1,1)]publicvoidCS([DispatchIDSemantic]UInt3id){uintindex=id.X;
...}
This approach would make it much easier to call the compute shader directly from .NET code on the CPU. Currently ShaderBuiltins.DispatchID (et al) throw a ShaderBuiltinException on execution on the CPU. Technically, I could change them to pull out a value from the Thread context, however maintaining a thread context is notoriously annoying in an async world and impacts on performance, and compute shaders (in particular) are destined to be run asynchronously even on the CPU. Further, as the code can't easily tell which properties will be accessed in the code, all of them would need adding to the context immediately prior to execution, which is wasteful and slow. Anyone implementing a CPU executor for the shaders would likewise need to understand how to setup the contexts (possibly by adding methods such as ShaderBuiltins.InitialiseComputeContext(...), ShaderBuiltins.InitialiseVertexContext(...), etc.) but this is far less obvious and discoverable, and far less performant than adopting the Direct3D style.
The text was updated successfully, but these errors were encountered:
FYI: as a workaround, I'm currently doing the following:
// Current 'OpenGL' style[ComputeShader(1,1,1)]publicvoidCS(){DoCS(DispatchThreadID);}publicvoidDoCS(UInt3dispatchThreadID){uintindex=dispatchThreadID.X;
...}
And calling DoCs(...) from the CPU, this doesn't allow for easy auto-plumbing, etc. (i.e. calling the known entry-point dynamically is not possible)
Further to the extensive discussion in #65, a core goal would be to share shader code between the CPU and GPU, allowing ray-tracing, AI, etc. to be run on the CPU where compute shaders are not available, or even to maximise throughput by utilising both the CPU and GPU.
The ShaderBuiltins for
VertexID
,InstanceID
,DispatchThreadID
,GroupThreadID
,IsFrontFace
allow shader code to access these variables in an 'OpenGL style' as opposed to the 'Direct3D' style where the variables are passed into shaders as parameters.For example
DispatchThreadID
is simply replaced withgl_GlobalInvocationID
in OpenGL, but is added as an input parameter to the compute shader e.g.Although, this is a valid sylistic choice, as the aspiration is to be able to ultimately execute
CS
from the CPU it would be much easier to achieve that goal replacing code such as:with a pattern like:
or, to future proof, prevent collisions, be less 'magic' and far more intelligible to consumers, allow a semantic attribute that supports parameter attachment:
This approach would make it much easier to call the compute shader directly from .NET code on the CPU. Currently
ShaderBuiltins.DispatchID
(et al) throw aShaderBuiltinException
on execution on the CPU. Technically, I could change them to pull out a value from the Thread context, however maintaining a thread context is notoriously annoying in an async world and impacts on performance, and compute shaders (in particular) are destined to be run asynchronously even on the CPU. Further, as the code can't easily tell which properties will be accessed in the code, all of them would need adding to the context immediately prior to execution, which is wasteful and slow. Anyone implementing a CPU executor for the shaders would likewise need to understand how to setup the contexts (possibly by adding methods such asShaderBuiltins.InitialiseComputeContext(...)
,ShaderBuiltins.InitialiseVertexContext(...)
, etc.) but this is far less obvious and discoverable, and far less performant than adopting theDirect3D
style.The text was updated successfully, but these errors were encountered: