The Linux Desktop Could "Soon" Get Support For Vulkan With 10-Bit Color Enabled
Enabling 10-bit color is a non-issue on proprietary operating systems. That is far from being the case on the GNU/Linux desktop. Enabling 10-bit color on GNU/Linux is easy enough, but things like the Vulkan graphics API, the Steam games store and launcher, the KDE Plasma and Deepin desktop environments and Chromium hardware acceleration do not work.
mpv developer Niklas Haas has submitted patches to the Mesa graphics stack that make it possible to run Vulkan games and applications on GNU/Linux desktops when 10-bit color is enabled.
Enabling 10-bit color on GNU/Linux desktop systems using the X display server is a very simple matter of adding
"DefaultDepth 30" to a configuration file in
/etc/X11/xorg.conf.d/. It can look like this:
You will see a message saying
Pixel depth = 30 bits stored in 4 bytes in the
Xorg.0.log file in
/var/log if 10-bit color gets enabled.
Actually using a GNU/Linux desktop with 10-bit color depth enabled is a entirely different matter.
The popular KDE Plasma and Deepin desktop environments will not even load if 10-bit color is enabled. Xfce, LXQt, GNOME, Openbox and other desktop environments do not have that particular problem but they all share quite a few others. The Chromium web browser loses hardware acceleration when 10-bit color is enabled, and the Mesa graphics stack loses its ability to run any game or application using the Vulkan graphics API. That applies to both the Mesa RADV Vulkan driver for AMD graphics cards and the Mesa ANV Vulkan driver for Intel graphics.
The vkmark Vulkan benchmark refuses to start with a cryptic message about
Error: No suitable Vulkan physical devices found and
vkcube bails with
Could not find both graphics and present queues when Mesa Vulkan drivers are used and 10-bit color is enabled.
The AMDVLK Vulkan driver for AMD graphics cards, on the other hand, can run Vulkan applications when 10-bit color is enabled - but there is a minor problem with color accuracy. The colors become somewhat more psychedelic than they should be when AMDVLK outputs to a 10-bit color enabled display.
The AMDVLK Vulkan driver is at least capable of running Vulkan applications when 10-bit colors are enabled, so it is a step ahead of the Mesa RADV driver even if the colors it produces are all wrong.
mpv To The Rescue
mpv developer Niklas Haas has taken it upon himself to ensure that Vulkan applications work right on GNU/Linux machines. He has submitted a patch for Mesa that allows Vulkan surfaces to be created when 10-bit color is enabled.
The patch has not yet merged into the Mesa git master tree. There is a fair chance that it will be. RedHats graphics engineer Michel Dänzer had this to say when we asked if the patch will be merged into Mesa master:
"seems likely to get merged soon"
Developer Niklas Haas sees no reason why the patch shouldn't be merged to Mesa master.
"Now we just need to wait for mesa to merge the MR.
I don't see any obstacles for them to do so. Somebody just needs to actually do it."
"The tl;dr is that libplacebo has supported this for like 2 years but mesa has not, so I finally got around to making a patch for mesa."
mpv still has some issues with VAAPI hardware acceleration when 10-bit color is enabled so you will want to use
--hwdec=no if you compile a patched Mesa tree and you try to play videos on a 10-bit Vulkan surface.
There's Still A Long Road Ahead Before 10-Bit Works As Expected On GNU/Linux
Steam when 10-bit color enabled on Linux. It doesn't work as of March 2021, it just dies with a "Segmentation fault".
Mesa Vulkan support for 10-bit color depth on Linux will be a nice step in the right direction, but there is still a lot of work to be done because overall Linux-support for 10-bit color is at a place where "everything just works".
The current reality is that everything does, in fact, not "just work" and that will remain the case even if Mesa does get proper 10-bit support for applications using the Vulkan graphics API.
The Steam game store and launcher says "failed to create drawable" before it dies with a
Segmentation fault when 10-bit color is enabled on Linux. There has been an open bug about that particular issue since April 2016.
The KDE Plasma and Deepin desktop environments won't even start, all you get is a fine black screen with a mouse-pointer.
There is no hardware acceleration in Chrome or Chromium.
..and those are just a few of the bigger issues you will run into if you enable 10-bit color on a GNU/Linux desktop machine today. GNU/Linux will surely get to a point where 10-bit "just works" someday, but it won't be there any time soon.