eden-emu/eden - eden - InfoTonic

ReinUsesLisp a8a2526128 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
..
opus@ad8fe90db7	externals: Track upstream opus	7 years ago
CMakeLists.txt	Set _FORTIFY_SOURCE=0 if building Opus with mingw-w64	6 years ago

ReinUsesLisp a8a2526128 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

opus@ad8fe90db7

externals: Track upstream opus

7 years ago

CMakeLists.txt

Set _FORTIFY_SOURCE=0 if building Opus with mingw-w64

6 years ago