time for amber2 branch?

[Triang3l]

On 19/06/2024 20:34, Mike Blumenkrantz wrote:
 > 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.

I don't think, however, that it can simply be dismissed like it doesn't 
exist when it's:
  • striving to become a part of Mesa among the "cool" drivers with 
broad extension support like RADV, Anvil, Turnip, and now NVK;
  • actively developed nearly every day (albeit for around 2 hours per 
day on average because it's a free time project);
  • trying to explore horizons Mesa hasn't been to yet (submitting 
hardware commands directly on Windows).

As for R600g, it's one thing to drop the constraints imposed by some 
Direct3D 9 level GPUs that, for instance, don't even support integers in 
shaders or something like that (if that's even actually causing issues 
in reality that slow down development of everything else significantly — 
the broad hardware support is something that I absolutely LOVE Mesa and 
overall open source infrastructure for, and I think that's the case for 
many others too), but here we're talking about Direct3D 11 (or 10, but 
programmed largely the same way) class hardware with OpenGL 4.5 already 
supported, and 4.6 being straightforward to implement.

This means that, with the exception of OpenCL-specific global addressing 
issues (R9xx can have a 4 GB "global memory" binding though possibly), 
the interface contract between Gallium's internals and R600g shouldn't 
differ that much from that of the more modern drivers — the _hardware_ 
architecture itself doesn't really warrant dropping active support in 
common code.

Incidents like one change suddenly breaking vertex strides are thus 
mainly a problem in how _the driver itself_ is written, and that's of 
course another story… While I can't say much about Gallium interactions 
specifically, I keep encountering more and more things that are 
unhandled or broken in how the driver actually works with the GPU, and 
there are many Piglit tests that fail. I can imagine the way R600g is 
integrated into Gallium isn't in a much better state.

So I think it may make sense (even though I definitely don't see any 
serious necessity) to **temporarily** place R600g in a more stable 
environment where regressions in it are less likely to happen, but then 
once it's brought up to modern Mesa quality standards, and when it 
becomes more friendly to the rest of Mesa, to **move it back** to the 
main branch (but that may stumble upon a huge lot of interface version 
conflicts, who knows). Some of the things we can do to clean it up are:

  • Make patterns of interaction with other subsystems of Gallium more 
similar to those used by other drivers. Maybe use RadeonSI as the 
primary example because of their shared roots.
  • Fix some GPU configuration bugs — that I described in my previous 
message, as well as some other ones, such as these small ones:
    • Emit all viewports and scissors at once without using the dirty 
mask because the hardware requires that (already handled years ago in 
RadeonSI).
    • Fix gl_VertexID in indirect draws — the DRAW_INDIRECT packets 
write the base to SQ_VTX_BASE_VTX_LOC, which has an effect on vertex 
fetch instructions, but not on the vertex ID input; instead switch from 
SQ_VTX_FETCH_VERTEX_DATA to SQ_VTX_FETCH_NO_INDEX_OFFSET, and COPY_DW 
the base to VGT_INDX_OFFSET.
    • Properly configure the export format of the pixel shader DB export 
vector (gl_FragDepth, gl_FragStencilRefARB, gl_SampleMask).
    • Investigate how queries currently work if the command buffer was 
split in the middle of a query, add the necessary stitching where needed.
  • Make Piglit squeal less. I remember trying to experiment with 
glDispatchComputeIndirect, only to find out that the test I wanted to 
run to verify my solution was broken for another reason. Oink oink.
  • If needed, remove the remaining references to TGSI enums, and also 
