Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 58

Thread: RadeonSI Gallium3D Gets UBO/TBO Support, OpenGL 3.3

  1. #21
    Join Date
    Mar 2012
    Posts
    325

    Default 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?

  2. #22
    Join Date
    Aug 2012
    Posts
    111

    Default

    Quote 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

  3. #23
    Join Date
    Nov 2013
    Posts
    5

    Default

    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.

  4. #24
    Join Date
    Mar 2012
    Posts
    325

    Default

    Quote 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

  5. #25
    Join Date
    Dec 2012
    Posts
    551

    Default

    Quote 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.

  6. #26
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote 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 ?

  7. #27
    Join Date
    Aug 2012
    Posts
    111

    Default

    Quote 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?

  8. #28
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    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".

  9. #29
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    970

    Default

    Quote Originally Posted by bridgman View Post
    Stupid 2-minute edit limit.
    Uh? Didn't Michael remove it?

  10. #30
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote 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

Posting Permissions

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