libGL error: failed to load driver: swrast ??

[Astara]

Many (though not all that I can tell) of my X11-programs that seem to link with libGL from the libglvnd package emit the error "libGL error: failed to load driver: swrast" before they then go on and seem to work normally.

These are programs like several of the GL type progs like glxspheres as well as non-3D type programs like the 'xconfig' GUI linux kernel configuration program (!go figure!).

I can't tell, however, exactly which library or program has the above message in it. It might be it's pulled in from some multi-language message lib from a specific error code, as I see it looking through locale files as part of glxspheres' startup.

I see it trying to load what looks like possible driver libs from /usr/lib64/dri/... and in that dir I see several .so files including a swrast_dri.so, which seems to be a duplicate of a few other files like kms_swrast_dri.so, radeonsi_dri.so and virtio_gpu_dri.so, with 6 other files in that directory appearing to be hard-links to the same file. Maybe a generic catchall type driver?

Anyway, not sure what the impact is as the programs I've seen issuing this message appear to work correctly, as far as I know. The glxspheres prog seems to get about 30 frames/sec (1/2 my monitor sync rate) which is what I set my desktop for in the Nvidia 3D settings.

FWIW, other messages when I start glxspheres: Polygons in scene: 62464 libGL error: failed to load driver: swrast Visual ID of window: 0x2c6 Context is Indirect OpenGL Renderer: GeForce RTX 2080 Ti/PCIe/SSE2

So I'd like to find out 1) what (if anything) I'm missing by not having that driver load (as the progs seem to mostly work) 2) how I might get it to load if it should be loading 3) how I can shut up that message, "selectively", (i.e. not sending all graphic programs' output to /dev/null)

Of course this assumes it has anything to do with your libs, and that you know anything about this message ( :-) ).

If not, well very sad, it's been this way for a "while" -- and it seems to be mostly a cosmetic problem, but hoping you might have a clue?

Thanks for anything! ;-) A*a

[kbrenneman]

Note that libglvnd is hosted on Freedesktop now, so any bug reports should go here: https://gitlab.freedesktop.org/glvnd/libglvnd

That message is from Mesa, not from libglvnd. That means it's not using the NVIDIA GLX client library (which might mean that the NVIDIA driver isn't installed, or that the system is misconfigured in some way). It ends up trying to use Mesa, but then Mesa can't find its software renderer, so it has to fall back to indirect rendering. It's surprising that anything with GLX even runs at that point, since most distros disable indirect rendering by default.

But, I can't really speculate about the underlying problem without knowing more about that system -- distro, version, driver versions, etc.

[Astara]

On 2021/01/13 08:45, Kyle Brenneman wrote:

Note that libglvnd is hosted on Freedesktop now, so any bug reports should go here: https://gitlab.freedesktop.org/glvnd/libglvnd

That message is from Mesa, not from libglvnd. That means it's not using the NVIDIA GLX client library (which might mean that the NVIDIA driver isn't installed, or that the system is misconfigured in some way). It ends up trying to use Mesa, but then Mesa can't find its software renderer, so it has to fall back to indirect rendering. It's surprising that anything with GLX even runs at that point, since most distros disable indirect rendering by default.

But, I can't really speculate about the underlying problem without knowing more about that system -- distro, version, driver versions, etc.

Sorry for the delay, got interrupted twice in writing this...sigh

But to answer some of your questions...

Distro: Well, the program is running on a butchered version of Opensuse tumbleweed (their 'rolling release'). I say butchered, because I had a disk crash last spring that has caused me to get out of sync with their current version -- which is being difficult to upgrade to because they changed the rpm format.

Why does Mesa put out an error message saying 'libGL: failed ...' instead of 'Mesa: failed...'? That's certainly misleading.

FWIW -- I am running the program on the linux server (which has no dedicated graphics card). It is displaying on my Windows7 desktop running Cygwin-X.

Windows is where it is finding the Nvidia card, so I'm using 'X' running on Windows to create the display window, and the program is remotely using the OpenGL features on the graphics card that is running on my desktop.

I thought that was why it was displaying that it was running in an "Indirect Context".

When you say it sounds like the nvidia driver isn't installed -- isn't installed where?

Windows has an Nvidia driver installed (or alot wouldn't work) and I can use OpenGL as well as DirectX.

The server does NOT have an Nvidia driver installed, because it doesn't have a graphics card. It can only use remote OpenGL calls.

That's why I'm a bit confused by the can't load driver swrast message, since I'm not sure what what it is supposed to be doing. As I mentioned there is a swrast.so in the dri directory.

That's sorta what I thought the libglvnd was for -- to redirect the opengl calls to the "right" driver (a remote one).

Isn't Mesa a SW-implementation of OpenGL that would be used if I wasn't using a graphics card to render?

If this should be reposted or forwarded to the other location you mentioned, feel free to forward, or let me know I should re-submit this there.

Thanks for any clues! :-)

