Page 1 of 3 123 LastLast
Results 1 to 10 of 24

Thread: Don't Look For Open-Source AMD CrossFire Anytime Soon

  1. #1
    Join Date
    Jan 2007
    Posts
    14,309

    Default Don't Look For Open-Source AMD CrossFire Anytime Soon

    Phoronix: Don't Look For Open-Source AMD CrossFire Anytime Soon

    While the open-source AMD Linux driver continues gaining ground on Catalyst, one feature you will likely not see from the open-source Linux driver in the foreseeable future is support for AMD's CrossFire technology...

    http://www.phoronix.com/vr.php?view=MTYxNjM

  2. #2
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,517

    Default

    This sounds like a Mesa Intermediate Project, for those who are already familiar with Mesa enough and that want to explore its interactions with the kernel and Wayland. I'd be surprised if no freelancers tried to implement it, as it sounds like a relatively fun project. Possibly quite crowdfundable, too, as the gains, while slight, are visible to users, not only developers, so the interest in that should be quite bigger.

  3. #3
    Join Date
    Dec 2013
    Location
    Lyon, France
    Posts
    30

    Default

    Well, I could start to have a look at it, since I want to get involved with Mesa development, and I am looking for a GSOC organization, since XBMC won't be in the party this time.
    I am afraid this would require a large amount of work split between driver, windowing system, etc... not very suitable for a GSOC.
    But yes, this could be an interesting feature. Moreover, multi-vendor "Crossfire" or "SLI" or whatever would be a great plus for the tux OS. I can also imagine a "gpu fallback" instead of a software one, if one extension is implemented on a GPU and not an other. I am afraid memory structures may not be compatible, though.

  4. #4
    Join Date
    Jun 2010
    Posts
    227

    Default

    Any guesses on how long it will take before open source AMD drivers have full feature and performance pairity with the proprietary drivers? 10 years prehaps?

  5. #5
    Join Date
    Jul 2009
    Posts
    240

    Default

    so if you had a layer that would virtualise the GPUs you could even use an AMD and an nVidia card and on top intel integrated graphics :P
    sounds fancy!

  6. #6
    Join Date
    Jun 2009
    Posts
    1,086

    Default

    yeah basically the problem is to deal with vram uploads so it don't end slower than single GPUs and probably this layer must be closer to mesa than the drivers so is flexible enough to be gpu independant, especially to avoid shader specialization

  7. #7
    Join Date
    Oct 2013
    Posts
    224

    Default

    Quote Originally Posted by Prescience500 View Post
    Any guesses on how long it will take before open source AMD drivers have full feature and performance pairity with the proprietary drivers? 10 years prehaps?
    What difference will that make for you? It will not accelerate the development in any way. Just relax and enjoy what there is at the moment, which is better than there anything was.

  8. #8
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,517

    Default

    Quote Originally Posted by Prescience500 View Post
    Any guesses on how long it will take before open source AMD drivers have full feature and performance pairity with the proprietary drivers? 10 years prehaps?
    It depends on what you mean. In the strict sense, never (I highly doubt r600g will ever have XvBA support, for instance, because VDPAU is just better). Also, Catalyst has "AI" settings which are basically program-specific hacks, so those probably won't make it into FOSS drivers, either (that would just make the code too unclean and not really be worth it, especially for older games). It also depends on the hardware R700 hardware can only do OpenGL 3.3, so right now their support is almost in parity between r600g and Catalyst (only things like Crossfire don't work). But yea, in general FOSS drivers are competitive already (they have several advantages over Catalyst as it is).

  9. #9
    Join Date
    Dec 2012
    Posts
    501

    Default

    Quote Originally Posted by GreatEmerald View Post
    This sounds like a Mesa Intermediate Project, for those who are already familiar with Mesa enough and that want to explore its interactions with the kernel and Wayland. I'd be surprised if no freelancers tried to implement it, as it sounds like a relatively fun project. Possibly quite crowdfundable, too, as the gains, while slight, are visible to users, not only developers, so the interest in that should be quite bigger.
    I would also expect anyone that implemented it to not mandate GPU types. The ultimate crossfire would be one where workloads are load balanced across all available acceleration providers. I imagine doing that in real time - ie, checking the idle status of each part - would be too much of a slowdown. I'd imagine some kind of primitive benchmark or hardware performance database that Mesa could reference to gauge the relative strength of accelerators to know how to partition workloads.

    Yea, there are a lot of problems with a model like that (memory coherency, locality, synchronization overhead) but it sounds like a great PHD project.

  10. #10
    Join Date
    Dec 2012
    Posts
    97

    Default

    Quote Originally Posted by jakubo View Post
    so if you had a layer that would virtualise the GPUs you could even use an AMD and an nVidia card and on top intel integrated graphics :P
    sounds fancy!
    Usually, multiple GPU things like CrossFire are implemented using AFR (Alternate Frame Rendering), where each frame is alternated between GPUs. If you try and pair up a measly Intel integrated GPU with an extremely powerful AMD Radeon HD 6970, you'll end up with frametime issues, creating the "micro-stutter" effect, as every other frame would take longer to render due to the disparity between the GPUs. So while CrossFire across completely different GPUs sounds nice, it's much harder in practice and would most likely be worse than using a single GPU.

Posting Permissions

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