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.
Announcement
Collapse
No announcement yet.
Wine 1.1.23 Released With Various Fixes
Collapse
X
-
Originally posted by RealNC View PostBecause 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.Last edited by dungeon; 08 June 2009, 12:28 AM.
Comment
-
Originally posted by dungeon View PostAnd maybe not, their extensions are often bloated and hard to use.
And others provide nothing?
Standards never sucks, leave make up to your girl.
Comment
-
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).
Comment
-
Originally posted by RealNC View PostAt 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.
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.
Comment
-
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.
Comment
-
Originally posted by Henri View PostThe 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.
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...
Comment
Comment