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; 05 February 2009, 04:11 PM.
      Test signature

      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.
              Test signature

              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...
                  Test signature

                  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; 05 February 2009, 05:57 PM.

                    Comment

                    Working...
                    X