Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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.

    Comment


    • #3
      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.

      Comment


      • #4
        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?

        Comment


        • #5
          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!

          Comment


          • #6
            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

            Comment


            • #7
              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.

              Comment


              • #8
                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).

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X