Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 5 of 5

Thread: Need help with rasterizer selection issue

Hybrid View

  1. #1
    Junior Member Newbie
    Join Date
    Oct 2012
    Posts
    3

    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:

    http://forum.xbmc.org/showthread.php?tid=133221

    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.

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    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?

  3. #3
    Junior Member Newbie
    Join Date
    Oct 2012
    Posts
    3
    Quote Originally Posted by thokra View Post
    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?
    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.)

    3) 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.

    4) 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.

  4. #4
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    [..]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.

  5. #5
    Junior Member Newbie
    Join Date
    Oct 2012
    Posts
    3
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •