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

[phoronix]

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

Prolific ACO shader compiler back-end developer Timur Kristóf has managed to land his latest improvements in Mesa 20.1-devel for this alternative to the AMDGPU LLVM back-end supported so far by the RADV Vulkan driver...

http://www.phoronix.com/scan.php?page=news_item&px=RADV-ACO-TES-Control-Eval

[CochainComplex]

I have also checked out this patch before it merged officially and I was not able to notice any regeressions. Maybe some performance benefits in certain situations. But I have no data to support my impressions.

p.s.: Michael it would be nice to have this https://www.phoronix.com/scan.php?pa...-feb2020&num=1 Benchmark in an "kinda pinned version" ..where you just keep the baseline and add new "snapshots" to it. The snapshots could be timebased (snapshot after each month) or after major changes like the tesselation support with aco or release. Basically what you did but in a continuesly updated version.

I remember that I have seen this for Clear Linux but I can not find it anymore. Benchmarks each week(?) for current version at the give point in time over a timeline of 2 years it was very insightfull because major changes like switching to newer gcc could be identified very easily.

[TemplarGR]

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.

[CochainComplex]

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.

Maybe defaulting it wouldn't be too early by 20.1. What I have seen sofar and not only in my personal case is that a lot of users are already using it by default and have zero to almost non existing issues. Furthermore switching it to default now will unveil the few not working cases. But for me ACO is one of the most stable experimental feature I have ever seen. ...perhaps more stable then 5700XT's win driver official stable stack

[mphuZ]

Great. The faster it is finalized and implemented by default, the faster AMD will think about implementing it in AMDVLK.

[mphuZ]

Timur Kristóf:

The aco-tess branch is now merged. It should give you guys equal functionality to what you currently get from LLVM, and it should work accross all supported hardware, GFX6-10.

Unfortunately it is currently slightly less efficient than the LLVM implementation. We'll improve it by adding support for shader I/O in the NIR load/store vectorizer. We are also looking into making it use less LDS space (for the sake of sanity, I used the same LDS layout as LLVM, for the initial version).

[ms178]

Great. The faster it is finalized and implemented by default, the faster AMD will think about implementing it in RadeonSI.

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

[FireBurn]

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

[mphuZ]

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

AMD refuses the proprietary compiler and will use LLVM on all systems . Is it not possible to use LLVM and ACO together? To begin with , the ACO needs to be fully refined, and then look at the situation.

[R41N3R]

Great, I hope as well that ACO gets soon enabled by default for RADV. It works much better and avoids a lot of stuttering!

For OpenGL it remains to be seen if ACO will be further developed for it. I hope there will be a well working OpenGL to Vulkan translation in the not too distant future, not necessarily as fast as radeonsi, but fast enough for most use cases.