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
As user code is generally not optimized, there might be a need to implement optimization passes.
On the shader side
Optimization can happen on the AST generated, some passes like constant propagation, type checking and type coercion are better fit in this part of the compiler.
There is an api for creating an intermediate representation between SDSL and SPIR-V for control flow graph optimization, like finding dead code and such. This IR is created with arrays of quadruples/three address code that can be converted in a graph representation.
On the sdspv side
As this library creates an SDSL flavored SPIR-V to be able to mix and combine modules together, there might be considerations for optimizations on this level.
On the SPIR-V
SPIR-V is an binary intermediate representation of shader code. It is generally consumed by drivers and is most likely optimized for binaries generated for GPUs. We can't know to which extent it is optimized and how performance could be affected since there are so many different GPUs and drivers that work differently.
As user code is generally not optimized, there might be a need to implement optimization passes.
On the shader side
Optimization can happen on the AST generated, some passes like constant propagation, type checking and type coercion are better fit in this part of the compiler.
There is an api for creating an intermediate representation between SDSL and SPIR-V for control flow graph optimization, like finding dead code and such. This IR is created with arrays of quadruples/three address code that can be converted in a graph representation.
On the sdspv side
As this library creates an SDSL flavored SPIR-V to be able to mix and combine modules together, there might be considerations for optimizations on this level.
On the SPIR-V
SPIR-V is an binary intermediate representation of shader code. It is generally consumed by drivers and is most likely optimized for binaries generated for GPUs. We can't know to which extent it is optimized and how performance could be affected since there are so many different GPUs and drivers that work differently.
SPIR-V Tools offers
spirv-opt
, a tool to reduce binary size of SPIR-V modules, unfortunately not usable directly in C# unless we create bindings to the library. Fortunately, the lunarg sdk has a little pdf talking about various optimization passes possible on SPIR-V level.The text was updated successfully, but these errors were encountered: