Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Thursday December 21 2017, @09:53AM   Printer-friendly
from the Vulkans-cannot-lie dept.

After a long wait, AMD is finally delivering on their two-year promise of open-sourcing their AMD Vulkan driver for Linux!

Ahead of the Vulkan 1.0 debut nearly two years ago, we heard that for AMD's Vulkan Linux driver it was initially going to be closed-source and would then be open-sourced once ready. At the time it sounded like something that would be opened up six months or so, but finally that milestone is being reached! Ahead of Christmas, AMD is publishing the source code to their official Vulkan Linux driver.

What Is This Driver?

This Vulkan driver they are open-sourcing is their "official" Vulkan driver as found for Linux users already within the AMDGPU-PRO driver. It's also the shared code-base to their Vulkan Windows driver. Basically, it's their full-featured Vulkan driver that AMD has been investing in the past 2+ years.

With this being the official AMD Vulkan driver and from their shared code-base, it's important to note that this is NOT a driver living within Mesa. This AMD Vulkan driver lives in its own code-base and is not using or dependent upon Mesa/Gallium3D but rather just interfacing with libdrm / AMDGPU DRM / LLVM directly.

... With this official Vulkan driver being shared across platforms, I was curious if this open-source access would allow it to be built on Microsoft Windows or if they are not opening up all of the bits for the Windows integration, etc. The AMD response to this question was, no, the code they are pushing out was stripped down to just their Linux code.

What About RADV?

... RADV was started out by David Airlie and Bas Nieuwenhuizen in what they figured would be a short-lived effort while waiting on the AMD open-sourcing milestone to occur. But with this AMD milestone having taken much longer than anticipated, in the mean time RADV has become a roughly feature complete and compliant Vulkan driver with modest performance potential. David Airlie has indicated in our forums that RADV is mature enough now where he doesn't plan to stop work on this driver when the AMD open-sourcing of their driver happens. Thus moving forward we're likely to see these two separate open-source Radeon Vulkan drivers continue.

At least with the official Vulkan driver not being Mesa-based, it isn't "stepping on the toes" of RADV or anything as it will continue to be its own separate code-base while RADV continues to live within Mesa.

Only time will tell what will happen in the future if RADV developers will lose interest and stop maintaining the driver or if Linux gamers will continue preferring RADV since its already packaged and available on many Linux distributions, etc.

It is worth noting that AMD is only opening the parts of their proprietary driver that are related to Vulkan; the OpenGL components are remaining closed-source.

With two competing open-source drivers now available (AMD's AMDGPU and Mesa's RADV), will this mean the end of one of them going forward or will both continue to live on independently? Does having two choices merely further fragment the Linux ecosystem, or is it good to be able to switch between drivers where one may be lacking in performance or compatibility with certain software and games?

Further reading:


Original Submission

Related Stories

Vulkan 1.1 Specification Released 13 comments

Vulkan 1.1 Specification Released: Open-source Tools, SDKs, and Launch Driver Support

Since the release of Vulkan 1.0 in February 2016, the successor to OpenGL slowly but surely made its way into applications and game engines. Today, roughly two years later, the Khronos Group is releasing Vulkan 1.1 and SPIR-V 1.3 specifications, and much like Vulkan 1.0's 'hard' API launch these are accompanied by updated developer tools, open source conformance tests, and launch driver support from GPU vendors. [...] In sum, the evolution of Vulkan from 1.0 to 1.1 is three-pronged: integration of developer-requested functionalities, driver support and seamless porting of Vulkan to more platforms, and then practical implementation by way of a developed ecosystem.

Moving straight into the core changes, Vulkan 1.1 brings two new wide-ranging functionalities: protected content and subgroup operations. The former utilizes low-level restrictions such that applications can render and display using resources they cannot access or copy, in turn securing playback and display of protected content. While ostensibly for DRM purposes, Khronos noted that Vulkan was exposing GPU capability rather than pushing for hardware-level DRM, leaving usage or implementation up to the developers.

So on the one hand, developers may choose to create a highly-restrictive multi-layered DRM scheme with a high degree of granularity. On the other hand, perhaps the feature could be used for an advanced low-level adblocker, not only for browsers but one that could hook onto ad-serving mobile and desktop games and applications. All might be possible with Vulkan 1.1 and beyond. To that end, Vulkan is in many ways simply looking to enable what is possible – in the purest sense of the idea – on GPUs.

That idea carries over with the new 'subgroup operations', where a set of threads can communicate and coordinate amongst themselves where normally this would be done by accessing off-chip memory. Ultimately, this offers developers a method of parallelizing certain workloads to a very high degree, and while compute and deep learning are the more obvious use cases, subgroup operations are not limited to only compute shaders and could presumably be used for graphical purposes. Naturally, the new SPIR-V 1.3 likewise supports subgroup operations.

