eden-emu/eden - eden - InfoTonic

ReinUsesLisp 76bd3a8843 gl_arb_decompiler: Use NV_shader_buffer_{load,store} on assembly shaders NV_shader_buffer_{load,store} is a 2010 extension that allows GL applications to use what in Vulkan is known as physical pointers, this is basically C pointers. On GLASM these is exposed through the LOAD/STORE/ATOM instructions. Up until now, assembly shaders were using NV_shader_storage_buffer_object. These work fine, but have a (probably unintended) limitation that forces us to have the limit of a single stage for all shader stages. In contrast, with NV_shader_buffer_{load,store} we can pass GPU addresses to the shader through local parameters (GLASM equivalent uniform constants, or push constants on Vulkan). Local parameters have the advantage of being per stage, allowing us to generate code without worrying about binding overlaps.	6 years ago
..
libzip@89bd6d63bd	externals: Track upstream libzip	7 years ago
CMakeLists.txt	externals: Track upstream libzip	7 years ago

ReinUsesLisp 76bd3a8843 gl_arb_decompiler: Use NV_shader_buffer_{load,store} on assembly shaders

NV_shader_buffer_{load,store} is a 2010 extension that allows GL applications
to use what in Vulkan is known as physical pointers, this is basically C
pointers. On GLASM these is exposed through the LOAD/STORE/ATOM
instructions.

Up until now, assembly shaders were using NV_shader_storage_buffer_object.
These work fine, but have a (probably unintended) limitation that forces
us to have the limit of a single stage for all shader stages. In contrast,
with NV_shader_buffer_{load,store} we can pass GPU addresses to the
shader through local parameters (GLASM equivalent uniform constants, or
push constants on Vulkan). Local parameters have the advantage of being
per stage, allowing us to generate code without worrying about binding
overlaps.

6 years ago

libzip@89bd6d63bd

externals: Track upstream libzip

7 years ago

CMakeLists.txt

externals: Track upstream libzip

7 years ago