> 1. How much of the ATI trouble can be attributed to Wine, how much to > the > fglrx driver?- I read a lot of related discussion [1] but I'm not sure > what of that trouble is resolved already. Probably 50-50. There are a few classes of bugs that show up on one card vendor or the other: *) Different codepaths. WineD3D uses a lot of vendor-specific extensions for various features. If the implementation of a specific feature in one codepath is broken, you have a failure on HW X, but it is still a pure wine fault. E.g. for fixed function fragment processing we have a GL_ARB_texture_env_combine codepath(very old, pre-radeon 8500, pre-TNT2, other non-shader capable hardware), a GL_NV_register_combiners codepath(TNT2 to Geforce 2), a GL_NV_texture_shader+GL_NV_register_combiners codepath(geforce 3, 4), a GL_ATI_fragment_shader codepath(Radeon 8500-9200), and a GL_ARB_fragment_program codepath(Radeon 9500+, Intel GMA, Geforce 5+). It *) Dependence on hardware specifics that are not given by the spec. E.g. Nvidia hardware initializes shader output registers to 0.0. This is promised by GL_NV_vertex_program, but that extension only exists on nvidia hardware. We usually take care of initializing the registers or not using the values otherwise, but I recently found a bug concerning the specular color which I haven't fixed yet. *) Missing features. For some exotic D3D features we need some opengl extensions which are not supported everywhere(for example vertex blending). We tell the app about this, and it is supposed to cope with it, but not all apps do(those often break on intel cards on windows). By now we have shader emulation for almost all the legacy features that aren't available on all GL implementations, vertex blending is a notable exception. A WINEDEBUG=+warn could give hints here. *) Plain driver bugs > 2. Is there a chance *older* ATI cards (X800, X1950...) run better in > Wine > with the fglrx driver? I don't know. I have a radeon X1600 here, but I think most of the driver code is shared anyway. > 3. Is there a chance older ATI cards run better in Wine with the open > source "radeon" driver? (that for example does not seem to support GLSL > [2] for otherwise well-supported R300/R400-based cards) Doubtful, at the moment at least. The current mainstream Mesa/DRI infrastructure is not up to the task of supporting all the features games usually need(offscreen rendering, GLSL and vertex buffer mostly). Furthermore I came across many memory corruption bugs in Mesa. I have high hopes for the DRI2 and GEM stuff though, but unfortunately it isn't mainline yet as far as I can see. Henri worked a bit on the open source intel driver and Mesa software renderer, he can probably give you more information here. I am only using the R200 driver for my radeon 9000 mobility. Appart of pixel shader support and vertex blending all features that the windows driver has are available in wine, but it is pretty slow. I talked to Mattew Tippet(ATI driver developer) on the last XDC and I am in contact with him via Email. My sense is that ATI sees Wine as a big player in the Linux gaming segment and are working on making Windows apps run better. I saw that a few problematic bugs were fixed recently(for example linking two vertex shaders in a GLSL program), and I worked around a few others. So we see a steady improvement in ATI support, and it will continue to improve. It won't be blazing fast though, but a steady improvement. Your report sounds better than what I knew from the past already. That Supcom(a shader model 3.0 game I think) only shows static garbage is an improvement already, any game more modern than World of Warcraft usually crashed.
