2009/5/5 Stefan Dösinger stefan@codeweavers.com:
- quirk only enables point sprites on the first texture unit. This keeps point sprites working in
- most games, but avoids the crash
...and on the other ones it will create hard to diagnose / explain bugs. Just disabling the extension if it's broken also avoids the crash, and will at least have predictable behaviour.
I also *still* think us working around AMD's bugs is the wrong approach. Of course it would also help if AMD took these kind of things seriously, or at least replied to my posts (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107).
On Wed, 6 May 2009, Henri Verbeet wrote: [...]
I also *still* think us working around AMD's bugs is the wrong approach. Of course it would also help if AMD took these kind of things seriously, or at least replied to my posts (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107).
Do we have a more formal way of reporting bugs to AMD/ATI? Something like a Bugzilla? Concerning this issue (the driver reporting a number of vec4s instead of the number of uniforms), do we have a way of checking independently of AMD? If so that would strengthen our bug report.
I have a feeling that Wine is the only 'application' that really tests the Unix OpenGL drivers, by virtue of being the only application to run the really complex vertex and pixel shaders that are found only in Windows games. Maybe I am wrong, but if I am right it means that the driver developpers would do well to take Wine seriously, and probably use it as a matter of course, if they want to produce quality code.
But hey, I got a quick answer to my bug report to the Intel developpers so it's not always bad. Unfortunately now I'm the one that's slow to answer as I have not had time to test their proposed fix. But I have not forgotten...
2009/5/6 Francois Gouget fgouget@free.fr:
On Wed, 6 May 2009, Henri Verbeet wrote: [...]
I also *still* think us working around AMD's bugs is the wrong approach. Of course it would also help if AMD took these kind of things seriously, or at least replied to my posts (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107).
Do we have a more formal way of reporting bugs to AMD/ATI? Something like a Bugzilla? Concerning this issue (the driver reporting a number of vec4s instead of the number of uniforms), do we have a way of checking independently of AMD? If so that would strengthen our bug report.
I think they're aware of that particular issue because Stefan talked privately to one of their developers, but unless things changed recently http://ati.cchtml.com/ is probably the closest to a bug tracker there is, and I'm not completely sure they read that regularly.
But hey, I got a quick answer to my bug report to the Intel developpers so it's not always bad. Unfortunately now I'm the one that's slow to answer as I have not had time to test their proposed fix. But I have not forgotten...
Mesa (that includes e.g. the intel and radeon drivers) is generally responsive to bug reports, as is NVIDIA. It's really just AMD and Apple that are problematic wrt. getting bugs fixed.
2009/5/6 Henri Verbeet hverbeet@gmail.com:
Mesa (that includes e.g. the intel and radeon drivers) is generally responsive to bug reports, as is NVIDIA. It's really just AMD and Apple that are problematic wrt. getting bugs fixed.
Just for the record, I'm not trying to just make AMD look bad here, I think it's great that they released the GPU documentation, and that they're paying people to work on the Mesa driver. Also, going by what I hear from other people, fglrx improved a lot in the more recent versions (certainly compared to the kind of support my Radeon 9800 Pro had...), so it's not all bad. They just *really* need to fix their developer relations stuff.
2009/5/6 Francois Gouget fgouget@free.fr:
I have a feeling that Wine is the only 'application' that really tests the Unix OpenGL drivers, by virtue of being the only application to run the really complex vertex and pixel shaders that are found only in Windows games. Maybe I am wrong, but if I am right it means that the driver developpers would do well to take Wine seriously, and probably use it as a matter of course, if they want to produce quality code.
I've been in contact with developers at Linux Game Publishing for a while (and am now in fact a Junior Developer for them :D), and from what I gather, regular OpenGL apps on Linux implement hacks to work around bugs/shortcomings in ATI/AMD drivers. Wine is a special case where it's been decided that hacks for specific drivers is a bad idea except in extreme cases, and that there should be generalised solutions for everything (which is, by the way, the whole point of OpenGL :) ).
As a result, the question of hacks in Wine comes up quite often (ATI/AMD card owners want their games to work!) and it's (almost?) always rejected. With any luck, we'll see some sensible, functional, open-source radeonhd drivers coming soonish, so the issue of hacks at the application level can be minimised.
On Wed, May 6, 2009 at 3:52 PM, Ben Klein shacklein@gmail.com wrote:
2009/5/6 Francois Gouget fgouget@free.fr:
I have a feeling that Wine is the only 'application' that really tests the Unix OpenGL drivers, by virtue of being the only application to run the really complex vertex and pixel shaders that are found only in Windows games. Maybe I am wrong, but if I am right it means that the driver developpers would do well to take Wine seriously, and probably use it as a matter of course, if they want to produce quality code.
I've been in contact with developers at Linux Game Publishing for a while (and am now in fact a Junior Developer for them :D), and from what I gather, regular OpenGL apps on Linux implement hacks to work around bugs/shortcomings in ATI/AMD drivers. Wine is a special case where it's been decided that hacks for specific drivers is a bad idea except in extreme cases, and that there should be generalised solutions for everything (which is, by the way, the whole point of OpenGL :) ).
As a result, the question of hacks in Wine comes up quite often (ATI/AMD card owners want their games to work!) and it's (almost?) always rejected. With any luck, we'll see some sensible, functional, open-source radeonhd drivers coming soonish, so the issue of hacks at the application level can be minimised.
Actually ATI/AMD is quite interested in Wine. I have been in contact with them for joining their developer program and helping them fix issues. I didn't have time to fill out all the info yet. I could get them look at it then.
Roderick
Am Mittwoch, 6. Mai 2009 16:33:01 schrieb Roderick Colenbrander:
Actually ATI/AMD is quite interested in Wine. I have been in contact with them for joining their developer program and helping them fix issues. I didn't have time to fill out all the info yet. I could get them look at it then.
Note that the issue here is not getting the bug fixed(it is fixed in the 9.4 driver, as you've verified with my test apps), but that on older radeons we'll be stuck with a broken driver until one of the 3 existing Mesa radeon drivers becomes useable(I think the radeon-rewrite branch is the target, not the radeonhd one).
Am Mittwoch, 6. Mai 2009 10:10:07 schrieb Henri Verbeet:
2009/5/5 Stefan Dösinger stefan@codeweavers.com:
- quirk only enables point sprites on the first texture unit. This
keeps point sprites working in + * most games, but avoids the crash
...and on the other ones it will create hard to diagnose / explain bugs. Just disabling the extension if it's broken also avoids the crash, and will at least have predictable behaviour.
Not in this case. As I explain in a comment in the test, there's no d3d cap flag for point sprites. So the games will just go ahead and try to do the same kind of rendering and just fail in the same or worse way.
The only advantage we get from disabling point sprites altogether is the WARN we get if the game tries to use them. I'll add a similar WARN to the point sprite function if the game uses them and this workaround is active.
I also *still* think us working around AMD's bugs is the wrong approach.
I agree in general, if this was just a rendering bug I'd put the workaround as a hack into CrossOver and be happy. However, we're trying to prevent a kernel panic here, and on the last two Wineconfs we agreed that we should try to prevent kernel panics while running our d3d tests, even if it is ugly(we have similar workarounds for old Mesa glDrawPixels / glReadPixels issues). If the tests crash the systems people will refuse to run them, making them useless.
Of course it would also help if AMD took these kind of things seriously, or at least replied to my posts (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107).
That specific issue is fixed in 9.4 I think. They confirmed the bug and replied here: http://ati.cchtml.com/show_bug.cgi?id=1462
(unfortunately no 9.4 for <= r500 cards, so we have to keep our workaround in directx.c)
2009/5/6 Stefan Dösinger stefan@codeweavers.com:
Am Mittwoch, 6. Mai 2009 10:10:07 schrieb Henri Verbeet:
...and on the other ones it will create hard to diagnose / explain bugs. Just disabling the extension if it's broken also avoids the crash, and will at least have predictable behaviour.
Not in this case. As I explain in a comment in the test, there's no d3d cap flag for point sprites. So the games will just go ahead and try to do the same kind of rendering and just fail in the same or worse way.
The only advantage we get from disabling point sprites altogether is the WARN we get if the game tries to use them. I'll add a similar WARN to the point sprite function if the game uses them and this workaround is active.
Well, the point is that if you disable the extension it will just not work at all, instead of "sometimes, depending on which texture unit the texture is mapped on".
Of course it would also help if AMD took these kind of things seriously, or at least replied to my posts (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107).
That specific issue is fixed in 9.4 I think. They confirmed the bug and replied here: http://ati.cchtml.com/show_bug.cgi?id=1462
Sure, I read that too, but it's not my point of course.
-
Ben Klein -
Francois Gouget -
Henri Verbeet -
Roderick Colenbrander -
Stefan Dösinger -
Stefan Dösinger