Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×
Open Source AMD Linux

Open Source Could Help Bring Vulkan To More AMD GPUs (phoronix.com) 38

An anonymous reader writes: AMD has confirmed that their Vulkan Linux driver will only work with the new AMDGPU kernel driver, meaning that for right now on the desktop, Vulkan will just work on the Radeon R9 285, R9 380, R9 380X and R9 Fury series — not even the other Rx 200/300 series graphics cards. This limitation exists because the AMDGPU driver only works with GCN 1.2 and newer. In time, AMD may allow the driver to work on older GCN GPUs going back to the HD 7000 series. But wait: AMDGPU is open-source. AMD is welcoming community support to help bring AMDGPU (and thereby Vulkan) to these older GPUs. The work involved would be porting GCN 1.0/1.1 support from the existing open-source Radeon DRM driver over to the new AMDGPU DRM driver. The Vulkan code itself is said to already be compatible with all GCN GPUs going back to the HD 7xxx series.
This discussion has been archived. No new comments can be posted.

Open Source Could Help Bring Vulkan To More AMD GPUs

Comments Filter:
  • by Anonymous Coward

    I wonder what GCN 1.1 is missing that makes it make sense for GCN1.2+ to use a different driver, the only feature I know of is preemptive multitasking on the GPU, which is presumably useful for multiple HSA applications?

    My Kaveri is sad now.

    • Re:GCN and HSA (Score:5, Informative)

      by bridgmanAMD ( 4376807 ) on Saturday January 16, 2016 @05:26PM (#51315631)

      GCN 1.1 is missing nothing, so tell your Kaveri to be happy.

      We already have upstream support for KV and the other GCN 1.1 parts in amdgpu, it's just not enabled by default yet, and can't be until the userspace has been available long enough to make sure we can cut over without new kernel builds breaking existing systems:


      The only question that's not fully settled is what we do for SI - extend the libdrm-amdgpu userspace library to use radeon kernel driver IOCTLs, or port the SI code from the radeon kernel driver to the amdgpu kernel driver. We have been looking at both options in parallel with developing the Vulkan userspace.

      • Can my R7 Kaveri get some fries with that?
      • by KGIII ( 973947 )

        A little late but I'm a bit slow as I've been pretty damned ill for like a week now. Suffice to say, I'm a pretty loyal AMD buyer. Thanks. I will, once in a while, buy something Intel but not often. I also hate phones and tablets so I don't spend much there.

    • Missed a bit - the reason VI is the first family enabled by default in amdgpu is that we already had upstream support for SI and CI in the radeon kernel driver, and Linux kernel rules are really strict about not breaking userspace by removing or disabling user/kernel interfaces after they have gone upstream... so we can't just disable the radeon code as soon as we have amdgpu code upstream.
  • Since the R9 380 is essentially the R9 290 rebranded I guess it works with that gpu too?

    • R9 380 is Tonga (what we call GCN 3 and the media calls GCN 1.2). R9 290 is Hawaii, which is GCN2.
  • The work involved would be porting GCN 1.0/1.1 support from the existing open-source Radeon DRM driver over to the new AMDGPU DRM driver.

    Who chose the name "Direct Rendering Manager" in the first place? Was it created before or after "Digital Rights Management"?

    And who chose the name "Graphics Core Next"? That was certainly years after the GameCube console was officially abbreviated GCN. Incidentally AMD bought the company (ATI) that bought the company (ArtX) that developed the Flipper GPU in the GameCube.

Long computations which yield zero are probably all for naught.