Running The RadeonSI NIR Back-End With Mesa 19.1 Git

[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

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

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

[smitty3268]

Thanks Michael. Sounds like NIR support is in pretty good shape.

[tarceri]

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

[Marc Driftmeyer]

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

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

[R41N3R]

I didn't expect performance increases yet, but great to see it is that mature already. I use since 2 months NIR in all OpenGL games with RadeonSI and Mesa git and I didn't find any issue so far. Would be quite interesting to know a time line when this might become the default.

[pal666]

the only test with less than 60 fps is faster with tgsi, so it's not ready to be enabled by default

[xxmitsu]

You should be able to get that from the build logs on Launchpad.net for the Padoka PPA. Unfortunately the Padoka PPA doesn't report the hash to the Mesa version string.

Oh, from what I could find it seems that mesa build is about ~ a week old (808bf59). It seems that is missing some important NIR work done by Kenneth Graunke and Timothy Arceri.

[Michael]

Thanks for doing those Michael!
Can you please tell me the sha from which the mesa was build?

You should be able to get that from the build logs on Launchpad.net for the Padoka PPA. Unfortunately the Padoka PPA doesn't report the hash to the Mesa version string.