Announcement

Collapse
No announcement yet.

RadeonSI Gallium3D Gets UBO/TBO Support, OpenGL 3.3

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

  • #21
    glsl mixture

    After todays update from git it says I have openGL 3.0 AND 3.1:

    glxinfo | grep Open
    ATTENTION: default value of option force_s3tc_enable overridden by environment.
    OpenGL vendor string: X.Org
    OpenGL renderer string: Gallium 0.4 on AMD TAHITI
    OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.0.0-devel
    OpenGL core profile shading language version string: 1.40
    OpenGL core profile context flags: (none)
    OpenGL core profile extensions:
    OpenGL version string: 3.0 Mesa 10.0.0-devel
    OpenGL shading language version string: 1.30
    OpenGL context flags: (none)
    OpenGL extensions:

    what could be causing this?

    Comment


    • #22
      Originally posted by tomtomme View Post
      After todays update from git it says I have openGL 3.0 AND 3.1:

      glxinfo | grep Open
      ATTENTION: default value of option force_s3tc_enable overridden by environment.
      OpenGL vendor string: X.Org
      OpenGL renderer string: Gallium 0.4 on AMD TAHITI
      OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.0.0-devel
      OpenGL core profile shading language version string: 1.40
      OpenGL core profile context flags: (none)
      OpenGL core profile extensions:
      OpenGL version string: 3.0 Mesa 10.0.0-devel
      OpenGL shading language version string: 1.30
      OpenGL context flags: (none)
      OpenGL extensions:

      what could be causing this?
      It's the core version. The 3.0 is the compatibility version. Basically, if you have a game (such as Natural Selection 2) that requires 3.1 compatibility version, then you won't be able to use it. I've heard it said that the compatibility version is the "true" OpenGL version, but I don't know that I put much credence in that.

      That said, my glxinfo doesn't give a core profile.

      Code:
      DRI_PRIME=1 glxinfo -t | grep OpenGL
      OpenGL vendor string: X.Org
      OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
      OpenGL version string: 3.0 Mesa 10.0.0-devel (git-86cdff5)
      OpenGL shading language version string: 1.30
      OpenGL context flags: (none)
      OpenGL extensions:
      Does anyone know why that is? My mesa-demos package is: mesa-demos 8.1.0-1

      Comment


      • #23
        Code:
        OpenGL vendor string: X.Org
        OpenGL renderer string: Gallium 0.4 on AMD TAHITI
        OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.0.0-devel (git-86cdff5)
        OpenGL core profile shading language version string: 1.40
        OpenGL core profile context flags: (none)
        OpenGL core profile extensions:
        OpenGL version string: 3.0 Mesa 10.0.0-devel (git-86cdff5)
        OpenGL shading language version string: 1.30
        OpenGL context flags: (none)
        OpenGL extensions:
        At least, kwin now works with 3.1 opengl.

        Comment


        • #24
          Originally posted by dffx View Post
          It's the core version. The 3.0 is the compatibility version. Basically, if you have a game (such as Natural Selection 2) that requires 3.1 compatibility version, then you won't be able to use it. I've heard it said that the compatibility version is the "true" OpenGL version, but I don't know that I put much credence in that.

          That said, my glxinfo doesn't give a core profile.

          Code:
          DRI_PRIME=1 glxinfo -t | grep OpenGL
          OpenGL vendor string: X.Org
          OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
          OpenGL version string: 3.0 Mesa 10.0.0-devel (git-86cdff5)
          OpenGL shading language version string: 1.30
          OpenGL context flags: (none)
          OpenGL extensions:
          Does anyone know why that is? My mesa-demos package is: mesa-demos 8.1.0-1
          My mesa-demos is 9.0.99
          In addition I have mesa-demo-x at verstion 8.1.0

          Comment


          • #25
            Originally posted by dffx View Post
            By your comment it seems you may not be familiar with the method in which the open source drivers are developed. While AMD does provide support for open source driver development (even employing a few developers) they are largely "on their own" and they are not backed up by the large volume of developers and engineers that otherwise work for AMD. I certainly don't profess to know what resources they AMD open source devs have at their disposal, but Xorg devs certainly only have a limited set of resources to work with. If you're going to fault AMD for anything, fault them for not operating like Intel does and don't push for fully open source driver development across the board, don't fault the limited (but steadily increasing) performance of the open source, community developed driver.
            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.

            Comment


            • #26
              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.
              I think you're reading much more into the microcode than is actually there. All the documentation describes behaviour of chip+microcode, and the binary driver programs to the same interface. Have you actually read the current documentation ?

              Comment


              • #27
                Originally posted by tomtomme View Post
                My mesa-demos is 9.0.99
                In addition I have mesa-demo-x at verstion 8.1.0
                Hmmm, wonder what your mesa-demos package is. As far as I can tell, 8.1.0 is the latest stable release: http://cgit.freedesktop.org/mesa/demos

                Which is likely what your mesa-demo-x package is.

                What distro?

                Comment


                • #28
                  Stupid 2-minute edit limit.

                  There seems to be ongoing confusion between firmware (executed on the CPU) and microcode (part of the GPU HW design). The Linux interface to load microcode images has "firmware" in the name which probably doesn't help.

                  A number of hardware blocks on the GPU are designed around microcode rather than pure random logic, even seemingly "dumb" blocks like the memory controller. We release those microcode images under a license which allows redistribution in Linux distros or devices and the driver loads them into the hardware -- the chip is pretty much "dead" until the microcode images are loaded because the microcode is effectively part of the hardware design.

                  Documentation is at : http://www.x.org/wiki/RadeonFeature/#index10h2 . Maybe start with "AMD Southern Islands / Sea Islands Acceleration".

                  Comment


                  • #29
                    Originally posted by bridgman View Post
                    Stupid 2-minute edit limit.
                    Uh? Didn't Michael remove it?
                    ## VGA ##
                    AMD: X1950XTX, HD3870, HD5870
                    Intel: GMA45, HD3000 (Core i5 2500K)

                    Comment


                    • #30
                      Originally posted by darkbasic View Post
                      Uh? Didn't Michael remove it?
                      Sort of -- IIRC there used to be a ~1 minute limit -- Michael bumped it to 30 minutes a year or so ago. Now it seems to be back to 2 minutes.

                      zanny:

                      - the "firmware" debates related to using AtomBIOS -- low level firmware shared by VBIOS and gfx drivers -- not the on-GPU microcode

                      - you might find starting with 5xx acceleration and moving forward works better than starting with SI/CI and moving backward, since each new programming guide assumes some familiarity with the previous generations rather than making each subsequent doc longer and harder to read

                      Comment

                      Working...
                      X