Originally posted by bridgman
View Post
Announcement
Collapse
No announcement yet.
AMD's Hawaii Open-Source Support Still Remains Broken
Collapse
X
-
-
Originally posted by Azpegath View PostYes, I did that. Just as I bought the 4850 when that was pretty new, to use it with the FOSS drivers. I did it to support AMD since they support what I believe in. But I realize that it won't work perfectly at first, or that I will have to wait a while for ot to work at all. But I'm willing to sacrifice that for the thought of supporting the only high performance gpu maker that makes FOSS drivers. Plus, the 7000-cards cost almost as much as the 2-series and I don't want to buy a new card in a yearTest signature
Comment
-
Originally posted by Azpegath View PostYes, I did that. Just as I bought the 4850 when that was pretty new, to use it with the FOSS drivers. I did it to support AMD since they support what I believe in. But I realize that it won't work perfectly at first, or that I will have to wait a while for ot to work at all. But I'm willing to sacrifice that for the thought of supporting the only high performance gpu maker that makes FOSS drivers. Plus, the 7000-cards cost almost as much as the 2-series and I don't want to buy a new card in a year
Comment
-
Note that hawaii works correctly with clover and with radeonfb (ie the tty are "accelerated" and Plymouth works) so it's possible to run Xorg without 3d acceleration (if you use Windows to play game) and doesn't need UVD for flash acceleration (I didn"t test if uvd works in tty though). Otoh I don't think people tend to couple hawaii cpu too slow to decode YouTube video.
The strange thing about hawaii is that it looks like it works under the hood as opencl works without specific workaround (like R600_DEBUG=nodma) and egl* apps sometimes display proper triangle/gears picture, it looks like it fails to present them. Unfortunalty I don't understand precisely how the different blocks work together so it is pure speculation and I can't really help except by testing.
Comment
-
Originally posted by vljn View PostNote that hawaii works correctly with clover and with radeonfb (ie the tty are "accelerated" and Plymouth works) so it's possible to run Xorg without 3d acceleration (if you use Windows to play game) and doesn't need UVD for flash acceleration (I didn"t test if uvd works in tty though). Otoh I don't think people tend to couple hawaii cpu too slow to decode YouTube video.
Originally posted by vljn View PostThe strange thing about hawaii is that it looks like it works under the hood as opencl works without specific workaround (like R600_DEBUG=nodma) and egl* apps sometimes display proper triangle/gears picture, it looks like it fails to present them. Unfortunalty I don't understand precisely how the different blocks work together so it is pure speculation and I can't really help except by testing.
Comment
-
Originally posted by bridgman View PostI don't agree, in a number of ways.
1. Being *told* that something is low priority by the business unit that funds a lot of the open source development (who, incidentally, don't sell any Hawaii-based parts) is one thing, and not caring *yourself* is a very different thing. You seem to be shooting the messenger here -- I realize it's a time-honoured tradition but that doesn't make it a Good Thing.
2. You seem to be assuming that fixing the problems would be easy, and concluding that since the problems are not fixed then nobody must have worked on it and "nobody cares". Try thinking instead that time *has* been spent on it (enough to bring it up to the same level as the other GCN parts based on experiences with previous generations) but for some reason it's *still* not working, then try working up a new set of conclusions from that.
Remember there seem to be at least two separate issues here -- the intermittent hangs which drove the initial decision to disable acceleration by default, and some more recent breakage in the code which Michel is working with a customer to fix.
ad 1) if the BU in question considers fixing a non-working product a non-priority, why not just pull the plug on it? the current driver hardly provides any value over the standard vesa driver, so it maybe actually less embarassing and more honest to say hawaii won't be supported due to lack of resources than keeping us in the dark for 9 months. what do you think?
ad 2) i was under the impression that you, the hardware guys, and the catalyst guys are in the same boat, so it would seem that you could reach out to these engineers to help debug the OSS driver?
Comment
-
Originally posted by phtpht View PostI don't want to criticize your effort, but this reply has set me wondering:
ad 1) if the BU in question considers fixing a non-working product a non-priority, why not just pull the plug on it? the current driver hardly provides any value over the standard vesa driver, so it maybe actually less embarassing and more honest to say hawaii won't be supported due to lack of resources than keeping us in the dark for 9 months. what do you think?
ad 2) i was under the impression that you, the hardware guys, and the catalyst guys are in the same boat, so it would seem that you could reach out to these engineers to help debug the OSS driver?
Comment
-
Originally posted by Azpegath View PostWhile I don't agree with statement number one, I do also wonder about number 2. How much are you guys (the two different teams) sharing knowledge and working together? Is it possible for the FOSS team to loan a Catalyst engineer for say a month, both to add (wo)manpower as well as knowledge about the implementation on the Catalyst driver? I know the driver architectures are very similar, but register handling and those low-level hardware parts must be the same, right? Or at least very similar..Test signature
Comment
-
OK, I *know* that wasn't 5 minutes...
Originally posted by phtpht View Post... 1) if the BU in question considers fixing a non-working product they don't sell but others do a non-priority, why not just pull the plug on it? the current driver hardly provides any value over the standard vesa driver, so it maybe actually less embarassing and more honest to say hawaii won't be supported due to lack of resources than keeping us in the dark for 9 months. what do you think?
I don't understand the premise of the question. We have multiple business units, some of whom fund open source driver development, plus core software development funding. The fact that one BU doesn't sell a product doesn't mean we have no resources to work on that product, just fewer resources. This is mostly a more-difficult-to-figure-out-than-usual technical problem.Test signature
Comment
-
Originally posted by bridgman View PostWe already have the teams working closely together, but the drivers are architecturally quite different (memory manager, command submission, fencing, use of DMA etc..). The static register settings are made identical before first support comes is released -- that's what "golden register" settings are for. Generally in a situation like this there is more than one active problem, which means that even correct fixes don't seem to fix it -- so so since Bonaire and Hawaii have a lot in common first priority is to deal with open issues on Bonaire which should reduce the problem space on Hawaii.
Comment
Comment