"vboxvideo does not export required DRI extension"

[Jacob Godserv]

KDE4.3 is unable to enable its effects because Composite is not accessible in X. In X logs, these errors occured:

(EE) AIGLX error: vboxvideo does not export required DRI extension
(EE) AIGLX: reverting to software rendering

I will attach complete logs of my (still running) virtual machine, which is running on PUEL 3.0.4, with matching PUEL Guest Additions.

[Jacob Godserv]

Xorg.0.log of a still-running X session.

[Jacob Godserv]

Still-running virtual machine's log

[Michael Thayer]

Our DRI support is still not done properly, and fails in a number of cases. This will be fixed at some point, but of course I can't say exactly when.

[dterrahe]

This looks very similar to what I've been struggling with over a whole range of vbox versions. I eventually concluded something must have got messed up in my Vista 32-bits installation, but even on a fresh Windows 7 64-bits install with 3.1.4 and a fresh Fedora virtual machine (versus Debian previously) I had the exact same problem. The host has an nVidia 8600M GT and drivers 195.62 (but a long list of previous drivers "worked" identical).

The vboxvideo drivers seems to happily initialise DRI, but then switches to DRISWRAST anyway.

One difference in the log file is that I have a line

(II) AIGLX: Screen 0 is not DRI2 capable

a little bit before the

(EE) AIGLX error: vboxvideo does not export required DRI extension

It happily drmOpenDevice s /dev/dri/card0 in between though.

Is this something I could help with? If not all cases are handled correctly, could I try skipping a test that now fails to see if there are any further problems? Not sure which source file I would have to look in though. I assume it is in Guest Additions, since the host log file doesn't show anything suspicious.

[Markus Laker]

I have the same problem as dterrahe, along with generally sluggish screen updates. I'd be pleased to help if there were any tests I could run.

[Leonid Lobachev]

The error message is expected, it's done specifically to disable loading of vbox fake dri driver by aiglx as it's not working quite fine with it yet.

[dterrahe]

Then what should I do to get 3d acceleration working? I understand it should work on Win7-64/nVidia host hardware?

Should aiglx be disabled? How?

[Leonid Lobachev]

It wouldn't work with KDE's Kwin manager yet if you have same problem as it was stated in ticket description. Overwise, please provide host log, and run your app on the quest with CR_DEBUG_FILE=crlog.txt and provide that file as well.

[dterrahe]

I disabled aiglx using

Section "ServerFlags"

Option "AIGLX" "Off"

EndSection

which made the (EE) error lines in the log disappear, but it still loads the DRISWRAST driver.

Obviously, if the xorg log shows that no hardware acceleration is available, then neither kwin compositing, nor compiz nor glxgears will be accelerated? Which still leaves me wondering if this ever works for anybody with an nvidia host and what settings (xorg.conf or otherwise) are required.

Not sure how to get CR_DEBUG_FILE=crlog.txt to work. It seems no log file is generated when I put this in front of the glxgears command.

[Leonid Lobachev]

You should *NOT* disable AIGLX... that's why you don't see logfile.

"Obviously, if the xorg log shows that no hardware acceleration is available, then neither kwin compositing, nor compiz nor glxgears will be accelerated?" That's wrong.

Kwin would *NOT* work regardless.

[Leonid Lobachev]

Also...you're using fedora which might be the problem. Try some fresh guest ubuntu install to see if it's related to your host or not. You'd see exactly same error in the X log, but compiz/glxgears/glxinfo should work fine there.

[dterrahe]

Many thanks. I know that kdm will not work, which is why I was testing with glxgears and the test was with AIGLX reenabled. I found it very counter-intuitive that with the errors in the log file and the explicit mention that a software rasteriser is loaded, that there would still be accelerated 3D. My main install is actually debian unstable, but since it has seen many config changes I also tested with ubuntu and fedora in the past. This never gave me working 3d acceleration, but I now did a fresh ubuntu 10.04 64bit install, added guest-additions and mesa-utils and now glxgears is accelerated, for the very first time! It seems recent (since the last time I used ubuntu to test) changes have improved the situation for my system.

I'm attaching the xorg.log of this session for those who are struggling with the same problem and to make it clear again, this is from a session with working 3d and the errors are therefore no cause for concern.

I will now try to figure out how to fix my debian setup. I'm also using it in a dual-boot configuration with the nvidia drivers to access the hardware directly. nVidia is doing some diverting of lib files, meaning I have to explicitly instruct xorg to load its modules from /usr/lib/nvidia (where the original mesa files have been moved to). The confusing error messages in the log kept me looking in the wrong direction when the real remaining problem was apparently caused by glxgears loading the wrong libGL.

[dterrahe]

Xorg log from fresh ubuntu 10.04 install with working 3d acceleration.