RADV ACO Can Now Handle More Shaders With Mesa 20.1-devel

[Venemo]

Great news! ACO pipeline is finally complete! I think it would be great if it was enabled by default but in my opinion 20.1 is too soon, perhaps some extensive testing in the following months and making it default in 20.2 or 20.3 would be better.

We'd like to reach feature parity with LLVM first. Then we'll see when is the right time to make ACO the default.

Fixed it for you, as it surely won't happen for AMDVLK (as it is more tied to LLVM and also needs to serve compute which is a non-goal for ACO).

ACO already supports Vulkan compute shaders.

Hopefully once they've added everything they need for RADV they'll go back and switch radeonsi over to ACO for OpenGL

This is one of my goals, but it's not as trivial as it sounds.

[ms178]

ACO already supports Vulkan compute shaders.

Let me re-phrase, I meant that AMD uses LLVM not only for AMDVLK but also for their compute stack and as I understood it, the idea of ACO was to focus more on the workloads and optimizations which were important for better game performance [but that would conflict with AMD's need to serve also the compute stack]. And as AMD doesn't want to maintain a game-focused compiler and a compute-focused compiler in their driver stack, we probably won't see ACO in AMDVLK, at least anytime soon. But maybe AMD will revisit this decision, I don't know. It's up to the AMD people to decide if that would make sense or not. As they just announced serving both markets with different architectures going forward, at least I could think of the possibility that this decision might change in the future.

But for now, RadeonSI is probably getting ACO way sooner. And I wish the best of luck to all developers involved to get there. ACO has earned the praise of the community already and I hope we will see similar improvements on the OpenGL side as well with it.

[mphuZ]

the idea of ACO was to focus more on the workloads and optimizations which were important for better game performance [but that would conflict with AMD's need to serve also the compute stack]. And as AMD doesn't want to maintain a game-focused compiler...

Then answer a simple question. If AMD doesn't want to implement ACO, why are they implementing it in radeonsi (OpenGL)?
I will remind you that the OpenGL driver in Mesa is" official " for AMD and they directly support it. And it's also worth adding that AMD wants to completely get rid of closed drivers and switch to an open graphics stack.

So there is either some discrepancy, or AMD has already decided to use ACO in all its drivers (OpenGL and Vulkan).

[ms178]

Then answer a simple question. If AMD doesn't want to implement ACO, why are they implementing it in radeonsi (OpenGL)?
I will remind you that the OpenGL driver in Mesa is" official " for AMD and they directly support it. And it's also worth adding that AMD wants to completely get rid of closed drivers and switch to an open graphics stack.

So there is either some discrepancy, or AMD has already decided to use ACO in all its drivers (OpenGL and Vulkan).

I didn't say that AMD is opposed to ACO per se and the AMD devs are in a better position to answer their stance on ACO and the usefulness to them (and there were some critical comments from AMD devs on this topic in past debates), but RadeonSI is AMD's open source OpenGL driver on Linux whereas AMDVLK shares a lot of code with the Windows driver and they also use LLVM there which also needs to serve more purposes next to gaming on that stack. They also didn't want to maintain a second compiler as they would need to carry on with LLVM on that stack anyways. There is no such limitation with RadeonSI as it is used solely on Linux, ACO could evolve to become the compiler for Linux desktop graphics in both OpenGL and Vulkan and would be maintained by both AMD devs and the Valve/Google sponsored developers to bundle the manpower on the job.

If I remember correctly the AMD devs would have preferred that Valve (which sponsors ACO) invested into making LLVM better instead, but there were a couple of technical reasons why this route was not chosen in the end.

[theriddick]

I would LOVE to see RADV/Vulkan for AMD work better at 1080p and 1440p resolutions (mostly fine at 2160p). As we saw in the recent benchmark results, it really suffers at lower resolutions (which could be incorrect?).

[pal666]

Then answer a simple question. If AMD doesn't want to implement ACO, why are they implementing it in radeonsi (OpenGL)?
I will remind you that the OpenGL driver in Mesa is" official " for AMD and they directly support it. And it's also worth adding that AMD wants to completely get rid of closed drivers and switch to an open graphics stack.

So there is either some discrepancy, or AMD has already decided to use ACO in all its drivers (OpenGL and Vulkan).

you confused many things here. 1) what makes you think amd is impelenting aco in radeonsi? 2) amdvlk is not closed driver 3) radeonsi and radv are linux drivers, they are very far from "all amd drivers"

