What to expect from Vulkan?

Announcements
#1

Hi RA team, I’d like to know what are your expectatives from Vulkan ? What can we expect on speed gains and others ? Or is it gonna be only faster shaders and overlays…

Also I’d like to know if Vulkan has any minimal video card requirements, for example old intel hd models should work with time ?

Thanks, it’s great to know vulkan is going in RA. Best news of the day.

#2

Unfortunately, I don’t think Vulkan is going to be wildly exciting for day-to-day end-users. Eventually, we’ll be migrating to a Vulkan-native shader format, though the existing shaders will be supported indefinitely (as long as Nvidia keeps distributing their Cg Toolkit/Framework). Once we nail the new format down, I’ll be converting most of the existing shaders to it. There may be other benefits that end-users will be able to experience but it’s too early to really tell right now.

Currently, on the Intel front, only Broadwell works well. Haswell works in-game but the menu doesn’t show up. Ivy bridge is currently broken (though maister just put up a PR that may fix it for ivy bridge; we’ll have to do some testing). Sandy bridge and earlier is out of the question, according to Intel. For Nvidia, their binary driver (i.e., linux and windows) supports anything after Fermi, and Fermi might make it in the future. For AMD, their alpha-ish Vulkan driver is Windows-only and GCN 1.2+, IIRC; no word on linux support.

Note: our current Vulkan context is Wayland (i.e., linux) only but we’ll be extending that to more contexts in the future.

#3

I’m curious if it could help with display lag. From what I’ve read Vulkan is supposed to be a way to get more direct access to the GPU and maybe sort of get around the driver’s “black box”. Maybe that sort of access could lead to a more efficient form of Vsync that doesn’t hit the CPU as hard as Hard Sync Frames 0. And maybe it could get as low latency as KMS in Windows or even lower. I’m just speculating :E

#4

The way Vulkan handles multi-pass shaders could have significant performance improvements for mobile GPUs. Currently, multi-pass shaders require writing the output of one shader pass to memory before reading it in again as input the the next pass. This is very bad for mobile GPUs as they are slow at accessing memory (it also consumes a lot of power). Vulkan’s renderpasses, with suitable shaders, will significantly reduce the need for this repeated writing to and reading from memory. AMD reckons it can help with performance for desktop GPUs too.

#5

Well, it looks promising after all, even is benefits right now may not be extraordinary, could have a quite nice future. Does anyone know what happens with Intel Bay-Trail and Braswell chips ? Will they support Vulkan ?

Thanks.

#6

I can run software rendered cores with 0ms audio latency with Vulkan on the experimental Ivy Bridge Mesa drivers and have no audio crackling or video tearing.

This is using Vulkan RA running in Wayland.

Frame time deviations are much lower than GL - a best case estimate for GL was something like 5% (usually it was more like 15% or higher though), with Vulkan it’s more like 0.009%, on a bad day it might be 0.030%.

Also, we can even make software rendered cores faster with Vulkan (by a bit) because we have a new environ callback made for command buffer APIs like Vulkan where we can grab a pointer handle to a block of GPU memory (specifically allocated for the core), and then be able to blit straight to this from core land. This prevents us from having to copy the video frame from CPU to GPU when the libretro frontend is about to render to the screen.

I haven’t been able to make GPU screenshots or GPU recording work yet on this experimental Ivy Bridge driver, but if maister’s writeup is to be believed, it should be a vast improvement over GL’s recording performance.