AMD Catalyst 11.2 Linux Driver Released

[indus]

Sorry about using the word sh*t.Cant find edit button for posts.

[Night Nord]

At the end of the day, wine is a single application being used as a windows emulator. The most important thing to look at are native applications - which use OpenGL.

Well, maybe, in some bright far future, all major game titles (and games are one of the most important reasons why you may need discrete GPU. OpenCL and others are far not so popular) will be also released on Linux platform, just like they are released on Mac OS X now. Maybe this will be some near future, maybe more distant one, but anyway, we can't count on this for now. So, bugs-in-wine on fglrx are major reason, why gamers still buy NVidia, thought modern ATI's beating them in performance/price ratio by far. And looking for culprit - wine developers, fglrx developers, aliens, Microsoft or whatever - this is just useless here. flgrx developers may just pay a little more attention for wine bugs, as they could more easily detect the real problem - in driver or in wine. At least, that will be, imo, more useful then vsync or flash acceleration. I'm happy with OSS drivers for video and flash, so I need fglrx only for games and, mostly, for wine games. But that's my IMO, of course.

[PsynoKhi0]

Well, maybe, in some bright far future, all major game titles (and games are one of the most important reasons why you may need discrete GPU. OpenCL and others are far not so popular) will be also released on Linux platform, just like they are released on Mac OS X now. Maybe this will be some near future, maybe more distant one, but anyway, we can't count on this for now. So, bugs-in-wine on fglrx are major reason, why gamers still buy NVidia, thought modern ATI's beating them in performance/price ratio by far. And looking for culprit - wine developers, fglrx developers, aliens, Microsoft or whatever - this is just useless here. flgrx developers may just pay a little more attention for wine bugs, as they could more easily detect the real problem - in driver or in wine. At least, that will be, imo, more useful then vsync or flash acceleration. I'm happy with OSS drivers for video and flash, so I need fglrx only for games and, mostly, for wine games. But that's my IMO, of course.

I for one can't stand that kind of "the WINE devs program for nvidia, just buy a geforce" status quo, for a number of reasons.
Especially when it comes to an OS that has historically very much been about users being proactive and scratching their own itch.

So here's a suggestion: does anyone here have a Radeon HD lying around collecting dust? I do, and I think I might just donate it to WINE devs.

[monraaf]

I for one can't stand that kind of "the WINE devs program for nvidia, just buy a geforce" status quo, for a number of reasons.

So here's a suggestion: does anyone here have a Radeon HD lying around collecting dust? I do, and I think I might just donate it to WINE devs.

There's no need for that. Henri Verbeet, the main wined3d coder, already has Radeon HD hardware, in fact he even contributes to the open source r600g driver. In any case you are barking up the wrong tree, the problem is not wine, the problem is fglrx. Every time I encountered a bug with wine+fglrx, it always turned out to be that the bug was in fglrx not in wine. Just look at the bug report linked to a few posts ago as another example...

We* have fixed the issue, the fix will be included in future release.

*where we stands for ATI/AMD

...so again the bug was in fglrx. A better suggestion would be to point the AMD blob devs to the open source piglit test suite, and tell them to fix their god damned driver and do some fscking regression testing. Last time I ran piglit on fglrx some months ago the results were disappointing, to make an understatement.

[mirv]

There's no need for that. Henri Verbeet, the main wined3d coder, already has Radeon HD hardware, in fact he even contributes to the open source r600g driver. In any case you are barking up the wrong tree, the problem is not wine, the problem is fglrx. Every time I encountered a bug with wine+fglrx, it always turned out to be that the bug was in fglrx not in wine. Just look at the bug report linked to a few posts ago as another example...



...so again the bug was in fglrx. A better suggestion would be to point the AMD blob devs to the open source piglit test suite, and tell them to fix their god damned driver and do some fscking regression testing. Last time I ran piglit on fglrx some months ago the results were disappointing, to make an understatement.

What you linked to I thought was more due to a wine bug actually. The AMD guys can make a workaround, but if something's not in spec, how do you blame AMD for that?

[monraaf]

It clearly says that they fixed the bug, they didn't say they made a workaround. Perhaps you're referring to the comment about wine supposedly generating illegal shaders.

Why would they want to make workarounds for wine bugs? That doesn't sound like AMD at all. As Henry Verbeet said if they find the bug is in wine they should report it to the wine bugzilla or to him, so the bug can be fixed in wine. If they don't do so and fix the bug in fglrx, I assume the bug is in fglrx, not in wine.

[mirv]

Well, I'd assume that AMD are working on improving out of spec handling - running to spec is one thing, but they need to handle out of spec too (if nothing else to prevent things from crashing).

[PsynoKhi0]

What you linked to I thought was more due to a wine bug actually. The AMD guys can make a workaround, but if something's not in spec, how do you blame AMD for that?

My thought exactly.
"We've fixed this issue" doesn't necessarily imply a bug being squashed, making the code align itself with WINE's idiosyncrasies also "resolves this issue".

Specs and standards are supposed to level the playing field. One of the many requirements for users to be able to grab a piece of hardware without having to sell one of their kidneys in the long run. Any "our stuff works specifically with hardware from this vendor, others will have to play catch-up" is not something anyone should look forward.

[monraaf]

The burden of proof is on AMD and its defenders. It's a little easy to say "Well the bug really is in wine, but we worked around wine's idiosyncrasies in our driver" and then hide behind closed source code and not disclose exactly what wine's 'idiosyncrasy' supposedly is at fault.

I challenge anyone accusing wine of having an 'out of spec' nvidia bias to not only accuse (which is easy), but also to disclose the specifics where wine supposedly is at fault. I don't think you can, but if you can I'm pretty sure if you file a bug report it will be fixed in wine.

[mirv]

It was mentioned in the link what was the issue. In this particular case, it was GLSL shaders not being properly formed, according to spec.
If you'd like however, and this isn't for wine but from my own programming, I have seen shaders missing things specifying the precision of floats in the fragment shader. This is required by spec - shaders on fglrx wouldn't work without it. Problem is, not much old code had it, and previous specs didn't require it - so if it still worked, why look for a problem?
This is why it's important to have at least 2 implementations of any spec - to check and make sure everything's programmed as it "should" be. No blame, no accusations, merely continued software development.
People are quick to always point the finger at AMD, and while their drivers have problems just like any (and every) other driver out there, it doesn't mean other software is perfect.