Open daniel-schuermann opened 4 years ago
So, sorry for the delay. Now, I rebased and GFX6 and GS should also work for those using the valve ppa.
To those interested: I've started the work on tessellation support for ACO. There is a branch here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3964 which should work accross all devices, although so far I've tested with Polaris and Navi. Feedback is welcome, in case anyone wants to check it out.
I'll give it a test later today. Can it be merged on its own for testing, or some other MRs are needed as well?
@shmerl It doesn't need to be merged with anything, you can just checkout the aco-tess
branch on my gitlab.
@shmerl Fair warning: I checked, and it doesn't improve the frame rates of The Witcher 3 on Navi. Just saying.
I'll check, at least to confirm that it doesn't hang :) Also, I suspect framerate impact can be somewhat resolution specific, at least I already encountered such comparisons in the past.
I will be giving it a test on Vega hardware.
@Venemo: posted a result in benchmarks thread (#36). As you anticipated, no performance improvement for TW3, but all worked well in general. llvm11 still has a performance regression.
@shmerl Thanks for taking a look. There is still some room for optimization, and some of that might still happen within that MR. But it's already a massive changeset with ~30 commits so right now the main focus is to get it integrated. I think it's a big step that ACO can now handle all stages, at least.
The build with aco-tess mesa seems to be failing on my end due to warnings becoming errors. This happening on your end?
Bah, just int-conversion warnings from the mesa aco-tess branch somewhere in the gentoo mesa-9999 ebuild. Applying the branch diff to master works fine for me.
@Venemo : what would be the next focus after it's merged, performance optimizations or plumbing aco for OpenGL?
@shmerl Right now we're focusing on closing the feature gap between ACO and RADV's current LLVM backend. This includes 8/16-bit support (storage and I/O), tessellation and a few other things.
Plumbing ACO into RadeonSI (the OpenGL driver) is also something that I'd like to do, but it's not as trivial as it sounds. First, we need to take some steps to unify how RADV and RadeonSI do some things.
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).
Do you plan to start working on OpenGL support in aco soon, or that's not yet scheduled? It would be good to avoid hangs caused by llvm with radeonsi.
Do you plan to start working on OpenGL support in aco soon, or that's not yet scheduled? It would be good to avoid hangs caused by llvm with radeonsi.
Yes, but it doesn't have the highest priority. For mesa-20.2, there isn't much more to be expected as it's around the corner (We'll try to get NGG GS in, though). For mesa-20.3, we've currently only planned to add float16 vectorization, but at least some radeonSI work (e.g. compute shaders or maybe more) is likely. Then, there is also the RT-extension which is good chunk of work and we should get started rather sooner than later to not lag too far behind :)
What would need to be done in order to get image support in clover for radeonsi? I've heard it needs aco
@darkbasic It doesn't need ACO, and there is already an open MR for it: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7231
Are there any news / updates on plans or on-going work on ACO for radeonsi? Recent GPU hangs likely caused by radeonsi+llvm kind of reminded me about this.
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:
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)