Resubmitting. Spam filter ate my message. Really sorry if you receive this twice!
On 2013-02-16 09:04, Stefan Dösinger wrote:
What you really want to do is figure out why GL_ARB_map_buffer_range is slow on fglrx, and make sure that the problem is really fglrx specific. I fixed a number of dynamic buffer performance problems in the past months, but there are still problems if we're falling back to draw_strided_slow for some reason, like fixed function material tracking.
Thanks for reviewing this.
Going to ask Ben Supnik from Laminar Research (X-Plane developer) and BCC him, since he has apparently run into the same issue. There's much info of fglrx woes (not really Linux specific, either) on http://developer.x-plane.com/
He said publicly to be in contact with AMD themselves, and been friendly to OSS by releasing an X-Plane Linux version, as well as overall cool fellow.
Ben, Please help!
http://developer.x-plane.com/2012/02/three-nasty-bugs/
Overall "site:developer.x-plane.com radeon" is nice documentation for fglrx brokenness.
Other than being wrong conceptually, you're disabling dynamic buffers the wrong way: The "proper" way would be to add a quirk to the quirk_table in directx.c that removes ARB_map_buffer_range from the list of supported extensions if the driver vendor is AMD.
Like this? Patch attached.
I've run into hard GPU hangs with fglrx 13.2, no VT switch either. This helps:
[Software\Wine\Direct3D] "DirectDrawRenderer"="gdi" "Multisampling"="disabled" "OffscreenRenderingMode"="fbo" "UseGLSL"="enabled"
Lack of GLSL disables HDR apparently. But enabling it changes FPS from 70 to 90.
Without GDI, there's some nasty display corruption on FBOs.
Also Catalyst likes to hang display when switching from 3D to 2D and VT switch helps.
But with all this busywork, performance is near-native. Catalyst at least supports indirect addressing (whatever that means) and doesn't choke on > 128 temps... FYI Mesa bug submitted:
https://bugs.freedesktop.org/show_bug.cgi?id=55420
-sh