switch to the NIR transform feedback interface that, as far as I 
understand, is compatible with Nine and D3D10 frontends (or maybe it's 
the other way around (= either way, make that consistent).
  • Do some cleanup in common areas:
    • Register, packet and shader structures can be moved to JSON 
definitions similar to those used for GCN/RDNA, but with more clear 
indication of the architecture revisions they can be used on (without 
splitting into r600d.h and evergreend.h). I've already stumbled upon a 
typo in that probably hand-written S_/G_/C_ #define soup that has caused 
weird Vulkan CTS failures once, specifically in 
C_028780_BLEND_CONTROL_ENABLE in evergreend.h, and who knows what other 
surprises may be there. Some fields there are apparently just for the 
wrong architecture revisions (though maybe actually present, but 
undocumented, I don't know, given the [RESERVED] situation with the 
documentation for anisotropic filtering and maybe non-1D/2D_THIN tiling 
modes, for example, and that we have the reference for the 3D registers, 
but not for compute).
    • A lot of format information can be shared between vertex fetch, 
texture fetch, and color/storage attachments. I'm finishing writing some 
common format code for Terakan currently, that may be adopted by R600g.
    • Carefully make sure virtual memory is properly supported in all 
places on R9xx (using virtual addresses, and not emitting relocation 
NOPs that are harmless but wasteful — moreover, this part deserves some 
common function that will make it easier to port R600g to other 
platforms, such as by making it write D3DKMTRender patch locations on 
Windows).
  • Unify R6xx/R7xx and R8xx/R9xx code wherever possible. There's 
r600_state.c that is over 100 KB large, and evergreen_state.c that's 
even bigger, but in many places it's just the same code, just including 
r600d.h in one file and evergreend.h in another — and how much technical 
debt we already have in the R6xx/R7xx code is an interesting question. 
To me, there doesn't seem to be any necessity to abandon R6xx/R7xx 
support completely currently considering that the programming 
differences from R8xx/R9xx are pretty minor. At least as long as someone 
occasionally runs tests on the older generations.

Maybe that will involve some small-scale changes, maybe that will end up 
being more like a rewrite, but still it's totally possible that R600g 
may have a new beginning at this point, especially with Gert Wollny's 
compiler, and me visiting every aspect of the interface of those GPUs, 
rather than an ending. At some point we may even start exposing 
R600-specific functionality such as D3DFMT_D24FS8 in Gallium Nine on 
R6xx/R7xx.

However, I don't like the whole idea of moving drivers away from the 
main branch because that affects not only development, but also users of 
Mesa. It'd be necessary to ensure that Linux distribution maintainers 
are well-notified of the new branch, but even then that may still cause 
issues. Like, what if the amber2 drivers end up in a separate package in 
a distribution — and that'll possibly mean that after some `apt-get 
dist-upgrade`, users will suddenly lose GPU acceleration on their 
systems for an unobvious reason. And we definitely shouldn't be 
underestimating the number of users of that old hardware outside Linux 
developer circles — especially TeraScale (I think Firefox regularly gets 
issue reports from Nvidia Rankine/Curie users?) I occasionally see 
people on Reddit and other platforms discussing the status of Terakan, 
and I'd expect that the people who talk about some software are just a 
small fraction of those who use it at all. And sometimes weird things 
just happen like Bringus Studios bringing up a Xi3 Piston out of 
semi-vaporware nowhere…

Regarding CI, I can't promise anything right now, but I think that's not 
an unsolvable issue. Overall just one machine with a Trinity APU, an 
R6xx/R7xx card, and an R8xx card (one of them preferably being RV670, 
RV770, or Cypress/Hemlock, to be able to test co-issuing of float64 
instructions with a transcendental one when that's implemented) likely 
should cover most of our regression testing needs — at least in Gallium 
interaction most definitely.

Terakan development will surely continue being based on the main branch, 
partly because the original reason behind the split suggestion mostly 
doesn't apply to it. I do need recent Vulkan headers and all the WSI 
improvements at the very least — and there are areas where Terakan 
itself may contribute something new to the common Vulkan runtime code. I 
already have some WSI-demanded binary-over-timeline sync type 
enhancements on my branch, and if my Windows experiments go forward, 
there will likely be a lot of what can be added to the common code, such 
as WDDM 1 synchronization primitives (even though WDDM 2's timeline 
semaphores aka monitored fences are more important to modern drivers, 
there's no WDDM 2 on Windows older than 10), as well as paths for 
zero-copy presentation (primarily for WDDM 1 level configurations — like 
via sharing images with Direct3D 10/11, or with OpenGL to take advantage 
of the "exclusive borderless" driver hack, or maybe even via 
D3DKMTPresent where possible).

On 20/06/2024 20:30, Adam Jackson wrote:
 > We're using compute shaders internally in more and more ways, for 
example, maybe being able to assume them would be a win.

I'd imagine that compute shader usage scenarios in common Gallium code 
are optional, and depending on the hardware, compute shaders can even be 
the less optimal approach to things like image copying/resolving (where 
specialized copy hardware is available) from the perspective of 
performance or maybe format support (early, or maybe actually all, I 
don't know for sure yet, AMD R8xx hardware, for instance, hangs with 
linear storage images according to one comment in R800AddrLib, and 
that's why a quad with a color target may be preferable for copying — 
and it also has fast resolves inside its color buffer hardware, as well 
as a DMA engine).

— Triang3l