Page 1 of 4 123 ... LastLast
Results 1 to 10 of 32

Thread: FGLRX Pixel Buffer support

  1. #1
    Join Date
    Oct 2007
    Posts
    91

    Default 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. #2
    Join Date
    Oct 2007
    Posts
    91

    Default

    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?

  3. #3
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,282

    Default

    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 at 03:11 PM.

  4. #4
    Join Date
    Oct 2007
    Posts
    91

    Default

    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.

  5. #5
    Join Date
    Oct 2007
    Posts
    91

    Default

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

  6. #6
    Join Date
    Oct 2007
    Posts
    91

    Default

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

  7. #7
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,282

    Default

    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.

  8. #8
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,762

    Default

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

  9. #9
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,282

    Default

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

  10. #10
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,762

    Default

    Quote 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 at 04:57 PM.

Posting Permissions

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