Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2024-11-29T07:02:19+00:00 2024-11-29T07:02:19+00:00 Bruce Mitchener bruce.mitchener@gmail.com 2024-11-29T07:02:19+00:00 urn:sha1:c3557978cf0184aaf75c27c309bc87e84fd6ab79 Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com> 2019-02-28T15:59:17+00:00 Tim Foley tfoleyNV@users.noreply.github.com 2019-02-28T15:59:17+00:00 urn:sha1:852c88cc9d7e720af66275bf7fdf58341f5f6e7c The `specializeProgramLayout()` primarily existed to support global generic parameters. The guiding idea of the design had been that plugging in concrete types for global generic parameters should only affect the layout/binding of shader parameters that depend on the global generic type parameters. All other shader parameters should keep the same layout/location across all specializations. This idea was implemented by conceptually having two phases of layout: * A generic-argument-independent phase would do layout on all the shader parameters that *don't* depend on global generic type parameters. * A second phase would then pick up where the other one left off (re-using existing parameter layouts to guarantee a match), and just layout out the shader parameters that *do* depend on global generic type parameters. Because the other parameters were already laid out, these new parameters would only ever fill in the gaps in layout (or come after all the other parameters, if explicit bindings aren't used). This implementation strategy proved to be a bit of a mess, since we had to duplicate most of the code between the two passes anyway. This commit eliminates `specializeProgramLayout()` entirely, and instead threads through global generic type arguments as part of the main layout pass. It is almost strictly a cleanup pass, now that the refactored logic for `Program` means the same layout algorithm can apply to specialized and unspecialized programs. This change has one important semantic consequence (which is technically a break in backwards compatiblity for anybody using global generic parameters). Parameters that depend on global generic type parameters now get laid out in declaration order, just like all other shader parameters. This simplifies the rules, and in my experience actually makes application code *easier* to write in a systematic way (whereas the original design was motivated by the idea that giving more things stable locations would be beneficial). A future improvement could be made so that we don't thread through the global generic substitution as part of layout. Instead, we could just attach a list of the global generic type arguments directly to the `TypeLayoutContext` and look those up on-demand when we encounter a global generic parameter type during layout. This would actually eliminate the need for global generics to appear as a `Substitution` entirely. 2018-02-02T18:38:22+00:00 Tim Foley tfoleyNV@users.noreply.github.com 2018-02-02T18:38:22+00:00 urn:sha1:58475a8aa42284722a3763aa3bde49f2fa40366e - Remove references to building by embedding source (not recommended at this point) - Push users more toward binary builds rather than building from source (but include a document that talks about how to build) - Remove most (all?) references to supporting GLSL input - Expand the language guide to talk about the new features - Add a document that talks about the parameter layout algorithm