Announcement

Collapse
No announcement yet.

AMDGPU DC Display Code Ported To GCN 1.0 "Southern Islands" GPUs

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

  • AMDGPU DC Display Code Ported To GCN 1.0 "Southern Islands" GPUs

    Phoronix: AMDGPU DC Display Code Ported To GCN 1.0 "Southern Islands" GPUs

    The AMDGPU DC "Display Code" stack formerly known as DAL that's been in the mainline kernel the past several releases might soon see support for GCN 1.0 "Southern Islands" GPUs. This is the big display code stack necessary for atomic mode-setting, FreeSync/Adaptive-Sync, HDMI/DP audio, and other modern display features. When AMD brought up this DC stack, they hadn't brought it back to GCN 1.0 since for those original GCN GPUs they by default still use the Radeon DRM driver. But now they might soon see AMDGPU DC support...

    http://www.phoronix.com/scan.php?pag...DC-For-GCN-1.0

  • #2
    I am not too familiar with all of the components of the AMD stack and its history, but couldn't they try to bring all GCN cards to the modern stack if this work lands?! What else is needed? I vaguely remember some work on the UVD/VCE components as well, does anyone now what the status of that work is? Or are there hardware limitations that prevent GCN 1.0 / 1.1 cards from benefitting from the new stack (AMDGPU, DC etc.)?

    Comment


    • #3
      They probably need to accept those patches on some day anyway to enable amdgpu by default for SI to support Vulkan.
      Can understand they focus on recent generations first.
      But right now its an extra burden for SI Proton users, as they need to switch from default radeon first to amdgpu and editing kernel parameters. So they shouldnt wait too long.

      Comment


      • #4
        You don't need to edit kernel parameter for amdgpu support. You just need to load the driver with some options. That's easily package-able for every distro and also easy to install for an user.

        Comment


        • #5
          Originally posted by ms178 View Post
          ... I vaguely remember some work on the UVD/VCE components as well, does anyone now what the status of that work is? ...
          Last thing I know it was pending new firmware release from AMD.

          Comment


          • #6
            Does that mean all that's missing now is the video acceleration stuff for SI? Someone outwith AMD was working on it, but I think they got stuck

            Comment


            • #7
              Originally posted by ms178 View Post
              I am not too familiar with all of the components of the AMD stack and its history, but couldn't they try to bring all GCN cards to the modern stack if this work lands?! What else is needed? I vaguely remember some work on the UVD/VCE components as well, does anyone now what the status of that work is? Or are there hardware limitations that prevent GCN 1.0 / 1.1 cards from benefitting from the new stack (AMDGPU, DC etc.)?
              from what I remember there are large numbers of differences in features of the cards (both in terms of instructions supported and the various IP blocks being used)

              Comment


              • #8
                Originally posted by FireBurn View Post
                Does that mean all that's missing now is the video acceleration stuff for SI? Someone outwith AMD was working on it, but I think they got stuck
                Nope, these patches don't touch video decoding.

                Comment


                • #9
                  Originally posted by lumks View Post
                  You don't need to edit kernel parameter for amdgpu support. You just need to load the driver with some options. That's easily package-able for every distro and also easy to install for an user.
                  Code:
                  /vmlinuz-linux-amd-staging-drm-next-git root=ZFS=/ rw zfs=antergos quiet amdgpu.cik_support=1 amdgpu.powerplay=1 amdgpu.dc=0 radeon.cik_support=0 modprobe.blacklist=radeon modprobe.blacklist=dell_smbios elevator=noop
                  echo 'Loading initial ramdisk ...'
                  There's my kernel command line. For CIK and SI users it is necessary, for some it's as simple as setting xorg.conf or blacklisting the radeon module, the rest have no choice since their card is too new or old.

                  Depending on the distribution, they could make, say, amdgpu-cik, amdgpu-si, and amdgpu packages that apply the appropriate kernel command line or modprobe settings, module blacklisting, maybe even xorg.conf or a reference. Until then, we have to edit the kernel or system files. I prefer editing the command line because below:

                  It used to have amdgpu.dc=1, but it only works like that on my 1080p monitor. Three weeks ago I had to switch to a crappy 1024x768 VGA monitor...first boot I was worried since the display cutout directly after GRUB, I waited a little bit and eventually rebooted it, switched to 4.14 LTS with a minimal command line, it worked, and tweaked my settings one at a time until I found dc=1 was the culprit. MSI R7 260x 2GB, Mesa 18.2.2, every Arch Linux 4.18 kernel and amd-staging from about three weeks to 4 days ago when not using 1080p over HDMI.

                  If I didn't have a backup kernel with sane settings, I'd have had to just guess at it. If they'd have been in /etc/modprobe.d/amdgpu.conf I wouldn't have been able to see what was going on to get an idea of what to change without SSH access. System packages are great for stuff that works...not so for experimental stuff where you might run into a problem.
                  Last edited by skeevy420; 10-08-2018, 07:49 AM.

                  Comment


                  • #10
                    Good cause one of the problems with AMD GPU's is how AMD tends to let slightly older hardware be left behind. 5000 and 6000 series cards are still stuck at OpenGL 3.3, while GCN 1.0 cards need you to jump through hoops to enable AMDGPU for Vulkan. This needs attention.

                    Comment

                    Working...
                    X