Wine 1.1.23 Released With Various Fixes

[Thunderbird]

No it a test suite which is in the wine code. It is nothing spectacular (no fancy 3d demos) but it are tests which test the behavior of d3d9 functions e.g. the behavior of a certain shader and other tests. At some point in catalyst <= 9.3 such tests even caused system crashes (which means driver bugs as Wine itself can't crash the system as it is a normal user space app).

For any serious gaming you needed FBOs anyway for Halflife-2 in d3d9, Battlefield, WoW (except for opengl mode but that mode doesn't show the minimap on ati), ... Regarding popular games I meant popular games on Wine like WoW and others.

[dungeon]

FBOs have been around for years and they are critical for D3D9 gaming. (They are a core part of OpenGL 3.0 but they already existed for OpenGL 2.0) For all games released in the last 4-5 years you need to enable FBOs else various things won't get rendered or you can't get some 3d effects. Enabling this option improves user experience.

Oh my god, fbo IS good to have for DX9 gaming, but not critical! "Enabling this option improves user experience" and disables any non-nVidia user experience, because of driver which is not nVidia's. But why not just set up a quirks sheme for backbuffer on non-nVidia and non-DX9 in hardware capable cards, when drivers start to work just remove it from there. With current decision you can simply put on Wine's main page that "nothing but nVidia by default will work good with wine for sure in the next six (6) months at bare minimum, for later we will for sure continue ruining it again with vendor only part of OpenGL 3.2 implementation because it works the best in every cases, instead of generic, with 3.3 we... and so on...".

Further Wine is not pro-Nvidia. We use generic opengl extensions for all our functionality. In some cases vendor-specific extensions are used when opengl doesn't offer a functionality we need for d3d9/d3d10 or when a vendor extension offers an additional boost. (The only real case we have for this are the Nvidia shader extensions which we now use to offer shader model 2.0, they are more efficient than GLSL and allow things GLSL doesn't. OpenGL 3.2 is supposed to fix this missing functionality namely the ability to set a pixel shader independent of a vertex shader whereas right now GLSL ties them together which is very inefficient for hl2 and some other games).

But sorry, that IS very pro-nVidia driven, you'll wait some years when everyone maybe will have proper OpenGL 3.2 drivers to fix PS 2.0 support globally, while waiting we could use nV extensions on every cards, could we? Doh, we'll have to wait for "crappy" fglrx, s3 or DRI OpenGL 3.2 implementation, while waiting we could use nV extensions on every cards, could we? Why you not just choose GLSL and then wait for OpenGL 3.2? If you prefer 1% of some vendor goodness, instead of GLSL you are very pro-some_vendor, so when you choose explicitly something that is not a standard you are pro-some_vendor, when you call standard extensions as generic you are very likely pro-some_vendor, if something can work on every card in 99% cases, but instead you choose vendor only extensions which works only on one vendor cards, you are of course pro-some_vendor.

So please tell me again that Wine is not pro-nVidia, pro-Valve, pro-Blizz or pro-something_big_pop_one software, but first and mainly pro-nVidia.

[RealNC]

The conclusion I draw from all this is that NVidia simply cares about features and performance while AMD does not or lacks the knowledge for it.

[Thunderbird]

I repeat myself FBOs are needed for sm2.0 and higher. In short FBOs are needed for offscreen rendering which most d3d9 games use without an FBO games still want to use offscreen rendering and we then just render to the normal window which is evil, causes rendering issues and only offers 24-bit/32-bit in general and no floating point formats or others.

The opengl functionality which might get added in 3.2 will make our live easier and improve performance. Right now we work around the issue but it kills performance if the game switches shaders frequently like in half-life2. On Nvidia we can nicely work around it but not on ATI. On s3 the same extensions are offered but I haven't touched their hardware.

The only major issue around now is that there are buggy FBO implementations. Wine is the most complicated opengl program around.

[mirv]

I just want to point out that if I were writing drivers, I'd be more interested in writing them for native apps. I wouldn't be thinking that, for example, something written and coded for dx9 would be translated to run on opengl and the drivers should be written for that (this applies to all companies).
So before using wine as an excuse to whine about ati vs nvidia, it might be best for everybody to keep that in mind.

I'm going edit a bit more and say that nvidia had useable linux drivers out a while ago, and it's only natural that wine would therefore run better. This is an indication of wine dev experience with nvidia drivers, and can not in any way be used to magically show the current state of drivers from either company.

[Kano]

Usually the "native" apps then have to program around fglrx problems too. If they don't they could even crash the xserver - like vdrift when you end it. I would see wine as opportunity to reproduce outstanding bugs in order to fix em. When you can reproduce em then you can at least verify more easy if changes fixes em or not. nvidia just looked more carefull at outstanding rendering bugs than ati. The target should be always a flawless driver, which is of course not so easy to archive, but telling the ppl that rendering issues and video issues are not really the main target - as long as some workstation apps work which are usally not used by ppl who buy the gamer series cards - must be a joke. When you look at the sales numbers ati should notice gaming cards are the majory. Focussing on the minority with very few bugs is somehow extra stupid.

[Melcar]

Here we go again...

Anyway, the way I see it and have understood it up to now, is that fglrx targets workstations and the like, and the open drivers the home desktop user. ATI is starting to optimize fglrx toward the desktop environment, which is a big plus over the driver's intended purpose.

[dungeon]

The conclusion I draw from all this is that NVidia simply cares about features and performance while AMD does not or lacks the knowledge for it.

No nVidia push others to use their extensions and to think their way, not everytime invite some goodness, but always it's vendor way... So yes they just have that power in OpenGL area, but AMD also have knowledge in other area like http://www.pcper.com/article.php?aid=724. Guess how Wine will attempt to implement that "tesselation"...

The only major issue around now is that there are buggy FBO implementations. Wine is the most complicated opengl program around.

One more major issue is also that in 1.1.23 backbuffer is not working any more as expected (i tested this on DRI drivers), will that tend to be deprecated or maybe even removed?

I always suppose that silence meaning recognition, but it's OK - Wine developers often don't even have other cards then nVidia's, but always know when all other drivers are wrong.


-------++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++-------
No i don't want to whining or trolling here, but i hate any vendor only solution everywhere, even more when some developers rumor about how they actually support standardization in their software, but on the other hand everyone can see that source is full of quirks for nVidia, but others can just fix their drivers. That is it. Maybe Wine is just one game that needs to be fixed!

[Melcar]

The Way It's Meant To Be Played

[dungeon]

The Way It's Meant To Be Played

Yes that way, pushing and scrapping all around

But why Wine do the same is another question?