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

 
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.
  • (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.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (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?