http://bugs.winehq.org/show_bug.cgi?id=21515
ppanon@shaw.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ppanon@shaw.ca
--- Comment #3 from ppanon@shaw.ca 2010-01-30 03:19:43 --- I'm also running a similar environment: recent git open source ATI/radeon driver with HD3850 recent git mesa (7.8 alpha) Currently they're both from the Ubuntu Xorg-edgers PPA (2010/01/27 snapshot for ATI, 2010/01/28 for mesa).
I'm getting similar behaviour where VENDOR_WINE is being selected based on the GL_VENDOR of "Advanced Micro Devices, Inc." I haven't been able to get as far as cruiseoveride because the apps I'm trying are failing completely with the VENDOR_WINE default.
That said, I think what's happening for cruiseoveride is that Mesa 7.7+ has beta support for OpenGL 2.0 APIs with ATI R600 and above. http://wiki.x.org/wiki/RadeonFeature
So what's probably happening is that Wine code assumes that VENDOR_MESA has a lower level of OpenGL support, whereas it probably uses more recent APIs when the VENDOR_ATI is detected, expecting GL2+ from the proprietary fglrx driver. So by hardcoding to VENDOR_ATI, wine is using more advanced APIs that better support translation of the graphics calls from the application.
It looks like I wouldn't be able to use cruiseoveride's VENDOR_ATI hack though because the HD3850 isn't in Wine's list of ATI devices (which jumps from HD3200 to HD4350). From lspci -v
01:00.0 VGA compatible controller: ATI Technologies Inc RV670PRO [Radeon HD 3850] Subsystem: ATI Technologies Inc Device 2542 Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at fe9e0000 (64-bit, non-prefetchable) [size=64K] I/O ports at c000 [size=256] Expansion ROM at fe9c0000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: radeon Kernel modules: radeon
cruiseoveride's VENDOR_ATI hack has issues however, because it may result in Wine attempting to use GL APIs that are supported by the fglrx driver, but not in the Mesa 7.7+ R600(+) driver support. Seeing as how GL 2.0, and eventually GL3.0+ support is planned through Mesa/Gallium3D, what probably needs to be done is to rewrite the Mesa-based GL translation paths to also select based on the OpenGL level supported.