Re: Gaming support with different hardware vendors (esp. ATI)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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.




[Index of Archives]     [Gimp for Windows]     [Red Hat]     [Samba]     [Yosemite Camping]     [Graphics Cards]     [Wine Home]

  Powered by Linux