Need help with rasterizer selection issue

Greetings,

I am an experienced software engineer, but I have no experience whatsoever with OpenGL, Glut, GLEW, DRI, Mesa, or pretty much anything related to graphics. (This stuff is just not my forte.)

Despite my abundant ignorance, have decided to jump into the deep end of the pool and try to solve a rather annoying problem. The problem has been discussed in this thread:

xbmc very slow when run as non-privileged user

In a nutshell, XBMC is getting the wrong rasterizer (the software rasterizer) whenever it is run under the UID of any non-root user. The result is that it is slower than molasses in January, and essentially unusable for any and all non-root users. There is quite obviously a permissions problem somewhere, but where, exactly? I haven’t a clue, but hope somebody here will be kind and pass me one.

I am no stranger to debugging sizable software systems. I know how this is going to go. Somewhere, in some routine in some piece of code, there is a fork in the road. At that fork, if you are logged in as root, you go left. Otherwise you go right. I know that if I can just find the location of that place, i.e. which hunk of software, and which source file, and which function, then I will be 99% of the way to solving the problem.

So, can anybody here be so kind as to tell me where, exactly, the decision is made as to which rasterizer will be used? If so, I would be eternally grateful.

Thanks in advance for any and all assistance.

Falling back to the Mesa soft-pipe simply means that you don’t have a DRI enabled (or otherwise direct rendering capable) kernel module for your GPU installed and/or X.org can’t deal with it due to a faulty Xorg.conf. In earlier days, when X.org didn’t choose almost anything you need to use acceleration out the box, this was common.

What GPU is installed in your system and which Debian version are you on?

[QUOTE=thokra;1243797]Falling back to the Mesa soft-pipe simply means that you don’t have a DRI enabled (or otherwise direct rendering capable) kernel module for your GPU installed and/or X.org can’t deal with it due to a faulty Xorg.conf. In earlier days, when X.org didn’t choose almost anything you need to use acceleration out the box, this was common.

What GPU is installed in your system and which Debian version are you on?[/QUOTE]

OK, please allow me to make several points that I apparently failed to be clear about:

  1. I do have DRI enabled. It is working just fine as long as it is used from the root account (but not otherwise).

  2. I have already placed the following into my xorg.conf file:

Section “DRI”
Mode 0666
EndSection

(I also and additionally manually set the mode on /dev/dri/card0 to 0666, but that also did not seem to help at all.)

  1. The problem is apparently not related to any one specific GPU. I have seen the exact same problem on two different systems with two radically different GPUs from two different manufacturers (Intel and AMD). For this reason, I do believe that your question about the type of GPU I have is most probably irrelevant.

  2. When I have encountered the problem in question, I have not been running any version of Debian, nor even any version of Ubuntu, Fedora, Mageia, or Mint Linux, nor for that matter any form or flavor of Linux whatsoever. I encounter the problem when running on FreeBSD, although if you look at the thread that I provided a link to, you will see another party has reported the exact same problem also under Linux.

Now that I have all of the above out of the way, can you help me to find the fork in the road or not?

I ask again: Where is it decided which rasterizer to use?

You can best help me by providing that information.

Thank you.

[…]can you help me to find the fork in the road or not?

Nope, don’t know about and thus can’t help you with FreeBSD.

NEVERMIND!

I just had not one but two of those Duh! moments.

First, after looking into this problem some more (which I only got time to do today) I realized rather quickly that THIS web site (www.opengl.org) is about discussions and so forth relating to OpenGL generally, and presumably as an API, independent of specific implementations, and thus my question was inappropriate here, given that I actually needed internals info for the specific implementation that I happen to be using (which happens to be Mesa).

Second, upon spending only a short while digging down into the Mesa source code (and turning on relevant debugging flags and such) it didn’t take me that long to realize the root of the problem. Long long ago, I had added the following to my ~/.login file (although I had completely forgotten about this):

cause gthumb to avoid using dri-7.4.4 (and thus avoid segfaulting)

setenv LIBGL_ALWAYS_SOFTWARE 1

This was, of course, supposed to have been a short term work around for what I had hoped would be a temporary bug in a different application. But I forgot about it entirely, so it just stayed there, and worse, every time I would create a new account for myself on new hardware, I would always copy over my pre-existing ~/.login file, so the xbmc software rasterizer “bug” seemed to follow me around from machine to machine, EXCEPT of course when I would su to root, where the bad env variable setting would no longer apply.

In closing I’ll just say thank you to thokra for attempting to be of some assistance, and otherwise, my apologies to all for having needlessly killed so many electrons discussing what proved, in the end, to have been a simple case of pilot error.