[mphuZ]

They also didn't want to maintain a second compiler

But they will have to support the second compiler. radeonsi is their main OpenGL driver in the future. If there is an ACO in it , and an LVM in AMDVLK , then they will have to break.

you confused many things here. 1) what makes you think amd is impelenting aco in radeonsi? 2) amdvlk is not closed driver 3) radeonsi and radv are linux drivers, they are very far from "all amd drivers"

1. ACO developers say so themselves. The above has already been answered: "This is one of my goals" (Venemo)
2. Yes, I know. I'm talking about AMDGPU-PRO. AMD wants to completely switch to open drivers (OpenGL and Vulkan). What this will look like is not very clear yet, since their main OpenGL driver is in Mesa, and the Vulcan driver is in AMDVLK...
3. Yes. But RADV is not their driver. They only support AMDVLK.

[pal666]

But they will have to support the second compiler. radeonsi is their main OpenGL driver in the future. If there is an ACO in it , and an LVM in AMDVLK , then they will have to break.

"they" are different people. amdvlk is windows driver

1. ACO developers say so themselves. The above has already been answered: "This is one of my goals" (Venemo)

aco developers are valve, not amd

2. Yes, I know. I'm talking about AMDGPU-PRO. AMD wants to completely switch to open drivers (OpenGL and Vulkan). What this will look like is not very clear yet, since their main OpenGL driver is in Mesa, and the Vulcan driver is in AMDVLK...

amdgpu-pro is also open driver

3. Yes. But RADV is not their driver. They only support AMDVLK.

ok, but doesn't it reinforce my point? "all amd drivers" include windows and console drivers, where most of their revenue comes from

[ms178]

But they will have to support the second compiler. radeonsi is their main OpenGL driver in the future. If there is an ACO in it , and an LVM in AMDVLK , then they will have to break.

Yes, I think AMD has the intention to phase out AMDGPU-PRO in the long run, and they do need to support both LLVM (for AMDVLK and Windows anyways) and ACO (for their Linux stack) eventually. But at least when it comes to ACO it is Valve sponsoring three developers who do the majority of ACO work, also for RadeonSI as Venemo said (he is one of the ACO developers). So it is still a win of manpower for AMD for RadeonSI (and hopefully the same improvements for us users of it).

I think you haven't realized the part about the other needs LLVM has to serve for AMD yet. Also ACO is not feature-equivalent to LLVM and they already stated that OpenCL is not a goal for them to serve with ACO. In limiting the scope of ACO with the focus on desktop gaming, they can optimize this compiler for these workloads (compile time, memory footprint etc.) while LLVM also has to serve other workloads where other technical decisions and trade-offs might prevail.

[TemplarGR]

But they will have to support the second compiler. radeonsi is their main OpenGL driver in the future. If there is an ACO in it , and an LVM in AMDVLK , then they will have to break.



1. ACO developers say so themselves. The above has already been answered: "This is one of my goals" (Venemo)
2. Yes, I know. I'm talking about AMDGPU-PRO. AMD wants to completely switch to open drivers (OpenGL and Vulkan). What this will look like is not very clear yet, since their main OpenGL driver is in Mesa, and the Vulcan driver is in AMDVLK...
3. Yes. But RADV is not their driver. They only support AMDVLK.

Technically, RADV/AMDVLK/radeonSI and whatnot, are not drivers. AMDGPU is the driver. The rest are API implementations.

Also, to add to the discussion, i think both compilers will co-exist in the foreseeable future. ACO can focus on gaming workloads and eventually become the default (since the vast majority of MESA users are just multimedia/gamer users). LLVM can still be maintained for other uses and as an alternative in case of bugs. There is room for both in my opinion.