time for amber2 branch?

[Triang3l]

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