M.Kiesel
2008-Dec-07 22:07 UTC
[Wine] Gaming support with different hardware vendors (esp. ATI)
Hi all! I recently got an ATI Radeon HD 3850 card and now noticed that with the fglrx driver many games that look well in AppDB do not run properly on this hardware (Supreme Commander ingame: flickering static garbage, Prince of Persia SoT has several issues that completely garble ingame graphics). Older games (not using shaders among other things) seem to run fine - need to do more testing though. My guess is that AppDB is more or less nVidia-only. However, since I'm not impressed by nv politics (lacking OSS support; also they recently dropped support for my old card in their closed driver), getting a new nv card is no option. My questions: 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. 2. Is there a chance *older* ATI cards (X800, X1950...) run better in Wine with the fglrx driver? 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) I started a FAQ entry for this [3]. Any pointers with further information (bug entries...) for that FAQ are much appreciated. Last questions: How can I help? Should I add bugzilla entries for the games not working (probably this isn't much help)? Who to contact? Regards [1] http://article.gmane.org/gmane.comp.emulators.wine.patches/49869 [2] http://www.x.org/wiki/RadeonFeature [3] http://wiki.winehq.org/FAQ#head-a96989ff3303c1f6c35a1f85e0680b7f6bcfd16f
Stefan Dösinger
2008-Dec-07 22:59 UTC
[Wine] Gaming support with different hardware vendors (esp. ATI)
> 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.
M.Kiesel
2008-Dec-08 01:03 UTC
[Wine] Gaming support with different hardware vendors (esp. ATI)
On Sun, 7 Dec 2008, Stefan D?singer wrote:>> 1. How much of the ATI trouble can be attributed to Wine, how much to >> the fglrx driver? ... > Probably 50-50.... Thanks for the detailed information! Will try to summarize that for the FAQ. ATI trying to fix fglrx for Wine sounds very good. Concerning the bugs I observed (with Radeon HD 3850 and fglrx 8.11): 1. Prince of Persia SoT run with WINEDEBUG=+warn and minimum graphics settings gives [---] fixme:d3d9:Direct3DShaderValidatorCreate9 stub fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #31: "Fragment shader was successfully compiled to run on hardware.\nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supporte" fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #29: "Fragment shader(s) linked, vertex shader(s) linked. \nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supported " [---] . The graphics error is difficult to describe; many misplaced offscreen vertices is the best description I can come up with (can take screenshots/video though if it helps). In the meantime I also found http://bugs.winehq.org/show_bug.cgi?id=7411 which looks like pretty much the same issue (see comment #8). 2. Supreme Commander supports shader model 2.0. Don't know if it uses 3.0 features if present. Everything's fine until ingame; then, the engine seems to switch between the loading screen and a black screen. Same fixme messages as in PoP. Can I help in some way? Trying patches, running other tests or games (e.g., Bioshock as a shader 3.0 game)? Is there some git branch worth trying out? Regards
vitamin
2008-Dec-08 02:02 UTC
[Wine] Re: Gaming support with different hardware vendors (esp. ATI)
M.Kiesel wrote:> I recently got an ATI Radeon HD 3850 cardYour biggest mistake you did for your Linux. Ask ATI (now AMD) to write better drivers (not just for Linux but all platforms, their windows and mac drivers as bad).
DaVince
2008-Dec-09 09:25 UTC
[Wine] Re: Gaming support with different hardware vendors (esp. ATI)
> I'm not > impressed by nv politics (lacking OSS support; also they recently dropped > support for my old card in their closed driver), getting a new nv card is > no option.Funny, because ATI did the same thing for my card recently. The big difference is that nVidia actually quickly releases Linux drivers that work.