The shader compiler in R600g is actively developed (and I think OpenGL 4.6
support is among the main goals), I don't see why it needs to be moved to a
low-priority branch or to stop getting new NIR infrastructure updates
with the
current amount of maintenance it receives.
On 19/06/2024 18:26, Thomas Debesse wrote:
> Maybe the work-in-progress “Terakan” vulkan driver for r600 cards
> won't be affected because vulkan is not a gallium thing.
Terakan uses R600g files heavily, specifically the register structures,
as well
as the shader compiler (with additional intrinsics implemented and plans
to move
some SFN parts, primarily those interacting with bindings, such as storage
images/buffers, to NIR lowerings in R600g too for more straightforward code
sharing) and other shader-related parts.
Moreover, there likely will be backporting of some parts of Terakan to R600g
(architectural-scale bugfixes primarily) in the somewhat distant future
(when
they're fully implemented and well-tested in Terakan), specifically:
• GL_ARB_shader_draw_parameters.
• New vertex fetch subroutine generation, correctly dividing by the
instance
divisor, and co-issuing instructions where possible.
• 2048 vertex stride fetch subroutine workaround on pre-Cayman GPUs
(which have
bits only for up to 2047).
• Color attachment index compaction in fragment shaders to allow gaps
to be
filled with storage resources.
• Handling different alignment of pitch calculated by texture fetching
hardware
for 1D-thin-tiled mips of depth and stencil surface aspects that
can't be
respected on the depth/stencil attachment side where the pitch
register is
shared (likely will be using an intermediate overaligned surface).
• True indirect compute dispatch via a different packet sequence on the
existing kernel versions, and later, when the involved command
parsing is
fixed in the kernel, using actual INDIRECT_DISPATCH type-3 packets.
— Triang3l
