Future Work

[daniel-schuermann]

The purpose of this issue is purely informative and should serve clarification about recurring questions whether ACO will support certain features in future.

• Supported hardware:

  • [x] GFX6 (Radeon 7000 series, Radeon 200 series)
  • [x] GFX7 (Radeon 290, Radeon 300 series)
  • [x] GFX8 (Tonga, Fiji, Polaris)
  • [x] GFX9 (Vega)
  • [x] GFX10 (Navi)
  • [x] APUs (Bristol Ridge, Raven Ridge, ...)
  • [ ] ~Intel & Nvidia~ (not possible)

• Supported shader stages:

• [x] Vertex shaders

• [x] Tesselation control shaders

• [x] Tesselation evaluation shaders

• [x] Geometry shaders

• [x] Fragment shaders

• [x] Compute shaders

• Supported APIs:

• [x] Vulkan

• [ ] OpenGL

• [ ] ~OpenCL~ (not planned for near to mid future)

[SpookySkeletons]

Would Intel be open to providing pull requests to the compiler for their GPU's arch? Or is it some other blocker?

What license is ACO released under? MIT, same as Mesa?

[daniel-schuermann]

Would Intel be open to providing pull requests to the compiler for their GPU's arch? Or is it some other blocker?

The backend is GCN-only, and trying to port it to some other vendor's ISA basically means to rewrite it from scratch, so no.

What license is ACO released under? MIT, same as Mesa?

Yes.

[SR-dude]

FYI; I just tried a release candidate for 5.3 and it wasn't a pleasant experience. I only tried _The _Division__ and the garbage displayed on the screen should be worrisome to ACO developers. I had no choice but to downgrade.

[pendingchaos]

@SR-dude: Does this issue only happen with ACO?

