search

mellinoe / ShaderGen

Proof-of-concept library for generating HLSL, GLSL, and Metal shader code from C#,
MIT License
497 stars 56 forks source link

[SUGGGESTION] ShaderBuiltins should be split #78

Open thargy opened 6 years ago

thargy commented 6 years ago

Further to the conversations in #65, #67 and GH-77, we should consider reserving ShaderBuiltins for members that will throw a ShaderBuiltinException as they cannot reasonably be implemented on the CPU - therefore code that uses them cannot be run on the CPU.

Methods that can have CPU equivalents should be in a seperate class (Builtins) to indicate that they can run on the GPU & CPU. This makes it easy to see if a file is using GPU only functionality (as it will reference ShaderBuiltins. By only including Builtins you can be sure the members used will be available when running the same code directly on the CPU.

Note, before GH-77 all members of ShaderBuiltins throw a ShaderBuiltinException anyway when executed on the CPU, even when they could be implemented to run on the CPU, so this wasn't as big an issue. However, going forward, the ability to share code between GPU & CPU is a USP of the library, and so consideration should be given to creating CPU implementations of members whenever feasible, so the distinction becomes more important.

thargy commented 6 years ago

Note, this will also make it easier to test, as an automatic test can easily be added to ensure all ShaderBuiltins members throw a ShaderBuiltinException on invocation. Further, an automated test can be added to test consistency between Builtins members on CPU & GPU.