Khronos Group press release and Vulkan Resource Page.

SPIR: "Standard Portable Intermediate Representation"

Previously: Khronos Group Releases Vulkan 1.0 Graphics Specification

Related: Open Source Doom 3 BFG Gets a Vulkan Renderer
AMD Finally Pushing Out Open-Source Vulkan Driver


Original Submission

AMD Plays Catch-Up with Ryzen Mobile Drivers 11 comments

AMD's Latest Radeon Drivers Finally Bring Official Support to Ryzen Mobile

When Ryzen Mobile launched in October of 2017, most probably did not envision the poor state its drivers would be in for over a year. AMD never released an official driver for its Raven Ridge-based mobile APUs, so users had to rely on OEMs like HP that only released a single driver in November.

But at CES 2019, AMD promised to fix the situation with official support for Ryzen Mobile through its Adrenaline drivers. Those are the same drivers that already supported AMD's desktop APUs based on the same Raven Ridge architecture used for Ryzen Mobile. Today, AMD finally delivered on that promise with its newest 19.2.3 drivers.

According to AMD's release notes, the new driver offers an average of 10% more performance in gaming compared to the October Ryzen Mobile driver, and in eSports titles specifically, an average of 17% more performance. Of the games tested, most of them showed double-digit performance gains, especially Counter Strike: Global Offensive and Player Unknown's Battlegrounds. These kinds of gains could easily turn an unplayable experience into one that is playable, and such extreme gains are seen because this driver is a year and a half newer than the launch revision.

Also at Engadget.

