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.

38 comments

  1. Is vulkan free software? by Anonymous Coward · · Score: 0

    Or is it still freedom disrespecting software?

    1. Re:Is vulkan free software? by exomondo · · Score: 1

      Or is it still freedom disrespecting software?

      Vulkan isn't software at all, it is a specification.

  2. Good drivers from AMD? by Anonymous Coward · · Score: 0

    Finally wow!

    Doesn't support R9 GPU from last year... oh well, back to the same. Also in windows, apparently my 512MB AGP card can't' do hardware accelerated browsing or decode web video video anymore, it must have forgot how.

    1. Re:Good drivers from AMD? by Anonymous Coward · · Score: 1

      It's the age of software fast food. Agile developers write expendable software for disposable hardware. Pay a buck for an app with as much staying power as a wheat foam hamburger. What's your franchise? Apple or Google? Do you want a SIM with that?

    2. Re: Good drivers from AMD? by Anonymous Coward · · Score: 0

      You are whining that a decade old GPU doesn't support the accelerated display platforms today? You do realize a lot has changed and if your card can't accelerate everything it's not going to work. It's not up to the vendor or MS to make your 10-15 year old shit work today, stay on Windows XP or buy a new faster $30 graphics card.

      So entitled...

  3. ... but it probably won't by Hognoxious · · Score: 1

    n/c

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  4. GCN and HSA by Anonymous Coward · · Score: 1

    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.

    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: GCN and HSA by IBME · · Score: 1

      Can my R7 Kaveri get some fries with that?

    4. Re: GCN and HSA by Anonymous Coward · · Score: 0

      From your username and writing style I guess that you're an AMD employee, so thank you for trying to do it another way than regular old closed source. Looking forward to my next AMD purchase!

    5. Re:GCN and HSA by Anonymous Coward · · Score: 0

      I find it interesting that a representative from AMD posts here.

      I find it a bit sad that hardly anyone with questions or concerns about AMDs Open source strategy takes the oppurtunity to ask you directly, or even mod your answers up.

      Thanks for the effort, keep it up.

    6. Re:GCN and HSA by Anonymous Coward · · Score: 0

      Nothing but legal agreements. Pretty sure the first closed source driver for Vulkan will work on Kaveri, but not the open source one.

    7. Re:GCN and HSA by bridgmanAMD · · Score: 1

      Vulkan is being released first as closed source then open source, but open source should support at least the same hardware as the closed source did.

    8. Re:GCN and HSA by KGIII · · Score: 1

      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.

      --
      "So long and thanks for all the fish."
  5. Carrizo too by Anonymous Coward · · Score: 0

    Carrizo and its desktop incarnation, Bristol Ridge, do/will work with amdgpu as well.

  6. Spell Check by Anonymous Coward · · Score: 0, Funny

    Vulcan.

    Stupid, stupid person.

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

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

      https://www.khronos.org/vulkan

  7. Plan to OpenSource by DrYak · · Score: 1

    The long term plan of AMD for Vulkan is to open it.

    Vulkan is very low-level, there isn't that much room left for some "secret sauce" or other IP that needs to be protected.
    In Vulkan world (and DX12), the kind of magic that went into OpenGL and DirectX now goes directly into the 3D Engine.
    On Linux, Vulkan is very much comparable to the various "back-end" used by the Galium3D stack above which the Mesa openGL-state-tracker runs.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
    1. Re:Plan to OpenSource by Anonymous Coward · · Score: 1

      It seems Vulkan brings back the concept of classic "Display Lists" as "Command buffers" but with the option of editing them and not simply having to redefine an entire mesh simply because one bone moved due to dynamics.

  8. 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 ]
  9. R9 290X by Anonymous Coward · · Score: 0

    As an R9 290X owner, I'm not gonna lie, this kinda pisses me off.

    It seems like AMD's hardware support roadmap is getting shorter and shorter.

    1. Re:R9 290X by bridgmanAMD · · Score: 0

      Um... what exactly pisses you off ? We're going to be supporting Vulkan on your hardware, and amdgpu support for your hardware is already upstream in amdgpu.

      Support for GCN 1.1 in amdgpu is already upstream and has been for a while; it's just disabled by default because that hardware is already supported by radeon and we don't have the option to change that default until suitable userspace code (eg Mesa) has made its way out to most user systems so that existing systems don't break.

    2. 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.

    3. Re:R9 290X by Anonymous Coward · · Score: 0

      "Um... what exactly pisses you off ?"

      Your GPUs can't sync to most TVs over HDMI and almost always refuse to get a 1:1 pixel match because of your bullshit forced overscan in drivers, for starters, and that CANNOT BE DISABLED so I'm stuck using DVI to VGA converter to hook up to my 32" TV to get a near 1:1 pixel match. And it's been like that for AGES, from the HD4000 series up.

      nVidia is similarly guilty, but your GPUs do this bullshit WAY more often than nVidia.

    4. Re:R9 290X by Anonymous Coward · · Score: 0

      Get a new TV and dump your shitty ten year old 32" one.

  10. Nice by Anonymous Coward · · Score: 0

    Fragmentation before the API even got started! Nice job Kronos and AMD.

    1. 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.

  11. No by Anonymous Coward · · Score: 0

    All the open source in the world doesn't matter if you repeatedly build garbage, which is what AMD does. You'll save money by buying AMD, but you won't be doing yourself any favors.

  12. R9 290 by shione · · Score: 1

    Since the R9 380 is essentially the R9 290 rebranded I guess it works with that gpu too?

    1. Re:R9 290 by bridgmanAMD · · Score: 1

      R9 380 is Tonga (what we call GCN 3 and the media calls GCN 1.2). R9 290 is Hawaii, which is GCN2.

    2. Re:R9 290 by Anonymous Coward · · Score: 0

      :(

    3. Re:R9 290 by bridgmanAMD · · Score: 1

      Why the sad face ? Vulkan will run on both.

      R9 390 and R9 290 are both based on Hawaii, while R9 380 and R9 285 are both based on Tonga.

    4. Re:R9 290 by Blaskowicz · · Score: 1

      This news beats what I assumed till now : that the amdgpu driver is ONLY for the newest GPUs.

      We have it much better now but the question is then of timing, i.e. will you get support in time for Ubuntu 16.04? Or perhaps, Ubuntu 16.04.1 (maybe Mint 18.1).

      At least they didn't announce support for GCN 1.0/1.1 many monthes ago, leading to more waiting frustration but it seems like this takes ages and no public hard schedule dates could be given. That makes AMD seem fairly understaffed (though the linux kernel has its own schedule too, and Xorg, Mesa etc. ).
      Hoping AMD will not skimp on software and drivers as they get more "established". That is the main weakness compared to their well known GPU competitor, or so it is perceived.

    5. Re:R9 290 by shione · · Score: 1

      ah, oops. When I typed R9 380 above there I was thinking of the R9 390 which is the R9 290 rebranded.

      Like the AC this news makes me sad because the R9 380 isn't in the list so we have to hope the community will help give it support.

    6. Re:R9 290 by bridgmanAMD · · Score: 1

      R9 380 is one of the VI parts which is already enabled by default in upstream amdgpu.

      Not sure where the idea about community porting GCN 1.1 came from, that code has been upstream for months. The only question is GCN 1.0 since we haven't finalized whether to support that with amdgpu or radeon, so in the meantime people are writing "OMG what if they never support it ?" stories to get traffic.

  13. Who chose the names DRM and GCN? by tepples · · Score: 1

    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.

    1. Re:Who chose the names DRM and GCN? by TheRealMindChild · · Score: 1

      DRM in the linux kernel is old enough that I remember one of 3 drivers being for my 3dfx voodoo banshee card

      --

      "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson