Announcement

Collapse
No announcement yet.

Radeon RX 6800 "Sienna Cichlid" Firmware Added To Linux-Firmware.Git

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

  • Radeon RX 6800 "Sienna Cichlid" Firmware Added To Linux-Firmware.Git

    Phoronix: Radeon RX 6800 "Sienna Cichlid" Firmware Added To Linux-Firmware.Git

    The last piece of the puzzle to the open-source AMD Radeon RX 6800 / RX 6800 XT driver support is now upstream in its respective location...

    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
    Nice. Obviously would be perfect to do it day earlier. But this is still speedy.

    Comment


    • #3
      The firmware is already on its way as a stable update for Fedora 33.

      Comment


      • #4
        Note thought that ROCm pieces aren't open source yet. I guess ROCm 4.0 will suport it?

        Comment


        • #5
          As of

          Radeon RX 6800 Series Has Excellent ROCm-Based OpenCL Performance On Linux
          on 18 November 2020.

          With the strong OpenCL performance the Radeon RX 6800 in fact matched that of the RTX 3080 while the RX 6800 XT came out about 14% faster than the GeForce RTX 3080 overall
          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


          Wayland Network Transparency Patches Published
          on 9 February 2016
          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



          Waypipe Is Successfully Working For This Network-Transparent Wayland Apps/Games Proxy
          on 30 August 2019
          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




          There is an IDEA


          What about running Wayland/Waypipe on GPU and use PCIe 4.0 as a fast network for such configuration.


          What do you think about this idea?


          P.S. It seems that X server alternative is waypipe client, so there is opposite naming compared to X Window system, as I see.

          Comment


          • #6
            Originally posted by Peter Fodrek View Post
            What about running Wayland/Waypipe on GPU and use PCIe 4.0 as a fast network for such configuration.

            What do you think about this idea?

            P.S. It seems that X server alternative is waypipe client, so there is opposite naming compared to X Window system, as I see.
            Do you mean "run the entire Wayland stack on the GPU"? OpenCL is designed for parallel mathematical computations (fluid dynamic simulations, cloth simulation that kind of thing). It isn't very good at running traditional code (for example anything with if/else or variable length for loops are very inefficient).

            Most remote desktop systems just run the output of the video card through an H264 encoder these days. Bandwidth is less of an issue than it used to be.

            Comment


            • #7
              Originally posted by OneTimeShot View Post

              Do you mean "run the entire Wayland stack on the GPU"?
              Maybe or part of Wayland stack on GPU at least.



              Originally posted by OneTimeShot View Post
              OpenCL is designed for parallel mathematical computations (fluid dynamic simulations, cloth simulation that kind of thing). It isn't very good at running traditional code (for example anything with if/else or variable length for loops are very inefficient).
              Most remote desktop systems just run the output of the video card through an H264 encoder these days. Bandwidth is less of an issue than it used to be.
              Yes but

              An Early Port Of GCC To AMD's GCN Architecture
              on 22 September 2016
              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



              and

              Porting GCC to AMD GCN microarchitecture
              Honza Hubička SuSE ČR s.r.oPrague
              Joint work with Martin Jambor
              GNU Cauldron 2016

              Slide 4


              AMD Graphics Core Next
              New and clean instruction set used by AMD GPUs
              First specification released in 2011,
              Similar to traditional CPUs (unlike the predecessors)


              And I mention

              RDNA / RDNA2 is less similar to CPU then GCN
              CDNA is more similar to CPU then GCN

              So I it may be advantage-

              And If- then is slowed down on CPUs due to Spectre/Metldown and other Transient Execution Attacks




              and on GPU you are able to run both/all possible branches of code and use only valid branch result to speed up code on GPU

              Comment


              • #8
                Originally posted by Peter Fodrek View Post

                So I it may be advantage-

                And If- then is slowed down on CPUs due to Spectre/Metldown and other Transient Execution Attacks




                and on GPU you are able to run both/all possible branches of code and use only valid branch result to speed up code on GPU
                That's not the way it works. GPUs are good at running *the same code* in thousands of parallel compute units. Think of it as running the same program with hundreds of different inputs. If you have a loop that needs to run 80 times for just one of inputs, you'll be executing NOPs on all the other inputs because there's only one Program Counter shared between the cores.

                That's the main difference between CPU cores and GPU cores. Well that and GPU cores mostly do vector maths so you'll find some non-math things (especially anything to do with pointers to memory outside the local uniforms) are much faster on a CPU.

                Comment


                • #9
                  Originally posted by OneTimeShot View Post
                  That's not the way it works. GPUs are good at running *the same code* in thousands of parallel compute units. Think of it as running the same program with hundreds of different inputs. If you have a loop that needs to run 80 times for just one of inputs, you'll be executing NOPs on all the other inputs because there's only one Program Counter shared between the cores.

                  That's the main difference between CPU cores and GPU cores. Well that and GPU cores mostly do vector maths so you'll find some non-math things (especially anything to do with pointers to memory outside the local uniforms) are much faster on a CPU.
                  In fairness, CPU cores have the same problem once you start using SIMD instructions (SSE/AVX), and I don't think they have the same degree of automatic predication that GPU cores offer.

                  GPU SIMD units used to be a lot wider than CPU SIMDs but the gap is closing, with AVX512 in particular getting close to the 1024 or 2048 bit SIMD width you find on GPUs.

                  I do agree with your comment in the context of Peter Fodrek's post, however, since the GPU has to run each of the branches sequentially and so there is no effective speedup AFAIK.
                  Last edited by bridgman; 19 November 2020, 12:51 PM.
                  Test signature

                  Comment


                  • #10
                    This is great. This should be in Arch Linux shortly. Hopefully before my RX 6800 arrives

                    Comment

                    Working...
                    X