Related: AMD Finally Pushing Out Open-Source Vulkan Driver
AMD Ceases Graphics Driver Development for 32-Bit Operating Systems


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 2, Informative) by Anonymous Coward on Thursday December 21 2017, @10:16AM (8 children)

    by Anonymous Coward on Thursday December 21 2017, @10:16AM (#612744)

    So still no AMD GPUs can be used in freedom. Sigh.

    • (Score: 3, Insightful) by Wootery on Thursday December 21 2017, @10:18AM (7 children)

      by Wootery (2341) on Thursday December 21 2017, @10:18AM (#612747)

      There's no reason for FOSS advocates to always bite the hand that feeds, you know.

      • (Score: 0) by Anonymous Coward on Thursday December 21 2017, @12:23PM

        by Anonymous Coward on Thursday December 21 2017, @12:23PM (#612761)

        They get off on it, it's their thing. That way there's always an excuse for crappy hardware support.

      • (Score: 0, Touché) by Anonymous Coward on Thursday December 21 2017, @01:25PM

        by Anonymous Coward on Thursday December 21 2017, @01:25PM (#612768)

        It's their form of virtue signaling.

      • (Score: 5, Insightful) by Arik on Thursday December 21 2017, @01:31PM (4 children)

        by Arik (4543) on Thursday December 21 2017, @01:31PM (#612769) Journal
        Why can't you slaves quit complaining and show a little gratitude? Didn't I give you extra slop yesterday? I didn't have to do that!

        Ungrateful wretches.
        --
        If laughter is the best medicine, who are the best doctors?
        • (Score: 0) by Anonymous Coward on Thursday December 21 2017, @02:12PM

          by Anonymous Coward on Thursday December 21 2017, @02:12PM (#612784)

          There are only two alternatives: Starve to death or kill the master.

        • (Score: 2, Informative) by Wootery on Thursday December 21 2017, @02:23PM (1 child)

          by Wootery (2341) on Thursday December 21 2017, @02:23PM (#612788)

          If you're a full-bore Stallmanite who thinks proprietary software is nothing short of evil - the sort willing even to cheapen the horror of slavery in the name of berating corporations they don't like - there's not much I can say.

          To the less extreme FOSS fans among us, this is clearly step in the right direction, and very much a Good Thing™. We don't berate institutions for doing Good Things.

          • (Score: 1, Informative) by Anonymous Coward on Friday December 22 2017, @08:51AM

            by Anonymous Coward on Friday December 22 2017, @08:51AM (#613160)

            If you're a full-bore Stallmanite who thinks proprietary software is nothing short of evil

            You don't need to even know who RMS is to believe that proprietary software is nothing short of evil. All it takes to convince someone of that is having them follow the Intel IME fiasco.

        • (Score: 0) by Anonymous Coward on Saturday December 23 2017, @02:57AM

          by Anonymous Coward on Saturday December 23 2017, @02:57AM (#613504)

          Slaves?

          HAHHAAHHAAHAHHAHAHAAHHAHAHAHAHA

          Entitled much?

  • (Score: 3, Funny) by Wootery on Thursday December 21 2017, @10:16AM (2 children)

    by Wootery (2341) on Thursday December 21 2017, @10:16AM (#612745)

    I was wondering if the Linux driver was less sophisticated than the Windows driver (Linux has long been a second-class citizen for graphics drivers, of course), but apparently not. From TFA:

    It's also the shared code-base to their Vulkan Windows driver. Basically, it's their full-featured Vulkan driver that AMD has been investing in the past 2+ years.

    A real grown-up graphics driver, for Linux, released as FOSS? I guess we no longer need to pin our hopes on Elon for flying pigs.

    Could 2018 be the year of the Linux desktop?

    • (Score: 2) by unauthorized on Thursday December 21 2017, @06:52PM

      by unauthorized (3776) on Thursday December 21 2017, @06:52PM (#612890)

      Every year is the year of the Linux desktop! (p >= 1.0)

    • (Score: 0) by Anonymous Coward on Friday December 22 2017, @08:43AM

      by Anonymous Coward on Friday December 22 2017, @08:43AM (#613157)

      If by "grown up" you mean crashes all the time.

      Even die hard Windows fan boys will admit this. With the stable versions of Windows (XP, 7), just about every blue screen of death is caused either by faulty hardware or by drivers.

      Open source people tend to care a lot more about fixing bugs than about features and deadlines. Building a driver as closed source and then opening it would mean that by now the only thing left is to find and fix all the bugs.

      Remember Netscape? That's probably the best known example of open sourcing a closed product, and fixing that took basically a complete rewrite.

  • (Score: 2) by pe1rxq on Thursday December 21 2017, @10:18AM (13 children)

    by pe1rxq (844) on Thursday December 21 2017, @10:18AM (#612746) Homepage

    It will depend on the code quality and commitment from AMD
    Just dumping some code on the internet rarely works out as planned. Especially since this is from a source base that runs both on Windows and Linux. That means it is probably filled with all kinds of NIH abstractions and will not look like a typical Linux driver.
    Will AMD be willing to keep this driver up to date? Will they actively work to integrate it with Xorg and/or the kernel? And while doing so will they listen to criticism?

    • (Score: 4, Insightful) by Wootery on Thursday December 21 2017, @10:22AM (12 children)

      by Wootery (2341) on Thursday December 21 2017, @10:22AM (#612748)

      Will AMD be willing to keep this driver up to date?

      You see that they're Freeing their Linux driver, and your response is to question their commitment?

      Why would they have invested in a Linux port if they had no intention of maintaining it?

      Will they actively work to integrate it with Xorg and/or the kernel?

      Does it matter? What matters is that it's a working Free driver.

      And while doing so will they listen to criticism?

      Of which there will clearly be plenty.

      • (Score: 3, Informative) by pe1rxq on Thursday December 21 2017, @10:53AM (8 children)

        by pe1rxq (844) on Thursday December 21 2017, @10:53AM (#612753) Homepage

        A working driver with no commitment is a problem: I don't want to be pinned to a specific release or version.
        Will it work with next months kernel? I might need it for a different reason.

        To often I have been burned by some guys trowing stuff on the internet and then just disappear. It will work nicely as long as you don't mind getting stuck in that single moment in time.

        • (Score: 2, Insightful) by Anonymous Coward on Thursday December 21 2017, @11:29AM

          by Anonymous Coward on Thursday December 21 2017, @11:29AM (#612754)

          ok, so ignore it and don't use it.
          AMD will then respond to your attitude as they see fit, etc.
          but stop whining about it, because there are other people who would prefer that AMD does this sort of thing in the future as well (which they may not do if the response they get is your response).

        • (Score: 4, Informative) by Runaway1956 on Thursday December 21 2017, @01:35PM (6 children)

          by Runaway1956 (2926) Subscriber Badge on Thursday December 21 2017, @01:35PM (#612773) Journal

          Will it work with next months kernel?

          Recompile? Easier yet - hand that task off to DKMS. When you install your new kernel, DKMS automagically compiles your driver to work with it. I suppose that if you have special needs, that my not be good enough - but it works well for me. I will note that Nvidia has a number of legacy drivers available for download, and they all seem to compile with new kernels. There may come some time when they no longer compile with the most up-to-date kernels, but at the moment, things do work.

          • (Score: 2) by Wootery on Thursday December 21 2017, @02:12PM (5 children)

            by Wootery (2341) on Thursday December 21 2017, @02:12PM (#612783)

            Does Linux promise API compatibility between minor releases?

            • (Score: 4, Insightful) by Runaway1956 on Thursday December 21 2017, @03:23PM

              by Runaway1956 (2926) Subscriber Badge on Thursday December 21 2017, @03:23PM (#612815) Journal

              I think that they work really really hard toward that goal - but it's not exactly a "promise". When you upgrade, you may expect problems now and then. If you're using the latest and greatest, you may expect problems more often than people who restrict themselves to stable. Since I'm on the testing branch of Debian, I experience issues relatively frequently. On the other hand, if you're still using kernel 3.2 on some distro that was released five years ago, you won't have very many problems. Of course, you are facing obselesence issues, eventually.

              For amusement, you might consider this: Automotive technology is around 100 years old now. And, despite that 100 years history, sometimes, the manufacturers create lemons. Linux, Windows, Mac, Gentoo - they all have their lemonade specials. Unlike the automotive industry, software doesn't make guarantees, and it's unlikely that any court will take your side if you should sue. Stuff happens, and eventually, some combination of circumstances will bite you in the ass.

            • (Score: 2) by LoRdTAW on Thursday December 21 2017, @03:39PM (1 child)

              by LoRdTAW (3755) on Thursday December 21 2017, @03:39PM (#612820) Journal

              The "stable kernel API/ABI" argument has been an issue for a while. Proponents say it will solve all of our hardware problems while opponents say it will allow hardware manufactured to slip in more binary blobs. Both arguments are valid but the latter means drivers can be neglected and left to rot while Windows drivers are carefully tweaked and optimized.

              • (Score: 2) by Wootery on Thursday December 21 2017, @03:55PM

                by Wootery (2341) on Thursday December 21 2017, @03:55PM (#612822)

                Surely it's less evil for a blob to be left to rot, than for it to be periodically unearthed and lazily hacked into just about coping with the API changes, no?

            • (Score: 0) by Anonymous Coward on Friday December 22 2017, @08:49AM (1 child)

              by Anonymous Coward on Friday December 22 2017, @08:49AM (#613159)

              Does Linux promise API compatibility between minor releases?

              API, yes between minor versions, mostly between major versions. However, this is not handled by the Linux people, the API is controlled by the Glibc people.
              ABI, yes, even between major versions ("we don't break user space").

              However, this doesn't matter as aside from certain USB stuff, drivers need kernel internals, and internals are NEVER guaranteed to stay the same.

              • (Score: 2) by Wootery on Friday December 22 2017, @09:20AM

                by Wootery (2341) on Friday December 22 2017, @09:20AM (#613162)

                ABI, yes, even between major versions ("we don't break user space").

                I meant the API and ABI for kernel modules.

      • (Score: 2, Informative) by djh2400 on Thursday December 21 2017, @02:38PM (2 children)

        by djh2400 (725) on Thursday December 21 2017, @02:38PM (#612792)

        My understanding is that AMD feels they must maintain their own driver in order to support enterprise/business customers. They can't just leave a complex video driver for a flagship line of products up to the whims of the Mesa team, which may or may not break things at new versions or perhaps may or may not accept pull requests from AMD themselves. In order to provide support for their product (graphics cards under Linux), they need something that they fully control. (Although, why would they be picky about control on the graphics side while happily letting the Linux team control the built-in Vega drivers?)

        Furthermore, I believe that, to them, the idea of adopting RADV from Mesa directly — even with the ability to add their own, custom patches — ultimately would create more work for them since their in-house driver is part of and shares many similarities to the Windows driver. Maintaining two distinctly code bases is likely something they feel would cost too much or that they can't handle effectively.

        Of course, Mesa is now free to peruse AMD's code and copy over any missing features, just as AMD is now capable of from Mesa. My guess is that neither party feels they can leave the graphics-driver project entirely up to the other, and so both drivers will probably live on for now. I expect that regular users will be happy sticking with Mesa while business customers will stick to a driver which is "officially supported" (although RADV outperforms AMDGPU in certain benchmarks already). Though, I admit my understanding of the underlying issues and/or politics is probably limited, so take all of this with a grain of salt. I'd love to be corrected if someone knows more!

        • (Score: 2, Informative) by djh2400 on Thursday December 21 2017, @02:41PM

          by djh2400 (725) on Thursday December 21 2017, @02:41PM (#612794)

          (Although, why would they be picky about control on the graphics side while happily letting the Linux team control the built-in Vega drivers?)

          My apologies; I meant Ryzen drivers. I was intending to contrast how the graphics line is managed from their perspective compared to the processor line.

        • (Score: 3, Informative) by Wootery on Thursday December 21 2017, @03:06PM

          by Wootery (2341) on Thursday December 21 2017, @03:06PM (#612807)

          For OpenGL, we'll still need Mesa. AMD have only Freed their Vulkan driver.

(1)