Announcement

Collapse
No announcement yet.

DRI without aiglx

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DRI without aiglx

    it auto-loads swrast_dri.so instead of mach64_dri.so

    I would like to ask some questions about X.Org and DRI and Mesa amd hope maybe someone knows:

    1. is it possible to build X.Org directly with DRI, without Mesa ?
    2. where is the most complete documentation of all the X.Org extensions ? and all the XCB extensions ? how do I know which ones I should compile and which not, the X.Org manuals weren't very helpful in that regard

    3. where are the most complete instructions of building a Modular X.Org 1.5.0, I have made some progress but am having some problems, specifically aiglx loads swrast_dri.so even if mach64_dri.so is present

    4. why does AIGLX load even if DRI is working ? and how to prevent it ? because --disable-aiglx has no effect, and that module still gets compiled and loaded

    previously I wasn't able to start X at all, but that appears to have been either due to following incorrect build instructions or due to the driver for my hardware (mach64) being too new (building the latest .tar.bz2 source and overwriting with make install allowed to start the server)

    and before that I had some other errors such as "shmget: function not implemented" which apparently disappeared after compiling System V IPC support into the kernel

    and then there was another error in the mach64 driver which says "linear aperture not available" which was also fixed by using the non-git version of the driver (latest bz2 release)

    there were additional errors: such as:
    cannot open virtual console 7 (permission denied)
    undefined symbol xf86getpcivideoinfo
    xf860OpenConsole: Cannot open/dev/tty0 (Permission denied)
    some agp error, which was fixed by setting a higher agp aperture size in the BIOS
    and another error from MACH64 which was fixed by enabling VM86 in the kernel

    what an eventful week, wouldn't you agree ? and it's not over yet!

    specs of the target and build system:
    P3 Katmai 500/100 384MB
    Ati Rage Pro Turbo AGP 2X 8MB

    I am currently trying to figure out what I can from:



    mesa3d.org

    but I have yet to know exactly what I need to do or how, every guide suggest different ./configure options for different packages and uses different installation methods

    the good news is that MACH64 driver itself does not have any (EE) during it's loading, so currently I am trying to build xorg-server-1.5.0.tar.bz2 with ./configure --enable-dri --enable-dri2 but apparently that does not go so well, because I found on the forum someone suggests that to disable aiglx need DRI2

    I would appreciate some pointers in the right directions.

    I have tried to use DirectFB and XDirectFB as a preferred method of hardware acceleration, and that mission was only partially successful, DirectFB did build, but the patch of XDirectFB for xorg did not work at all.

    for your consideration, I am currently open for any suggestions anyone may have for the best hardware acceleration performance achieveable on Linux, if there is something other than the two above mentioned methods you think I should know about and try to use instead, I would like to know about it.
    Last edited by monohouse; 18 September 2008, 06:24 AM.

  • #2
    no mesa = no dri with X.org . mesa contains opensource 3d drivers for various cards (including ati).

    you need :
    - kernel drm modules for your card (in case of ati : drm.ko , radeon.ko )
    - X (duh ;-) )
    - mesa with ati dri module (they come with standard mesa install)
    - xf86-video-ati driver.

    why does AIGLX load even if DRI is working ?
    try this :

    xorg.conf :
    Code:
    Section "ServerFlags"
           Option "AIGLX" "false"
    EndSection

    Comment


    • #3
      that had no effect

      (II) MACH64(0): Direct rendering enabled
      (==) RandR enabled
      (EE) AIGLX error: dlopen of /opt/gfx-test/lib/dri/swrast_dri.so failed (/opt/gfx-test/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
      (EE) GLX: could not load software renderer
      (II) GLX: no usable GL providers found for screen 0
      $ xvinfo
      Xlib: extension "Generic Event Extension" missing on display ":0.0".
      $ glxinfo
      name of display: :0.0
      Xlib: extension "GLX" missing on display ":0.0".
      Xlib: extension "GLX" missing on display ":0.0".
      Xlib: extension "GLX" missing on display ":0.0".
      Error: couldn't find RGB GLX visual
      $ glxgears
      Xlib: extension "GLX" missing on display ":0.0".
      Error: couldn't get an RGB, Double-buffered visual
      btw the X.Org server 1.5.0 was configured with
      ./autogen.sh --prefix=/opt/gfx-test --enable-builtin-fonts --disable-xprint --disable-aiglx --disable-screensaver --enable-dri --with-mesa-source=/home/manoa/Mesa-7.2-rc1 --disable-ipv6
      $ls /opt/gfx-test/lib/dri
      mach64_dri.so
      i am now trying to rebuild it a little differently:
      ./autogen.sh --prefix=/opt/gfx-test --enable-builtin-fonts --disable-xprint --disable-aiglx --disable-screensaver --enable-dri --disable-ipv6
      without specifying the Mesa directory, while doing that I noticed that:
      checking for DBUS... no
      checking for HAL... no
      checking whether to build Xorg DDX... yes
      checking whether to build Xgl DDX... no
      checking whether to build Xegl DDX... no
      checking whether to build Xglx DDX... no
      I wonder if that has any relevance, gonna try to build with
      ./autogen.sh --prefix=/opt/gfx-test --enable-builtin-fonts --disable-xprint --disable-aiglx --disable-screensaver --enable-dri --disable-ipv6 --enable-xvfb --enable-xnest --enable-xfree86-utils --enable-xorg --enable-config-dbus --enable-config-hal --disable-xsdl --with-driver=dri --disable-glx-tls --with-xcb --enable-xcb
      instead
      Last edited by monohouse; 18 September 2008, 07:34 AM.

      Comment


      • #4
        That looks familiar from when I built a git xorg when I had a r500.

        To get h/w direct rendering I had to

        export LIBGL_DRIVERS_PATH=/path/to/your/Xorg-git/modular/lib/dri

        before startx - I guess you already have the other paths set like

        export LD_LIBRARY_PATH=/path/to/your/Xorg-git/modular/lib
        export PATH=/path/to/your/Xorg-git/modular/bin:$PATH

        When building/updating you need to make sure these are set to your modular tree.

        export PKG_CONFIG_PATH=/path/to/your/Xorg-git/modular/lib/pkgconfig
        export ACLOCAL="aclocal -I /path/to/your/Xorg-git/modular/share/aclocal"

        It was a while ago I did this and I arranged things so mesa and dri went into the modular tree, so it may be different for you.

        Comment


        • #5
          DAMN !, still it had no effect, same errors

          here is my ld.so.conf:
          /opt/gfx-test/lib
          /opt/gfx-test/lib/xorg/modules
          /opt/gfx-test/lib/xorg/modules/drivers
          /intel/cc/10.1.018/lib
          /usr/lib/libfakeroot
          /opt/qt/lib
          /opt/kde/lib
          /usr/local/lib
          this is the script I executed before loading X.Org
          export ACLOCAL="aclocal -I /opt/gfx-test/share/aclocal"
          export PKG_CONFIG_PATH=/opt/gfx-test/lib/pkgconfig
          export CFLAGS=
          export LIBGL_DRIVERS_PATH=/opt/gfx-test/lib/dri
          Last edited by monohouse; 18 September 2008, 07:48 AM.

          Comment


          • #6
            Originally posted by monohouse View Post
            DAMN !, still it had no effect, same errors
            Hmm maybe you shouldn't disable aiglx int the xserver.

            I had loads of hassle building xorg git and in between my first and second attempts things changed so that now you need mesa installed before building rather than just telling xserver where it is.

            LIBGL_DEBUG=verbose glxinfo

            can be useful in seeing what paths are being used.

            Comment


            • #7
              but that doesn't make mutch sense, because after I compiled and copied all the data from mesa/mesa in GIT, I then downloaded the new Mesa-7.2 and copied it into the same place, it should have overwritten all the data of the old Mesa, which was compiled with the wrong options

              damn I might have to do it all over again....but what happens if in the future I change the video card ? how will I be able to tell it to use the new driver, or what if I whant to check if I have some problem and it is in the driver and temporarily switch to swrast for a while, I can't believe that there is no way to switch the opengl driver

              Comment


              • #8
                im gonna try to build stable, I have leeched alote of things from http://xorg.freedesktop.org/releases/individual/
                including 1.5.3 server and a few other things, and I am using for the most part this guide: http://xorg.freedesktop.org/wiki/Development/git
                but I can't find libdrm in there, I can only find the git versions from where it says in the guide, but not the stable, is three any other manual for building xorg ?

                I whant to build stable version because I have had some trouble with git version before, for example the mach64 driver didn't work and a few other things went wrong, I want to be able to build a stable version first.

                these are the only manuals I know about




                and these are the only places to get the packages I know about




                I hope that is right

                btw this is the new script I use before running X.Org:

                Code:
                insmod drm.ko
                insmod mach64.ko
                export LD_LIBRARY_PATH=/opt/gfx-test/lib
                export LIBGL_DRIVERS_PATH=/opt/gfx-test/lib/dri
                export LIBGL_DEBUG=verbose
                export PATH=/opt/gfx-test/bin:$PATH
                startx -- /opt/gfx-test/bin/Xorg -verbose
                I hope that is also right, and btw, I have been thinking alot about XCB, and haven't got a decision, as far as I get it, it is supposed to make X faster or smaller or both, I managed to enable it, it required building additional packages, I am not sure if that actually means anything, does XCB actually increase performance for non-XCB programs (Xlib/XCB) ? is it worth enabling just for that purpose alone ? because it seems to me like a waste, but I am not sure.
                Last edited by monohouse; 09 November 2008, 11:38 PM.

                Comment


                • #9


                  Good luck!

                  Comment

                  Working...
                  X