time for amber2 branch?

[Mike Blumenkrantz]

On Wed, Jun 19, 2024 at 1:22 PM Triang3l <triang3l at yandex.ru> wrote:

> 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.
>

Nothing stopping those developments from continuing in an amber branch, and
the odds of any NIR changes being required for hardware this old are slim.


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

Terakan is not a Mesa driver, and Mesa has no obligation to cater to
out-of-tree projects which use its internal API. For everything else, see
above.


Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20240619/697976da/attachment-0001.htm>