Fix catalyst brain damage to speed up Falcon BMS 2x

Stanislaw Halik sthalik at
Sat Feb 16 04:47:44 CST 2013

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

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 

Ben, Please help!

> 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 


Lack of GLSL disables HDR apparently.

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:


-------------- next part --------------
A non-text attachment was scrubbed...
Name: wine-bisect-falcon-bms.diff
Type: text/x-patch
Size: 2091 bytes
Desc: not available
URL: <>

More information about the wine-devel mailing list