There was a regression with Vega (fixed in 994dc8eefdce3b7071850087574bb8ba84f6752f) which affected anything using Vulkan (but that shouldn't be affected by the kernel version though).

If it wasn't fixed by that and only happens with ACO, this should probably have it's own issue created.

[SR-dude]

I only tested ACO. I was looking into the strange GPU resets with the aforementioned game.

[daniel-schuermann]

As ACO is only a compiler backend, it barely interacts with the userspace driver and nothing else. It just translates code from one language to another.

[ntropy83]

The point "Supported shader stages", what does it mean exactly? As far as I know current ACO is not leaving out the rendering of tesselation or geometry shaders in a game.

One last question: why is Intel support not possible? Could that change if they release their dGPUs?

[pendingchaos]

The point "Supported shader stages", what does it mean exactly? As far as I know current ACO is not leaving out the rendering of tesselation or geometry shaders in a game.

It means RADV falls back to LLVM for these shaders because we haven't yet implement the features needed to compile them.

One last question: why is Intel support not possible? Could that change if they release their dGPUs?

ACO is a AMD specific because it turns a shader in a representation used by many Mesa drivers and common code (NIR) into GCN (and in the future, RDNA) code. So it's extremely AMD specific and supporting Intel CPUs would mean adding backends to ACO (which is already a backend) and turning it's IR into something resembling NIR.

It's role is similar to a LLVM backend and reason why it can't be used for Intel is the same reason why LLVM's X86 backend doesn't support ARM CPUs.

Intel's dGPUs almost certainly won't be using GCN/RDNA, so it won't change when they release them.

[ntropy83]

That makes sense, thank you for explaining. I am curious to see the end result, keep up the good work. If you ever need some helping hands let me know.

[Maltahl]

Is it currently possible to build a version of mesa-git-aco that supports navi10 (GFX10) ? I dont mind if i have to compile it myself and test it out.

Binaries provided on https://people.freedesktop.org/~agd5f/radeon_ucode/navi10/ are currently broken since 8/8 . However, the binaries on https://koji.fedoraproject.org/koji/buildinfo?buildID=1314657 works great with mesa-git using llvm 10 but i really wanna test the ACO patched mesa driver on Navi10

[pendingchaos]

Is it currently possible to build a version of mesa-git-aco that supports navi10 (GFX10) ? I dont mind if i have to compile it myself and test it out.

Not sure which exact package your talking about, but a sufficiently up-to-date one should be compiled with Navi support.

Binaries provided on https://people.freedesktop.org/~agd5f/radeon_ucode/navi10/ are currently broken since 8/8 . However, the binaries on https://koji.fedoraproject.org/koji/buildinfo?buildID=1314657 works great with mesa-git using llvm 10 but i really wanna test the ACO patched mesa driver on Navi10

It shouldn't matter what firmware you use with ACO, as long as the firmware works.

Note that ACO doesn't yet support Navi, so it will fall back to LLVM.

[Maltahl]

Not sure which exact package your talking about, but a sufficiently up-to-date one should be compiled with Navi support. It shouldn't matter what firmware you use with ACO, as long as the firmware works.

Note that ACO doesn't yet support Navi, so it will fall back to LLVM.

Thanks for the very quick reply. Good to know but there is still a warning where fallback is not happening on the package from valveaur mesa-aco-git 1:19.2.0_devel.115181.34dd1ddde6f-1

The driver that works for me currently is mesa-git compiled with your llvm (PKGBUILD from tk-glitch on github) so thanks a lot for the llvm build you have @pendingchaos since it is the llvm version that works for me.

[SR-dude]

Put your mind at ease. Kernel version 5.3-rc4 is ok and I'm not having any problem with ACO by using that kernel version.

[shmerl]

Put your mind at ease. Kernel version 5.3-rc4 is ok and I'm not having any problem with ACO by using that kernel version.

But aco is still not supporting Navi?

[vosian]

The original post says that ACO doesn't yet support Navi, so you'll have to wait a while.

[daniel-schuermann]

ACO should now be able to support GFX7 GPUs (Radeon R7 260/360(X) and R9 290/390(X)). (For upstream support, please check on https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2751 if it was merged.)

[MEXAHOTABOP]

gfx7 support can be upstreamed in coming 19.3.0 or 20.0/19.3.1+ only?

[BNieuwenhuizen]

I'd expect the gfx7 support to first end up in 20.0.

[MEXAHOTABOP]

this mean release somewhere in march thanks

[daniel-schuermann]

It's a bit unfortunate, but there isn't much we can do about. 19.3 has already been branched off, and only bug fixes are allowed to be backported. New features like this one automatically end up in the next release cycle.

[tiburcillo]

allright, does that mean I can use Ernst's or Kisak's PPA (https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa) or (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco?field.series_filter=eoan) to test this functionality?

[daniel-schuermann]

Both PPAs switched to 19.3, which means no. You can test it usind either https://launchpad.net/~valve-experimental (currently has only Bionic packages..) or wait a bit for it to land and use padoka PPA with RADV_PERFTEST=aco

[tiburcillo]

Thanks so much for this work, I'll keep my eyes open for a Mesa 20 PPA or maybe try to compile myself. Will report back in Steam Community once I grilled my good old R9 390X.

Both PPAs switched to 19.3, which means no. You can test it usind either https://launchpad.net/~valve-experimental (currently has only Bionic packages..) or wait a bit for it to land and use padoka PPA with RADV_PERFTEST=aco

[SpookySkeletons]

Is it a good idea to add a config option to the meson build to disable llvm dependency requirements completely once ACO is feature complete if amdgpu is the only lib enabled? Would be very useful for Gentoo down the line.

[daniel-schuermann]

I think so, but this will probably not be the case before 20.1 (at least if you also want to build radeonSI).

[MEXAHOTABOP]

used aco on gfx7 for a week seems like no problems so far good job

[eiglow]

is GFX6 support something that's coming? my HD 7970 and r5 240 are hanging out for it

[shmerl]

Is there any rough ETA for tessellation and geometry shaders support?

[pendingchaos]

GFX6, tessellation and geometry shaders are on the TODO list, there isn't really an ETA though

There is a WIP MR for geometry shaders on the freedesktop Gitlab which seems to work on Vega/Navi, so hopefully geometry shaders isn't too far away (though I expect the holidays to slow down review).

[SpookySkeletons]

Thanks for the heads up on the merge. Will gladly test the gs patches on my GFX8 when it finishes compiling with LTO!

Update: The gs patches seem to work alright on my GFX8 in Mordhau through steamplay! Nothing exploded or crashed

[marekolsak]

The section about supported shader stages is ambiguous. You know the vertex shader can be compiled as VS, ES, or LS, and the tess eval shader can be compiled as VS or ES. Also on gfx10, vertex shaders are usually compiled as NGG GS.

[pendingchaos]

Yeah, the item on vertex shaders is a little unclear. Vertex shaders as VS is supported but ES/LS (used when geometry or tesselation shaders are used) is unsupported. All kinds of geometry and tesselation shaders are unsupported. NGG is currently unsupported and it falls back to the legacy pipeline

The GS MR implements vertex shaders as ES, merged vertex/geometry shaders and GS copy shaders

[shmerl]

And is NGG work planned after tessellation shaders?

[pendingchaos]

There isn't really a planned order

If implementing NGG would improve vertex shader performance though, I would prioritize it over tessellation shaders. I haven't gotten around to actually checking this though

[marekolsak]

If NGG culling was implemented, it would double primitive throughout, because NGG GS can process primitives 2x faster than the rasterizer. Without culling, you are limited by the rasterizer. The legacy VS can only process primitives at the same rate as the rasterizer.

[marekolsak]

The downside of NGG culling is that it consumes more shader resources. The shaders are longer, have to contain culling code and thread compaction code, use LDS, and contain quite a few barriers.

[SR-dude]

Is this repository now deprecated? Any updates?

[shmerl]

As far as I understood, it's recommended to use Mesa master for any incoming aco updates.

[daniel-schuermann]

Is this repository now deprecated? Any updates?

Let's say it's deprecated, but will still receive updates for a while (probably until mesa 20.0.x). Currently, we use it as testing bed for merge requests, and try to rebase every week or so.

[baryluk]

@daniel-schuermann I think it is a good idea to close the issue tracker and not accept new issue reports.

[daniel-schuermann]

Upstream has no issue templates yet, so no. At least not yet :)

