Running The RadeonSI NIR Back-End With Mesa 19.1 Git

[Veto]

I feel sorry for the Windows AMD OpenGL driver. Getting destroyed so hard must hurt

Maybe at some time AMD can switch their windows driver to Mesa? Either by using Zink (Gallium over Vulkan) or by making an AMDGPU windows driver. After all, code sharing was an argument for DC/HAL anyway.

[theriddick]

And yet no one cares in the Windows world as games use DirectX and not OpenGL.

Well No Mans Sky somehow runs decent under windows and OpenGL, so I dunno.

[nuetzel]

I'm pretty happy with these results. There are still a number of known optimisations missing for the NIR backend vs the TGSI backend.

Note:
It was tested with Vega, here.
I see one little triangle corruption under UH with Polaris 20 (RX580). - Marek know that.
The above corruption is FIXED with current Mesa git + Marek's latest SDMA patches.
BUT sadly reliable _whole_ system hang under UH and UV with my Polaris 20 (Nitro+) => VM faults (I've to dig.)

Kernel:
latest 'amd-staging-drm-next' 0bf64b0a9f7850809c4da2fafce36d1504cc28d9

Mesa git:
49397a3c840b38f8c65705dd05d642c0beb4dea9 plus

c459985765e (HEAD -> master) radeonsi: use SDMA for uploading data through const_uploader
0039866bee8 gallium/u_upload_mgr: allow use of FLUSH_EXPLICIT with persistent mappings
bb3dfd0b68c gallium/u_threaded: always unmap const_uploader
78a5adca84d st/mesa: always unmap the uploader in st_atom_array.c
0a5446396fc winsys/amdgpu: cs_check_space sets the minimum IB size for future IBs
c60e63f5eb1 winsys/amdgpu: clean up IB buffer size computation
f63402c437f winsys/amdgpu: remove occurence of INDIRECT_BUFFER_CONST
a7540f5aa48 winsys/amdgpu: use a separate fence list for syncobjs
f5340535a1c winsys/amdgpu: unify fence list code
6c93ed58404 winsys/amdgpu: don't drop manually added fence dependencies
0146f9a0e00 radeonsi: fix EXPLICIT_FLUSH for flush offsets > 0
59f6cec379b gallium/u_threaded: fix EXPLICIT_FLUSH for flush offsets > 0
22335474274 radeonsi: re-initialize query buffers if they are reused

[geearf]

Congratulations to the devs, it's not finished and yet already faster!
It'd be awesome if the min could also be higher than with TGSI of course.

Is the support of OGL 4.5 complete with NIR already?

[cb88]

Well No Mans Sky somehow runs decent under windows and OpenGL, so I dunno.

Probably because it also Targets PS4 and Xbox both of which have Radeon GPUs so they target the compatible subset of OpenGL instead of trying to optimise for Nvidia etc... its just optimized more generally.

[Dukenukemx]

And yet no one cares in the Windows world as games use DirectX and not OpenGL.

Emulators tend to use OpenGL like CEMU, YUZU, and Citra. Which all run like crap on AMD in Windows due to poor OpenGL drivers. Run these emulators on Linux and the performance is far better.

[cb88]

I tested NIR with the Superposition 1080p extreme benchmark and RX570:

Original R600_DEBUG=nir
1867 1878 points
13.97 14.05 avg fps

No reason to use R600_DEBUG=nir.

You should also log CPU usage during the run...

[clapbr]

You should also log CPU usage during the run...

this. you don't even know if that testcase is CPU-bottlenecked for you and assumed wrong stuff as usual

[nuetzel]

Note:
It was tested with Vega, here.
I see one little triangle corruption under UH with Polaris 20 (RX580). - Marek know that.
The above corruption is FIXED with current Mesa git.

Yes, this is SOLVED with NIR, even on Polaris. - GREAT.
(Have to bisect for the right commit.)

Marek's latest SDMA patches.
BUT sadly reliable _whole_ system hang under UH and UV with my Polaris 20 (Nitro+) => VM faults (I've to dig.)

Reverting the SDMA patches (1-4) on Polaris SOLVED this.

[Strunkenbold]

Can confirm. Those sdma patches immediately freeze the whole system. Even if it's just the desktop.