Comment 1 Pierre Ossman 2021-10-13 14:10:52 CEST

Also note that indirect rendering has been disabled by default since 4.10.0 and so far we haven't had any support issues asking how to re-enable it. So long term it might be easier to completely remove indirect rendering support.

Comment 2 William Sjöblom 2021-10-14 11:27:58 CEST

Note that mesa has dropped support for the legacy swrast in version 21.0 and that we are now required to either transition to llvmpipe or drop support for indirect rending entirely. Thus, this bug blocks a future upgrade of mesa.

Comment 4 Pierre Ossman 2021-12-23 13:00:05 CET

(In reply to Pierre Ossman from comment #1)
> Also note that indirect rendering has been disabled by default since 4.10.0
> and so far we haven't had any support issues asking how to re-enable it. So
> long term it might be easier to completely remove indirect rendering support.

TurboVNC has completely stripped out indirect rendering from their server in their 3.0.0 release.

Comment 5 Pierre Ossman 2024-06-07 13:50:52 CEST

That was apparently a bit of an exaggeration. TurboVNC has simply forced indirect rendering permanently off. The rest of the GLX code is just as before, which means it likely still requires swrast or llvmpipe to function.

Comment 6 Pierre Ossman 2024-06-07 13:57:05 CEST

For some odd reason, direct rendering still requires GLX support in the X server. I don't really understand why, as the application will render everything on its end, and upload the result using a normal PutImage request. I see no need for any GLX support for that.

After experimenting, what's needed are GLX visuals and fbconfigs that match what the direct rendering driver supports, and the visuals in the X server. Perhaps Mesa is too lazy to do this mapping itself and assumes it will be available from the X server, and that's why it requires GLX?

Prototype of this available here:

https://github.com/CendioOssman/tigervnc/tree/nodri

Only tested with glxinfo and glxgears. More fbconfigs might be needed, as the list is way shorter than the one swrast provides.

Note that it gets higher priority than the original swrast provider, which might not be what we want. At least not if we want to upstream things. Ideally, it tries the swrast approach first, falling back to this dummy driver if that fails.

Upstream in this case might be Xorg, rather than TigerVNC.