[pendingchaos]

Geometry shader support (from https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2421 ) has been pushed to this repository. It hasn't been upstreamed yet.

Geometry shaders are enabled for all hardware ACO supports. Some of the commit messages mention "GFX8", but geometry shaders work the same on GFX7 and so should be enabled there too (the commits were initially made before GFX7 support was upstreamed IIRC).

[shmerl]

Do geometry shaders need any flags to enable wave32 for them like in other cases?

[pendingchaos]

When NGG is disabled for geometry shaders (which is currently always the case with both ACO and LLVM, but LLVM will soon use NGG), RADV always uses wave64 for geometry shaders

[aufkrawall]

Are LLVM's compile times for GS comparably bad as for others? Seems like the immediate advantages of having it in ACO are not that distinct, but perhaps it will be beneficial when seen in a bigger picture? At least I don't notice any breakage either.

[pendingchaos]

GS isn't really used that often, so the effect isn't as large as using ACO for VS, FS or CS shaders.

[baryluk]

Once the GS (and the dependent MRs) is upstreamed, would it be possible to compile Mesa or at least RADV without LLVM maybe? (loosing possibly decompilation support, which is mostly useful for debugging right? Or it is also used for other things like shader compiler feedback?).

[pendingchaos]

Besides GS, there is still tesselation shaders and GFX6 which currently fall back to LLVM. There are also some features which are safe to disable when ACO is used but are needed for feature parity: 8/16-bit types and NGG

After all that, we use LLVM's disassembler for GFX8+. So an alternative would need to be found or disassembly would have to be disabled (not a huge loss though, it's mostly useful for debugging and RenderDoc)

If it were possible to compile RADV without LLVM, llvmpipe and radeonsi would still need LLVM

[baryluk]

@pendingchaos Yeah, I know tesselation shaders still need LLVM.

Not having disassembler is fine for normal users.

But yeah, it is not practical to just RADV, but not radeonsi for some other stuff.

Well, once radeonsi uses aco, it is probably worth looking into it again :)

Thanks.

[pendingchaos]

Geometry shader support (without NGG) has been upstreamed.

GFX6 support has also been upstreamed and should be in this repository when it's rebased