Wine 1.1.23 Released With Various Fixes

[RealNC]

Because it's easier to use NVidia's extensions maybe. They "just work". NVidia was always providing support for fast gaming. If the standard sucks, NVidia steps in. That's not a bad thing. It shows they want their cards to be fast. And they are. NVidia is not the industry leader in high performance graphics for no reason.

[dungeon]

Because it's easier to use NVidia's extensions maybe.

And maybe not, their extensions are often bloated and hard to use.

They "just work".

Marketing... When they not, there is multisampling quirk ready to help in nVine pleasure.

NVidia was always providing support for fast gaming.

And others provide nothing?

If the standard sucks, NVidia steps in.

Standards never sucks, leave make up to your girl.

That's not a bad thing.

Who said that it is?

It shows they want their cards to be fast.

We all want our cards to be fast as Tesla's lightning.

And they are.

As Tesla's lightning?

NVidia is not the industry leader in high performance graphics for no reason.

Agree, there are many reasons. Half of them are naturally at 50%.

[Melcar]

Well, Medieval 2 and Rome no longer install and Furmark runs at half speed now. I guess it's either back to 1.1.22 or start hacking. Thankfully Fallout remains playable .

[RealNC]

And maybe not, their extensions are often bloated and hard to use.

At least they provide extensions. As Thunderbird said, Wine on ATI is slow and buggy. "Bloated and hard to use". Yeah. Right.

And others provide nothing?

Nothing that works at least.

Standards never sucks, leave make up to your girl.

I think you're obsessed with something. Someone who knows a lot about 3D and Wine just told you why NVidia is best for it, but still you won't admit that ATI just isn't up to par here. I already discussed this too long with you. There's no point trying to talk sense into fanbois.

[Thunderbird]

Next to the FBO change there were lots of other changes in 1.1.23 and those seem to have caused some small regressions. This causes that moving to backbuffer still doesn't allow you to run some games.

Further as I said we are only using nvidia shader extensions (and that code was written in the last couple of weeks), we always have fallbacks. For >=SM3.0 we are just using glsl. Further even if we were using NV extensions nothing forbids lets say ATI to also add those (as I mentioned S3 offers the same extensions).

[mirv]

At least they provide extensions. As Thunderbird said, Wine on ATI is slow and buggy. "Bloated and hard to use". Yeah. Right.


Nothing that works at least.


I think you're obsessed with something. Someone who knows a lot about 3D and Wine just told you why NVidia is best for it, but still you won't admit that ATI just isn't up to par here. I already discussed this too long with you. There's no point trying to talk sense into fanbois.

You're trying to manipulate words here. Several points: ATI have always provided their own extensions as well. I think it was VBOs that ATI pushed ahead - nvidia preferred something else (VARs).
ATI not up to par? Wine could be changed to take advantage of ATI cards, then you could say nvidia wasn't up to par. Again, it's about developer experience and being able to work around things - this applies to ati, nvidia, and I'm guessing intel as well. I've written my own apps that work great on an ATI card, but horribly slow on nvidia - and this applies to both windows and linux (never tried on a mac, but wanted to). Oh look, nvidia drivers must be crap. No - I just have more experience with ATI.
I'm going to call you an nvidia fanboy, as it certainly seems that way. Nothing wrong with that - but do please add some substance to what you say.

[Kano]

I don't get you. When you know ATI so well then optimize wine for it yourself instead complaining...

[mirv]

I don't get you. When you know ATI so well then optimize wine for it yourself instead complaining...

Sorry, I forgot, this is the internet. Some degree of sense and reason doesn't belong.

[Henri]

The relevant Wine bug report is http://bugs.winehq.org/show_bug.cgi?id=18794. This is a fglrx bug, plain and simple. The backtrace looks like a simple NULL-pointer dereference, which shouldn't be particularly hard to fix.

I already notified an fglrx developer about this. I will also file a proper bugreport with testcase on http://ati.cchtml.com/, probably later today. (And in case any ATI/AMD people read this, you guys *really* need to fix that. Having only an unofficial bugzilla that someone might read or not isn't the way to handle developer relations.)

On the subject of AMD running the Wine test suite or not, that's their choice to make of course. However, I think it's important to note that many of the tests in there were added as a result of fixing actual bugs in real applications. Failures in those tests usually translate into real bugs in real applications.

It's certainly true that at least some time ago most Wine (D3D) developers and users had nvidia cards. I think it's not hard to see why, given fglrx's quality in the past. More recently, as fglrx's quality has been improving, that's been changing. (And fwiw, Thunderbird actually has an AMD card.) That's an advantage for nvidia of course, but not due to malicious intend on our side. It's simply a result of ATI's historic policy of spending effort on fglrx proportional to Linux market share. That too was their choice to make. Either way, the current situation is that while fglrx is certainly improving, it isn't quite there yet in terms of support for features like FBOs and GLSL. Neither is Mesa/DRI, but things are improving there as well.

@dungeon: I think I asked you to do a regression test. Perhaps I'm mistaking you for someone else though.

[makomk]

The relevant Wine bug report is http://bugs.winehq.org/show_bug.cgi?id=18794. This is a fglrx bug, plain and simple. The backtrace looks like a simple NULL-pointer dereference, which shouldn't be particularly hard to fix.

Perhaps, but it looks like Wine's doing something a bit iffy. It appears to be attaching textures to FBOs with formats the specification explicitly forbids, apparently in the process of blindly trying all possible texture formats to see which can be attached. Something that fglrx should handle without crashing, certainly, but not exactly a normal or sane thing to do.

Also, if this was an NVidia driver bug, I really doubt Wine would do a release in the current state. They've broken all D3D apps under fglrx, since this test is done during D3D initialization. However, since fglrx is a second-class citizen in the Wine world...