Slashdot Mirror


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

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.

6 of 38 comments (clear)

  1. Re:GCN and HSA by bridgmanAMD · · Score: 5, Informative

    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:

    https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/Kconfig

    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.

  2. Re:GCN and HSA by bridgmanAMD · · Score: 2

    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.

  3. Re:Spell Check by bridgmanAMD · · Score: 2

    It is actually Vulkan with a 'k' in this case:

    https://www.khronos.org/vulkan

  4. AGP by DrYak · · Score: 2

    Doesn't support R9 GPU from last year...

    On Linux, AMD has recently started a new generation of kernel module (a new one which is unified for both the opensource Gallium stack and its Mesa3D opengl AND the proprietary Catalyst OpenGL).

    Only the recent hardware has its drivers developed for this new module.
    BUT there are no technological limitation preventing Vulkan on older hardware.

    Thus:
    - Vulkan could be ported to the older modules.
    - OR a thin "Vulkan"-to-"Gallium back-end" wrapper could be written (quite possible given that both are on the very low-level "just expose the hardware functions" end of the spectrum).
    (Similar to the various VAAPI to VDPAU and vice-versa thin wrappers).
    The only practical limitation is workforce: the number of driver developper (include open-source driver) on AMD's payroll is limited.

    Also in windows, apparently my 512MB AGP card can't' do hardware accelerated browsing

    There are very practical limitations that explain why AGP can't be used for this kind of acceleration.
    The more browsers try to exploit advanced OpenGL functionnality, the harder they hit AGP limitations.
    Either you need to stick with older browsers featuring less bells and whistle (but within the capability of AGP), or upgrade the hardware.

    or decode web video video anymore, it must have forgot how.

    Had the video engine of your browser recently been swapped (Firefox did change a few things).
    Maybe the new one is only comptaible with an API that isn't experted by your card (A bit like the VAAPI vs VDPAU under Linux)

    And the stability of Flash seem to be even more random that the weather.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  5. Re:R9 290X by bridgmanAMD · · Score: 2

    Let's try that again without the copy/paste typos: Um... what exactly pisses you off ? We will be supporting Vulkan on your hardware, and amdgpu support for GCN 1.1 is already upstream.

    GCN 1.1 support in amdgpu is disabled by default at the moment because that hardware is already supported by radeon and changing the default right now will break user systems. We need to wait until userspace code with the ability to work over either driver makes its way out to most of the user systems (which means going through at least a round of consumer distro release cycles), so that picking up a kernel with amdgpu enabled for pre-VI doesn't make your system stop working.

    Catalyst-style deployment where userspace and kernel driver come as a set are not affected by upstream defaults and don't have to wait.

  6. Re:Nice by bridgmanAMD · · Score: 2

    What fragmentation are you talking about ? The Vulkan driver will be exactly the same on all of our hardware.

    https://twitter.com/grahamsellers/status/688126936648790016

    The only issue under discussion is that we are in the middle of a Linux kernel driver transition (moving from the closed-source Vulkan driver and open source radeon driver to a new amdgpu kernel driver) and the question we haven't answered yet (very few announcements are happening until the Vulkan embargo NDA lifts) is which kernel driver the Vulkan driver will use on early GCN hardware.