[kbrenneman]

Mesa's swrast is a software implementation of direct rendering, not indirect. For this explanation, remember that in X11, the server is the X server, which in your case is Cygwin-X running on Windows. The client is the application, in your case running on Suse.

With direct rendering, the client itself can execute all of the GLX rendering commands. That means it can directly talk to the GPU (if it's using one), and it can directly access the memory that the application uses for meshes and textures and so on, and it can draw the result directly into the buffer that contains the window contents. There's a bunch of different things that allow that to work (and I can point you at the documentation for them if you're interested), but for this discussion, the important thing is that both the client and server have to be on the same computer, and the client and server have to be using a matching driver.

That's what libglvnd does -- the client asks the server for a driver name, and then tries to load the client-side driver that matches, so that direct rendering can work.

If the client and server are not running on the same computer, then it has to use indirect rendering. Indirect rendering works much the same way as normal X11 drawing: The client sends drawing commands to the server, using a standard protocol, and then the server executes those commands. In this case, it doesn't really matter which driver libglvnd loads, because they all speak the same GLX protocol.

Mesa's "failed to load driver" message is when Mesa tries to load swrast, but swrast can't run because it can't do direct rendering.

The "libGL" prefix is left over from before libglvnd existed, when that part of Mesa would have been libGL.so. The message just never got updated.

[Astara]

On 2021/01/18 08:33, Kyle Brenneman wrote:

In this case, it doesn't really matter which driver libglvnd loads, because they all speak the same GLX protocol.

Yes, that's why I wondered why it was trying to load swrast. There is no 'dri' interface for talking to the onboard graphics card -- not even VESA compatible, but barely providing VGA compatibility. I can use up to 1024x1280 but only in 16-bit color, so in graphics mode only a 1024x768x32 and below is available, with it barely usable as a text console.

Mesa's "failed to load driver" message is when Mesa tries to load swrast, but swrast can't run because it can't do direct rendering.

---

Ahh...that's one reason why I wondered about the message. I didn't see why it would need a driver for talking over the network.

The "libGL" prefix is left over from before libglvnd existed, when that part of Mesa would have been libGL.so. The message just never got updated.

---

Yeah, not uncommon.

So maybe what I really need is to figure out how to tell the

configure the remote client not to try any local drivers.

 Thanks for pointing me in the right direction!

A*a

[kbrenneman]

Libglvnd still has to pick a vendor library to use. Libglvnd just forwards function calls from the application to the vendor library (in this case, Mesa), and the vendor library is responsible for handling the GLX protocol for indirect rendering.

That error message itself is harmless, though, so you can safely ignore it.

[aaronp24]

While the error message is harmless, if you really want to try to get rid of it I think you can tell Mesa to skip trying to load swrast completely by setting LIBGL_ALWAYS_INDIRECT=1 in the environment.

Just to correct an earlier point: I think in theory if Mesa could actually find its swrast renderer, it would be able to use it to do "direct" rendering even without being on the same computer as the X server. It does local software rendering and then sends the images to the server through indirect X protocol.

[kbrenneman]

Huh, it looks like Mesa does have something that would go through XPutImage or XShmPutImage. I'd have to read through it more to see how that works.

That does bring up a possible alternative, though. If you want to let Mesa use direct rendering, but you want to display on a remote system, then VNC would give you that arrangement. Depending on that application, VNC might be faster than indirect rendering, too.

[Astara]

On 2021/01/19 11:02, Kyle Brenneman wrote:

Huh, it looks like Mesa does have something that would go through XPutImage or XShmPutImage. I'd have to read through it more to see how that works.

That does bring up a possible alternative, though. If you want to let Mesa use direct rendering, but you want to display on a remote system, then VNC would give you that arrangement. Depending on that application, VNC might be faster than indirect rendering, too.

VNC? That's sorta overkill -- i.e. doesn't that replace the whole desktop? That would prolly be slower for my purposes.

Right now, I use a Win7-Aero desktop, and bring up individual progs in windows.

I can get about 30FPS (depends on complexity, but doesn't seem network bound) on a 1Gb net.

XPutImage or XShmPutImage... not sure what they do...but not going to worry too much. Still, doesn't the swrast driver still need a dri compatible graphics card in the client (where glxspheres is running)?

I mean, that makes no sense in my case, as it still needs to render on my local X+GLX server (Win desktop) -- that's where the graphics card is, so trying to render on the server would seem to be slower.

Well, the "export LIBGL_ALWAYS_INDIRECT=1" seems to suppress the swrast loading attempt -- and that's really all I was trying to do in trying to file this 'issue'.

Thanks much!