Gaming support with different hardware vendors (esp. ATI)

M.Kiesel · Post by **M.Kiesel** » Sun Dec 07, 2008 5:07 pm

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.emu ... ches/49869

[2]
http://www.x.org/wiki/RadeonFeature

[3]
http://wiki.winehq.org/FAQ#head-a96989f ... 7f6bcfd16f

M.Kiesel · Post by **M.Kiesel** » Sun Dec 07, 2008 8:03 pm

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 · Post by **vitamin** » Sun Dec 07, 2008 9:02 pm

M.Kiesel wrote:I recently got an ATI Radeon HD 3850 card

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

Stefan Dösinger · Post by **Stefan Dösinger** » Mon Dec 08, 2008 6:24 am

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.

Stefan Dösinger · Post by **Stefan Dösinger** » Mon Dec 08, 2008 6:25 am

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"

Those are harmless. I think fglrx violates the spec here because it isn't
supposed to write anything on successful compilation(Instead it tells me
verbally that the compile was successful). GL_ARB_draw_buffers is actually
supported, but the driver nevertheless complains. I never saw any negative
effect, and the extension indeed works.

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?

No patches to test unfortunately. Unless you want to dig into the code and
start debugging the driver's behavior etc there is nothing you can do
unfortunately

DaVince · Post by **DaVince** » Tue Dec 09, 2008 4:25 am

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.

M.Kiesel · Post by **M.Kiesel** » Wed Dec 10, 2008 12:55 pm

On Mon, 8 Dec 2008, Stefan Dösinger wrote:

Can I help in some way?

...

No patches to test unfortunately. Unless you want to dig into the code and
start debugging the driver's behavior etc there is nothing you can do
unfortunately

I uploaded the PoP vertex shader programs as generated by Wine 1.1.10 and
a screenshot showing the problems to [1]. Perhaps this helps a bit.
Unfortunately I can't really make sense of GLSL (yet

.

Regards

[1]
http://bugs.winehq.org/show_bug.cgi?id=7411#c10