Announcement

Collapse
No announcement yet.

RadeonSI Gallium3D Gets UBO/TBO Support, OpenGL 3.3

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

  • #46
    Originally posted by mmstick View Post
    Simply installing LLVM 3.4 will not help with RadeonSI. Mesa needs to be compiled with LLVM 3.4 as a dependency.
    Yeah, that's what i meant since he was already compiling mesa from git. Install it and then recompile mesa.

    For 3.0 support, you'll need Mesa 10.0 with LLVM 3.4.

    For 3.1 support, you'll need at least x-server 1.13.

    I'm not sure about kernel support, but I'd recommend the newest you can there as well for the best DPM support.

    Comment


    • #47
      Originally posted by smitty3268 View Post
      Yeah, that's what i meant since he was already compiling mesa from git. Install it and then recompile mesa.

      For 3.0 support, you'll need Mesa 10.0 with LLVM 3.4.

      For 3.1 support, you'll need at least x-server 1.13.

      I'm not sure about kernel support, but I'd recommend the newest you can there as well for the best DPM support.
      Is there any sort of guide on how to compile mesa with the latest xserver/gallium/llvm3.4/dri for radeonsi?

      Comment


      • #48
        Originally posted by mmstick View Post
        Is there any sort of guide on how to compile mesa with the latest xserver/gallium/llvm3.4/dri for radeonsi?
        It depends on which distro you're running. I'm an Arch user, so it's actually pretty simple: I just use this repo for precompiled packages: http://pkgbuild.com/~lcarlier/mesa-git/

        Comment


        • #49
          Originally posted by dffx View Post
          It depends on which distro you're running. I'm an Arch user, so it's actually pretty simple: I just use this repo for precompiled packages: http://pkgbuild.com/~lcarlier/mesa-git/
          Looking for a normal non-distro-specific solution for Ubuntu. The usual way of using git to clone the latest repo along with the configure options to use. I don't know anything about what's specifically needed to compile the entire driver/xorg stack for radeonsi with llvm or what configure options are needed. I at least know llvm/clang is needed which can be installed as so:

          Code:
          git clone https://github.com/llvm-mirror/llvm
          git clone https://github.com/llvm-mirror/clang
          cd llvm; ./configure --enable-pic; make -j9; sudo checkinstall -y --pkgname=llvm-git --pkgversion=3.4; ../
          cd clang; make -j9; sudo checkinstall -y --pkgname=clang-git --pkgversion=3.4; ../

          Comment


          • #50
            Originally posted by mmstick View Post
            Looking for a normal non-distro-specific solution for Ubuntu. The usual way of using git to clone the latest repo along with the configure options to use. I don't know anything about what's specifically needed to compile the entire driver/xorg stack for radeonsi with llvm or what configure options are needed. I at least know llvm/clang is needed which can be installed as so:

            Code:
            git clone https://github.com/llvm-mirror/llvm
            git clone https://github.com/llvm-mirror/clang
            cd llvm; ./configure --enable-pic; make -j9; sudo checkinstall -y --pkgname=llvm-git --pkgversion=3.4; ../
            cd clang; make -j9; sudo checkinstall -y --pkgname=clang-git --pkgversion=3.4; ../
            The "normal non-distro-specific solution" is to clone the repo, configure, make and make install.

            Note that i approach this from Debian/Ubuntu point of view since its easier to build deb files and track them, especially if certain compile options are changed which result in added/removed files from the build (the removed files' old version will still be there if you just use make install and may create problems).

            But in case your repo has (and probably it has) a mesa installed from packages you have to make sure that the new libraries are loaded which can be tricky if there are 2 libraries in the library path (even if in different locations).
            You have 2 choices:
            -Install in a different prefix and convince ldconfig to always load the new libraries. Cleaner solution but i had some issues with old libs loaded.
            -Overwrite the old libraries and deal with the package updating issues - if a new update appears for a mesa component and its upgraded, your libs will be overwritten since the apt system has no idea about what you did there.
            Here you can do the following (i did it this way):
            Compile mesa and make it a deb package - this package will step on many other system packages toes so to speak since Debian/Ubntu hacked mesa into a truckload of separate packages. Solution:
            Find out what packages have conflicting files (trial and error, try to install the .deb file from terminal and watch the errors) and recreate the .deb, with the conflicting packages added to the "replaces" list until it will install. This will result in the built mesa's files added to a list in apt's records that state that the files in question belong to the newer package (mesa) and will not be bothered if the system's mesa library package is updated.

            As for building for radeonsi, you only have to specify the "--with-gallium-drivers=radeonsi" config option. Example below my build script for r600 (i suppose replacing r60 with radeonsi would work):

            Code:
            ./autogen.sh --sysconfdir=/etc --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu --enable-debug \
            CPPFLAGS="-m64" \
            CXXFLAGS="-m64" \
            --enable-64-bit --disable-32-bit \
            --enable-texture-float \
            --with-gallium-drivers=r600,swrast \
            --with-dri-drivers="" \
            --enable-vdpau \
            --enable-egl --enable-gles1 --enable-gles2 \
            --enable-glx-tls \
            --with-egl-platforms=x11,drm \
            --enable-gbm \
            --enable-gallium-egl \
            --enable-gallium-osmesa \
            --with-osmesa-bits=32 \
            --enable-gallium-llvm \
            --enable-r600-llvm-compiler \
            --enable-shared-glapi
            Note that i use 64 bit system and i have to build mesa separately for 64 and 32 bit (the latter for 3d apps, mostly games that are 32 bit like for example the games from STEAM).
            deb builder script:
            Code:
            fakeroot checkinstall --install=no --replaces libgles1-mesa:amd64,libgl1-mesa-dev,libglapi-mesa:amd64,libgles2-mesa:amd64,libgbm1:amd64,libegl1-mesa-dev,libgl1-mesa-dri:i386,libgl1-mesa-dri:amd64,libgl1-mesa-glx:amd64,libegl1-mesa:amd64,libgl1-mesa-swx11:amd64,libegl1-mesa-drivers:amd64,libosmesa6-dev:amd64,mesa-common-dev --pkgname=mesa --pkgversion=`cat VERSION` --pkgarch=amd64 --backup=no
            Really really good idea to save these in scripts.
            I also made a "master" script that pulls the latest gits, builds mesa, xf86-ati, glamor and creates+installs their .deb files in one shot.

            Comment


            • #51
              Originally posted by gradinaruvasile View Post
              The "normal non-distro-specific solution" is to clone the repo, configure, make and make install.

              Note that i approach this from Debian/Ubuntu point of view since its easier to build deb files and track them, especially if certain compile options are changed which result in added/removed files from the build (the removed files' old version will still be there if you just use make install and may create problems).

              But in case your repo has (and probably it has) a mesa installed from packages you have to make sure that the new libraries are loaded which can be tricky if there are 2 libraries in the library path (even if in different locations).
              You have 2 choices:
              -Install in a different prefix and convince ldconfig to always load the new libraries. Cleaner solution but i had some issues with old libs loaded.
              -Overwrite the old libraries and deal with the package updating issues - if a new update appears for a mesa component and its upgraded, your libs will be overwritten since the apt system has no idea about what you did there.
              Here you can do the following (i did it this way):
              Compile mesa and make it a deb package - this package will step on many other system packages toes so to speak since Debian/Ubntu hacked mesa into a truckload of separate packages. Solution:
              Find out what packages have conflicting files (trial and error, try to install the .deb file from terminal and watch the errors) and recreate the .deb, with the conflicting packages added to the "replaces" list until it will install. This will result in the built mesa's files added to a list in apt's records that state that the files in question belong to the newer package (mesa) and will not be bothered if the system's mesa library package is updated.

              As for building for radeonsi, you only have to specify the "--with-gallium-drivers=radeonsi" config option. Example below my build script for r600 (i suppose replacing r60 with radeonsi would work):

              Code:
              ./autogen.sh --sysconfdir=/etc --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu --enable-debug \
              CPPFLAGS="-m64" \
              CXXFLAGS="-m64" \
              --enable-64-bit --disable-32-bit \
              --enable-texture-float \
              --with-gallium-drivers=r600,swrast \
              --with-dri-drivers="" \
              --enable-vdpau \
              --enable-egl --enable-gles1 --enable-gles2 \
              --enable-glx-tls \
              --with-egl-platforms=x11,drm \
              --enable-gbm \
              --enable-gallium-egl \
              --enable-gallium-osmesa \
              --with-osmesa-bits=32 \
              --enable-gallium-llvm \
              --enable-r600-llvm-compiler \
              --enable-shared-glapi
              Note that i use 64 bit system and i have to build mesa separately for 64 and 32 bit (the latter for 3d apps, mostly games that are 32 bit like for example the games from STEAM).
              deb builder script:
              Code:
              fakeroot checkinstall --install=no --replaces libgles1-mesa:amd64,libgl1-mesa-dev,libglapi-mesa:amd64,libgles2-mesa:amd64,libgbm1:amd64,libegl1-mesa-dev,libgl1-mesa-dri:i386,libgl1-mesa-dri:amd64,libgl1-mesa-glx:amd64,libegl1-mesa:amd64,libgl1-mesa-swx11:amd64,libegl1-mesa-drivers:amd64,libosmesa6-dev:amd64,mesa-common-dev --pkgname=mesa --pkgversion=`cat VERSION` --pkgarch=amd64 --backup=no
              Really really good idea to save these in scripts.
              I also made a "master" script that pulls the latest gits, builds mesa, xf86-ati, glamor and creates+installs their .deb files in one shot.
              Why not share the scripts?

              Comment


              • #52
                Originally posted by mmstick View Post
                Looking for a normal non-distro-specific solution for Ubuntu. The usual way of using git to clone the latest repo along with the configure options to use. I don't know anything about what's specifically needed to compile the entire driver/xorg stack for radeonsi with llvm or what configure options are needed. I at least know llvm/clang is needed which can be installed as so:

                Code:
                git clone https://github.com/llvm-mirror/llvm
                git clone https://github.com/llvm-mirror/clang
                cd llvm; ./configure --enable-pic; make -j9; sudo checkinstall -y --pkgname=llvm-git --pkgversion=3.4; ../
                cd clang; make -j9; sudo checkinstall -y --pkgname=clang-git --pkgversion=3.4; ../
                Remember http://llvm.org/apt/ ? That has the latest llvm/clang as debs.

                As far as non-distro-specific stuff goes: I prefer to install to /opt/${PKGNAME}${PKGVERSION} (for example /opt/mesa10), then symlink into /usr if needed (when your software uses rpath) or else use LD_SO_PATH or /etc/ld.so.conf.d/mesa.conf

                Anyhow, you usually need the latest libdrm and llvm, then you'll need to build mesa, then glamor, then the ATI driver. But there may be a few other things in there as well...

                Comment


                • #53
                  Originally posted by Ibidem View Post
                  Remember http://llvm.org/apt/ ? That has the latest llvm/clang as debs.

                  As far as non-distro-specific stuff goes: I prefer to install to /opt/${PKGNAME}${PKGVERSION} (for example /opt/mesa10), then symlink into /usr if needed (when your software uses rpath) or else use LD_SO_PATH or /etc/ld.so.conf.d/mesa.conf

                  Anyhow, you usually need the latest libdrm and llvm, then you'll need to build mesa, then glamor, then the ATI driver. But there may be a few other things in there as well...
                  That's the problem: there is no real effort in properly documenting how to do this. Furthermore, there is the issue that you also have to compile 32-bit versions. Considering I have no idea how to go about this, I'm pretty much clueless.

                  Comment


                  • #54
                    Originally posted by Ibidem View Post
                    Remember http://llvm.org/apt/ ? That has the latest llvm/clang as debs.
                    That's the version I'm using too because (in my case) debian unstable has a 3.4 but that svn-version causes xorg to segfault during start-up.

                    Anyhow, you usually need the latest libdrm and llvm, then you'll need to build mesa, then glamor, then the ATI driver. But there may be a few other things in there as well...
                    When I tried to build that stack myself I stumbled across Running DRM/DRI/Mesa/DDX/Xorg from git on Debian Sid and it helped me a lot. Sure, that's ignoring the package system completely and there will be all sorts of problems, but it's the fastest way to test the new stuff.

                    Comment


                    • #55
                      Originally posted by mmstick View Post
                      That's the problem: there is no real effort in properly documenting how to do this. Furthermore, there is the issue that you also have to compile 32-bit versions. Considering I have no idea how to go about this, I'm pretty much clueless.
                      You need the 32 bit dev libraries. But as they are not multiarch on Debian (the amd64 and i386 both contain the include files which seem to be identical), i personally just installed the 64 bit ones then unpacked the i386 ones.

                      Originally posted by mmstick
                      Why not share the scripts?
                      They are kinda long. But if you brought it up like this...

                      I have a folder named compile in which i have cloned xf86-ati, glamor, mesa. I have a script in this top folder (called "deballmesa"):
                      Code:
                      #!/bin/bash
                      cd mesa
                      git pull
                      rm *.deb
                      ./mesadoalldeb
                      sudo dpkg -i *.deb
                      cd ../glamor
                      git pull
                      rm *.deb
                      ./glamordoalldeb
                      sudo dpkg -i *.deb
                      cd ../xf86-video-ati
                      git pull
                      rm *.deb
                      ./deballxf86
                      sudo dpkg -i *.deb
                      cd ..
                      rm mesadebs/*.deb
                      cp mesa/*.deb mesadebs/
                      cp glamor/*.deb mesadebs/
                      cp xf86-video-ati/*.deb mesadebs/
                      Each folder has their own sscripts that deal with building and creating debs.:
                      mesa:

                      has the local deb creator script, called :
                      mesadoalldeb
                      Code:
                      #!/bin/bash
                      make distclean ; ./configure64 && make -j 4 && ./debify64
                      make distclean ; ./configure32 && make -j 4 && ./debify32
                      -has configure64, configure32 for configuring the build for 64 and 32 bits

                      **Note the llvm related mess, its because i was only able to install side by side llvm-3.3 on 64 bit and 3.4 on i386 because of lack of (proper) multiarch support. They seem to work well nonetheless. I built both without llvm support and saw no discernable difference. BTW if you want Webgl on Firefox (or Seamonkey), disable llvm (launch Firefox with "R600_LLVM=0 firefox").

                      configure64:
                      Code:
                      #!/bin/bash
                      sudo rm /usr/bin/llvm-config
                      sudo ln -s /usr/bin/llvm-config-3.3 /usr/bin/llvm-config
                      ./autogen.sh --sysconfdir=/etc --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu --enable-debug \
                      CPPFLAGS="-m64" \
                      CXXFLAGS="-m64" \
                      --enable-64-bit --disable-32-bit \
                      --enable-texture-float \
                      --with-gallium-drivers=r600,swrast \
                      --with-dri-drivers="" \
                      --enable-vdpau \
                      --enable-egl --enable-gles1 --enable-gles2 \
                      --enable-glx-tls \
                      --with-egl-platforms=x11,drm \
                      --enable-gbm \
                      --enable-gallium-egl \
                      --enable-gallium-osmesa \
                      --with-osmesa-bits=32 \
                      --enable-gallium-llvm \
                      --enable-r600-llvm-compiler \
                      --enable-shared-glapi
                      configure32:
                      Code:
                      #!/bin/bash
                      sudo rm /usr/bin/llvm-config
                      sudo ln -s /usr/bin/llvm-config-3.4 /usr/bin/llvm-config
                      ./autogen.sh --sysconfdir=/etc --prefix=/usr --libdir=/usr/lib/i386-linux-gnu --enable-debug \
                      CPPFLAGS="-m32" \
                      CXXFLAGS="-m32" \
                      LDFLAGS="-L/usr/lib/i386-linux-gnu -L/usr/lib" \
                      --disable-64-bit --enable-32-bit \
                      --enable-texture-float \
                      --with-gallium-drivers=r600,swrast \
                      --with-dri-drivers="" \
                      --enable-vdpau \
                      --enable-egl --enable-gles1 --enable-gles2 \
                      --enable-glx-tls \
                      --with-egl-platforms=x11,drm \
                      --enable-gbm \
                      --enable-gallium-egl \
                      --enable-gallium-osmesa \
                      --with-osmesa-bits=32 \
                      --enable-gallium-llvm \
                      --enable-r600-llvm-compiler \
                      --enable-shared-glapi
                      also there are the deb creator scripts, debify64 and debify32:
                      debify64:
                      Code:
                      #!/bin/bash
                      fakeroot checkinstall --install=no --replaces libgles1-mesa:amd64,libgl1-mesa-dev,libglapi-mesa:amd64,libgles2-mesa:amd64,libgbm1:amd64,libegl1-mesa-dev,libgl1-mesa-dri:i386,libgl1-mesa-dri:amd64,libgl1-mesa-glx:amd64,libegl1-mesa:amd64,libgl1-mesa-swx11:amd64,libegl1-mesa-drivers:amd64,libosmesa6-dev:amd64,mesa-common-dev --pkgname=mesa --pkgversion=`cat VERSION` --pkgarch=amd64 --backup=no
                      debify32:
                      Code:
                      #!/bin/bash
                      fakeroot checkinstall --install=no --replaces libgles1-mesa:i386,libgl1-mesa-dev,libglapi-mesa:i386,libgles2-mesa:i386,libgbm1:i386,libegl1-mesa-dev,libgl1-mesa-dri:i386,libgl1-mesa-dri:i386,libgl1-mesa-glx:i386,libegl1-mesa:i386,libgl1-mesa-swx11:i386,libegl1-mesa-drivers:i386,libosmesa6-dev:i386,mesa-common-dev --pkgname=mesa32 --pkgversion=`cat VERSION` --pkgarch=i386 --backup=no --exclude=/etc/*,/usr/include/* --nodoc
                      -glamor has glamordoalldeb:

                      Code:
                      #!/bin/bash
                      make clean 
                      ./autogen.sh --prefix=/usr --enable-glx-tls --enable-xv
                      make -j 4
                      fakeroot checkinstall --install=no --pkgarch=amd64 --backup=no --pkgname=glamor --pkgversion=5.1-`git describe`
                      -xf86-video-ati has
                      deballxf86

                      Code:
                      #!/bin/bash
                      make clean 
                      ./autogen.sh --prefix=/usr
                      make -j 4
                      fakeroot checkinstall --install=no --pkgarch=amd64 --backup=no --pkgname=xf86-video-ati --pkgversion=7.2-git-`git describe` --replaces=xserver-xorg-video-radeon,xserver-xorg-video-ati

                      Comment


                      • #56
                        I use Debian testing 64 bit.

                        PS: What is with this 1 minute edit limit, its very annoying.

                        Comment


                        • #57
                          Originally posted by gradinaruvasile View Post
                          PS: What is with this 1 minute edit limit, its very annoying.
                          Michael just answered this in another thread -- it's a temporary thing while he finds a better solution for a recent wave of spam attacks. I guess it's less annoying that spam...

                          Comment


                          • #58
                            Originally posted by zanny View Post
                            I'm not faulting the code in the open, I'm faulting the effective inability for your average joe to really help implement the critical missing functionality of the SI hardware because the firmware blobs are obfuscated you can't know if you are actually utilzing the hardware properly. If they would release the microcode specs, the firmware, and any design documentation that explains exactly how to optimally use their pipeline, I (and other devs I imagine) might fathom spending a few hundred hours trying to make the mesa driver work with their new hardware.
                            Take a look at the programming guides, along with the generated assembly that the AMDAPP Kernel Analyzer generates... If you want to figure out how to properly optimize code for the SI cards, it's not at all hard to figure out the way that Catalyst handles things (if it's not already in the documentation).... The Kernel Analyzer (which I use for some CL driver work occasionally) gives you the full IL and/or assembly that is generated for Catalyst...

                            It's not that AMD needs to provide open firmware for the radeon cards... that's not slowing things down. The thing that's slowing things down is that efficient GPU driver programming is complex, and there's not that many people who have the skills/motivation to do it.

                            Comment

                            Working...
                            X