Announcement

Collapse
No announcement yet.

AMD Lands Displayable DCC Support For Raven APUs In Mesa 19.1's RadeonSI

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

  • AMD Lands Displayable DCC Support For Raven APUs In Mesa 19.1's RadeonSI

    Phoronix: AMD Lands Displayable DCC Support For Raven APUs In Mesa 19.1's RadeonSI

    Marek Olšák of AMD has merged his latest performance-enhancing feature into RadeonSI Gallium3D: the enabling of displayable DCC on Raven Ridge / Raven 2 APUs...

    http://www.phoronix.com/scan.php?pag...isplayable-DCC

  • #2
    I think there's a bug in amdgpu because when I update to kernel 5.0.6 I got stuck on "fb: switching to amdgpudrmfb from VESA VGA" at boot, so I stayed on 4.18

    Comment


    • #3
      4.19 is the last kernel I am able to boot because of some drm issue, this is incredible anoying...

      Comment


      • #4
        bridgman marek what hardware/software combination AMD uses to test raven on linux? All these months and people still facing instability issues, if we know that using kernel X, on OEM Y board Z, with AMDGPU A, you are guaranteed that it will work

        Comment


        • #5
          Originally posted by andrei_me View Post
          bridgman marek what hardware/software combination AMD uses to test raven on linux? All these months and people still facing instability issues, if we know that using kernel X, on OEM Y board Z, with AMDGPU A, you are guaranteed that it will work
          On the graphics side, we use a few commercial boards, but mostly AMD engineering boards and OEM platforms where Linux support was requested. This biggest issues generally come down to UEFI and ACPI. Most OEMs only validate windows and windows doesn't enable a bunch of features that Linux does. The most problematic ones are IOMMU and interrupt remapping (IVRS tables). The boards usually have the ACPI tables, but they tend to be buggy since windows doesn't use them. Getting a sbios that works properly with Linux is the best bet unfortunately.

          Comment


          • #6
            agd5f cool, thanks for the answer, so can I say that the linux fixes are quirks fixes in the end?

            Comment


            • #7
              Originally posted by andrei_me View Post
              agd5f cool, thanks for the answer, so can I say that the linux fixes are quirks fixes in the end?
              In general the showstopper problems on Linux are platform issues that are fixed in the sbios. There are fixes in the driver too, but they tend to be for smaller corner case issues.

              Comment


              • #8
                This sounds like an important thing to know. Which boards/OEMs have requested Linux support? Seems logical that we should be buying their hardware in this case.

                Comment


                • #9
                  I've had very good luck with this board combined with this memory and my 2400g. I had some issues with the 4.16 kernels and a few GPU hangs while playing Batman Arkham City but all in all my Raven Ridge has been excellent. I'm running Mageia 7 (cauldron) kernel 5.0.6 and Mesa 19.0.1.

                  I've read many a horror story about the issues people have had with their Raven Ridge systems, I guess I've been fortunate mine has been so well behaved.

                  I hope Michael's rig behaves itself because the 2400g really is a fascinating processor.

                  Comment


                  • #10
                    Originally posted by agd5f View Post
                    On the graphics side, we use a few commercial boards, but mostly AMD engineering boards and OEM platforms where Linux support was requested.
                    That does not yet translate into specific products one could buy.

                    This biggest issues generally come down to UEFI and ACPI. Most OEMs only validate windows and windows doesn't enable a bunch of features that Linux does. The most problematic ones are IOMMU and interrupt remapping (IVRS tables). The boards usually have the ACPI tables, but they tend to be buggy since windows doesn't use them.
                    If you've got a specific recommendation for kernel parameters or ".config" options to use to disable such problematic features, please let us know. I for one certainly would not miss a few percent performance if it was that what it would take to achieve reasonably long uptimes while using amdgpu.

                    Comment

                    Working...
                    X