Does WINE work well with radeon drivers for D3D games?

[Extreme Coder]

Hi,
I have an ATI X1650 Pro.
I read that the OSS radeon driver supports 3D acceleration on it, so I think I could give it a try if it supports WINE any better than fglrx.

So my question is, how well would WINE work with radeon driver in D3D games? (The ones that keep crashing or not running with FGLRX even with a good rating in AppDB)

Also, does radeonhd support 3D acceleration? And how similar is it to radeon?

Sigh.. I should've gotten me a nVidia for the time being.. The time I spent trying to make Wine/Cedega work with games that supposedly work with WINE was far too long, and it makes me want to format my Linux partition

Thanks!

[bridgman]

I think the issue is that a lot of the games need full OpenGL 2.0 or 2.1 to support DX9 and AFAIK none of the open source drivers are doing a good job of that yet.

The radeonhd driver has supported 3d for a couple of months, and as of the last week or so is now supporting 2d and 3d acceleration simultaneously (before that you had to disable 2d acceleration when you ran with 3d acceleration). The accel code in the two drivers is now pretty similar.

[Extreme Coder]

I think the issue is that a lot of the games need full OpenGL 2.0 or 2.1 to support DX9 and AFAIK none of the open source drivers are doing a good job of that yet.

The radeonhd driver has supported 3d for a couple of months, and as of the last week or so is now supporting 2d and 3d acceleration simultaneously (before that you had to disable 2d acceleration when you ran with 3d acceleration). The accel code in the two drivers is now pretty similar.

I see.. but wouldn't that mean that those with Intel cards can't use Wine?

Also, is the whole wine-fglrx thing caused from wine or from fglrx?

[Kano]

Well wine works fine with fglrx 8-5 and with nvidia drivers

[bridgman]

I see.. but wouldn't that mean that those with Intel cards can't use Wine?

I don't remember seeing many posts about running Wine on Intel graphics - good *or* bad. My *guess* would be that Wine on Intel open source drivers would be a bit better than on our open source drivers, if only because the driver support has been available for longer, but I don't really know for sure.

My understanding is that the Intel open source drivers are around GL 1.5 while the ATI open source drivers are "1.3 with nearly all of the 1.4 features". Not sure exactly how that maps into which apps run well on Wine.

[Extreme Coder]

I don't remember seeing many posts about running Wine on Intel graphics - good *or* bad. My *guess* would be that Wine on Intel open source drivers would be a bit better than on our open source drivers, if only because the driver support has been available for longer, but I don't really know for sure.

My understanding is that the Intel open source drivers are around GL 1.5 while the ATI open source drivers are "1.3 with nearly all of the 1.4 features". Not sure exactly how that maps into which apps run well on Wine.

So the wine issue is not from a problem of fglrx's new 3D stack?

[bridgman]

We're trying to find out -- specifically to find a better way for "Wine problems" to get translated into "OpenGL problems" to make it easier for the core OpenGL team to work on them. I suspect that some of the problems will be fglrx-related in that they are caused by changes in the OpenGL functionality, and others will turn out to be wine-related in the sense that they are caused by assumptions made by the wine devs about how our driver stack behaves which are not related to the OpenGL API.

[fermulator]

Any progress on this front Bridgman?

Curious to know when the "needed OGL extensions" required by many games run in WINE would be available in the open source Radeon driver?

[bridgman]

In theory the higher GL levels will come "for free" once a Gallium3D driver is available. It obviously won't be that easy but it does mean that OGL 2.x support is mostly likely to come after Gallium3D has replaced the current hardware driver layer in Mesa for ATI/AMD parts.

Gallium3D in turn relies on DRI2 and GEM/TTM support, and it's GEM/TTM where most of the "development pressure" is being felt today (since having a solid GEM/TTM implementation is also a pre-requisite for enabling Kernel ModeSetting (KMS) by default.

Getting GEM/TTM into the upstream kernel is really what will gate most of the other bits. Once it is accepted into the kernel that means the upper level drivers (the X driver and Mesa) can rely on having kernel video memory management, which in turn allows developers to focus their efforts on getting DRI2-based drivers (including Gallium3D) ready for shipped in distros.

Fedora is already shipping most of these bits, but that requires it to run ahead of the upstream kernel in a number of areas.

[curaga]

Any news on how Intel works now that it supports GL 2.1?