Announcement

Collapse
No announcement yet.

FGLRX Pixel Buffer support

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

  • FGLRX Pixel Buffer support

    Bridgman,

    There are currently two bugs (1058, 1303) opened on the unofficial bug tracker at http://ati.cchtml.com dealing with the lack of the WGL_ARB_pbuffer extension in the current FGLRX driver. I was just hoping that you or someone in your driver development team could comment on when we can expect this much needed feature to be implemented.

    Thank you.

  • #2
    I take it I'm the only person that cares about pbuffer support in the FGLRX driver. Since AMD has known about this bug for almost a year, and there has been no response here, I can only assume that AMD doesn't care to support this feature. An oddity about this situation is that AMD has docs and sample code on their website that use this extension, although it seems to be written for old hardware: http://developer.amd.com/gpu/radeon/...s/default.aspx

    Anyone from AMD want to respond?

    Comment


    • #3
      OK, these are DX games making Windows GL calls over WINE. Not sure, but I'm guessing that WINE is mapping them into pbuffers calls and AFAIK what we support is PBOs, at least that's my recollection from earlier discussions.

      The original complaint was "PBOs don't work" which AFAIK turned out to actually be "PBOs work but they are not reported as being available", which was fixed months ago AFAIK.
      Last edited by bridgman; 02-05-2009, 03:11 PM.

      Comment


      • #4
        Yes, the WGL extensions are for Windows, but they are needed for some applications run under Wine. A very similar extension, GLX_SGIX_pbuffer, is already supported by FGLRX, perhaps this can be mapped to WGL_ARB_pbuffer somehow. However, since FGLRX shares a common code base with the Windows driver, I see little reason why this can't be ported directly over to Linux.

        On a side note, the Nvidia binary blob has provided the WGL_ARB_pbuffer for a 'long time'.

        Thanks for your reply.

        Comment


        • #5
          Originally posted by bridgman View Post
          OK, these are DX games making Windows GL calls over WINE.
          Actually, this issue surfaces in WoW when running the opengl client, not the direct3d client under Wine. Wine's opengl stack is considered complete, it basically just transfers calls 1:1 to the driver. This problem does not show itself when running the direct3d client because Wine translates the calls to opengl, but they don't use the WGL_ARB_pbuffer extension.

          Comment


          • #6
            Originally posted by bridgman View Post
            The original complaint was "PBOs don't work" which AFAIK turned out to actually be "PBOs work but they are not reported as being available", which was fixed months ago AFAIK.
            I am currently using the 9.1 release, but AFAIK, the WGL_ARB_pbuffer extension has been unsupported on all versions of FGLRX based on the new code base (I have an m76, so I have no idea if it was supported on the old code base).

            This has been a problem on all versions of Wine that I have tested, including the latest 1.1.14.

            Comment


            • #7
              Everything I read indicates that pbuffers have been pretty much replaced by FBOs over the last few years. I haven't looked at the two in detail but at first glance it seems that using FBOs in WINE would be the way to go.

              Comment


              • #8
                ATI seems to have removed quite some stuff from OpenGL recently. Counter-Strike (uses an OpenGL 3D engine created in 1999) runs slower at times with my Dual Core 3.33GHz + 4870 and any recent Catalyst (7.11 and up; the problem started with my older X1950) than it did years ago with a small Celeron and a Radeon 9800...

                Comment


                • #9
                  It might not be removal as much as retuning of the performance optimizations. You generally make important things fast at the expense of making unimportant things slow, so it's possible that functions used by more recent apps have been given priority over functions used by older apps.

                  Still, I wouldn't expect a 4870 to be slower than a 9800 on any 3D app with the possible exception of glxgears. Interesting...

                  Comment


                  • #10
                    Originally posted by bridgman View Post
                    Still, I wouldn't expect a 4870 to be slower than a 9800 on any 3D app with the possible exception of glxgears. Interesting...
                    There was one instance in Counter-Strike were the problem is severe: The "headshot2k" map. The 4870 would slow down to crawl at 20FPS while the old X1950 with Catalyst <=7.11 would render happily at 200+FPS. I actually reported that bug as soon as I updated to 7.12 (and then reverted back to 7.11 because of it) but of course there was no reply and it got never fixed

                    Edit:
                    And it wasn't an issue that only showed on my PC. CS forums were full of it and the only solution was not using anything newer than 7.11. At some point, CS servers started removing that map. We never knew what happened. We simply had to accept it. Then the NVidia fanboy horde of course went on the "see, we told you so about ATI" trip
                    Last edited by RealNC; 02-05-2009, 04:57 PM.

                    Comment


                    • #11
                      Originally posted by bridgman View Post
                      Everything I read indicates that pbuffers have been pretty much replaced by FBOs over the last few years. I haven't looked at the two in detail but at first glance it seems that using FBOs in WINE would be the way to go.
                      This is not a Wine issue, it is a driver issue. FGLRX does not support opengl extensions in use by popular programs that otherwise work perfectly under Wine.

                      Ideally, Blizzard would update their opengl code to utilize FBOs instead of pbuffers. Unfortunately, their opengl code works just fine on the two platforms it was designed for, OSX and Windows, so they have little incentive to make this change just to support Linux.

                      Again, with FGLRX having a common code base with the Windows driver, what is holding the devs back from implementing this in Linux?

                      Thank you.
                      Last edited by sandain; 02-05-2009, 05:38 PM.

                      Comment


                      • #12
                        Let's be clear here - we're saying that fglrx may not support a WGL-specific opengl extension in use by popular WINDOWS programs, correct ?

                        Are you sure that NVidia implements the WGL extension in the Linux driver, or is it more likely that WINE successfully translates the call to an appropriate GLX extension but doesn't handle that properly on ATI cards ? I'm not necessarily disagreeing with you, just asking.
                        Last edited by bridgman; 02-05-2009, 05:43 PM.

                        Comment


                        • #13
                          To clarify, FGLRX does not support a WGL-specific extension used in a Windows program. This means WoW run under Wine does not properly render using AMD hardware.

                          The Nvidia binary blob does not support this WGL-specific extension in Linux. However, Wine still properly renders WoW on Nvidia hardware.

                          Edit: Nvidia drivers do not export WGL-specific extensions, Wine handles this.
                          Last edited by sandain; 02-05-2009, 09:34 PM.

                          Comment


                          • #14
                            Originally posted by bridgman View Post
                            Are you sure that NVidia implements the WGL extension in the Linux driver, or is it more likely that WINE successfully translates the call to an appropriate GLX extension but doesn't handle that properly on ATI cards ? I'm not necessarily disagreeing with you, just asking.
                            To clarify, AFAIK, Wine's OpenGL implementation does no translation, it is just a wrapper that passes calls 1:1 to the driver.

                            Comment


                            • #15
                              Actually that's wrong. It looks like NVidia does not implement the extension either. WINE maps the WGL call onto a different, experimental extension called GLX_SGIX_pbuffer (proposed in 1997 but never accepted) and that's what seems to be implemented in the NVidia driver. I suspect we also implemented it in our old OpenGL code (which would have been active back in 1997) but did not implement it in the new code base.

                              http://bugs.winehq.org/show_bug.cgi?id=11826

                              It sounds like the Wine devs also feel this should be mapped onto FBOs and would if they had time.
                              Last edited by bridgman; 02-05-2009, 05:55 PM.

                              Comment

                              Working...
                              X