Page 4 of 4 FirstFirst ... 234
Results 31 to 40 of 40

Thread: AMD's Hawaii Open-Source Support Still Remains Broken

  1. #31
    Join Date
    Nov 2010
    Location
    Stockholm, Sweden
    Posts
    396

    Default

    Quote Originally Posted by bridgman View Post
    Do you envision people buying Hawaii cards to use them with the open source drivers ?
    Yes, 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

  2. #32
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote Originally Posted by Azpegath View Post
    Yes, 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
    OK, noted and understood. Thanks for responding.

  3. #33
    Join Date
    May 2014
    Posts
    2

    Default

    Quote Originally Posted by Azpegath View Post
    Yes, 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
    I too follow this use-case. I buy a new top-end card every 2-3 years ($400-750 range) and like to have basic support available in a Linux desktop as I regularly dual-boot, only using Windows for gaming. A stable linux desktop environment on a top-end AMD card with FOSS drivers is definitely preferred.

  4. #34
    Join Date
    Mar 2011
    Posts
    27

    Default

    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.

  5. #35
    Join Date
    Dec 2007
    Posts
    2,329

    Default

    Quote Originally Posted by vljn View Post
    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.
    ttys are not accelerated with kms, they are always software rendered.

    Quote Originally Posted by vljn View Post
    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.
    Right. Hawaii is effectively a bigger bonaire. They both have the same 3D programming interface. It probably comes down to some 3D register or registers that need to be programmed slightly differently for hawaii, but so far we haven't been able to track it down.

  6. #36
    Join Date
    Jun 2009
    Posts
    58

    Default

    Quote Originally Posted by bridgman View Post
    I 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.
    I 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?

  7. #37
    Join Date
    Nov 2010
    Location
    Stockholm, Sweden
    Posts
    396

    Default

    Quote Originally Posted by phtpht View Post
    I 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?
    While 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..

  8. #38
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote Originally Posted by Azpegath View Post
    While 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..
    We 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.

  9. #39
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    OK, I *know* that wasn't 5 minutes...

    Quote 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?
    Added underlined text to your question above.

    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.

  10. #40
    Join Date
    Nov 2010
    Location
    Stockholm, Sweden
    Posts
    396

    Default

    Quote Originally Posted by bridgman View Post
    We 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.
    Ok, thanks. I just saw that I'd accidentally written "I know the driver architectures are very similar" even though I of course meant the opposite. You've stated several times before that the architecture is very different, so I wanted to assure you that I already knew that. Talk about misfire

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •