Как изменить opengl на vulkan

Введение.

В Linux для видеокарт AMD используется несколько реализаций Vulkan-драйвера, эта заметка призвана решить задачу, когда угораздило работать с программами, включая тестирование, требующими конкретный Vulkan-драйвер или его версию. В Linux есть простая возможность явно указывать какой драйвер задействовать для той или иной программы в отдельности.

Основные Vulkan-драйверы:

• RADV — Radeon Vulkan Driver — это свободный драйвер, входящий в Mesa, что делает его основным Vulkan-драйвером для подавляющего числа дистрибутивов Linux. Развивается под покровительством компании Valve. Отличается высокой производительностью, реализацией различных оптимизационных техник и продвинутым компилятором шейдеров ACO. В его развитии основной упор сделан на производительности игр, в особенности трансляции вызовов DX в Vulkan.
• AMDVLK — AMD Open Source Driver For Vulkan — официальный свободный драйвер от AMD. Не входит в состав Mesa и поставляется отдельным пакетом. Практически полностью аналогичен их проприетарному Vulkan-драйверу, входящему в состав AMDGPU Pro. Ключевое отличие заключается в использовании разных шейдерных компиляторов: свободный использует LLVM, закрытый — собственный. В виду официального статуса, ряд профессиональных программ и ранних портов игр (в основном от Feral Interactive) ориентировались только на AMDVLK, тем самым выдавая несколько более высокую производительность, чем на RADV. Причём существуют единичные программы, работающие исключительно с AMDVLK.
• Lavapipe — предназначен для программной отрисовки 2D и 3D графики силами центрального процессора, что позволяет работать с графикой без наличия отдельного видеочипа. Был создан в качестве замены менее производительного LLVMpipe, базирующегося на OpenGL, который, в свою очередь, постепенно выходит из оборота и заменяется Vulkan.

Для Debian и Ubuntu, включая деривативы, RADV и Lavapipe входят в пакет mesa-vulkan-drivers. Пакет AMDVLK можно брать из официального репозитория: https://github.com/GPUOpen-Drivers/AMDVLK/releases

Выбор драйвера определяется специальным json-скриптом. Для RADV и Lavapipe скрипты располагаются в /usr/share/vulkan/icd.d/, а для AMDVLK — в /etc/vulkan/icd.d/. Тем самым для использования того или иного драйвера должен быть задействован определённый скрипт:

• radeon_icd — включает использование RADV.
• amd_icd64 — AMDVLK.
• lvp_icd — Lavapipe.

Пример содержимого:

{
"ICD": {
"api_version": "1.2.182",
"library_path": "/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so"
},
"file_format_version": "1.0.0"
}

Суффикс i686 означает, что драйвер для 32-битных программ, а x86_64 — 64-битных.

Библиотеки находятся здесь: /usr/lib/x86_64-linux-gnu/

• libvulkan_radeon.so
• amdvlk64.so
• libvulkan_lvp.so

Применение.

Выбор драйвера определяется переменной VK_ICD_FILENAMES. Чтобы задействовать желаемый драйвер, необходимо передать ей путь до соответствующего скрипта.

Пример запуска Unreal Engine 4 с драйвером AMDVLK:

env VK_ICD_FILENAMES=/etc/vulkan/icd.d/amd_icd64.json '/home/$USER/UnrealEngine/Engine/Binaries/Linux/UE4Editor'

Подобным образом можно запускать любую программу с желаемым драйвером.

В виду того, что для переменной есть возможность указать собственный скрипт, можно использовать Vulkan-библиотеки различных версий, что очень полезно для того же тестирования.

Бонус.

При использовании Mesa 21.x игра War Thunder (на момент 2021 года) не могла запуститься. Проблема оказалась в том, что по какой-то причине она предпочитала задействовать драйвер Lavapipe, который предназначен для программной отрисовки средствами процессора, вместо штатного RADV, что приводило к ошибке:

WARNING: lavapipe is not a conformant vulkan implementation, testing use only.

Чтобы это решить, необходимо вручную включить использование драйвера RADV. Пример:

env VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json /home/$USER/WarThunder/linux64/aces

Таким образом игра успешно запустится.

Yes, it’s possible if the Vulkan implementation and the OpenGL implementation both have the appropriate extensions available.

Here is a screenshot from an example app in the Vulkan Samples repository which uses OpenGL to render a simple shadertoy to a texture, and then uses that texture in a Vulkan rendered window.

Although your question seems to suggest you want to do the reverse (render to something using Vulkan and then display the results using OpenGL), the same concepts apply…. populate a texture in one API, use synchronization to ensure the GPU work is complete, and then use the texture in the other API. You can also do the same thing with buffers, so for instance you could use Vulkan for compute operations and then use the results in an OpenGL render.

Requirements

Doing this requires that both the OpenGL and Vulkan implementations support the required extensions, however, according to this site, these extensions are widely supported across OS versions and GPU vendors, as long as you’re working with a recent (> 1.0.51) version of Vulkan.

You need the the External Objects extension for OpenGL and the External Memory/Fence/Sempahore extensions for Vulkan.

The Vulkan side of the extensions allow you to allocate memory, create semaphores or fences while marking the resulting objects as exportable. The corresponding GL extensions allow you to take the objects and manipulate them with new GL commands which allow you to wait on fences, signal and wait on semaphores, or use Vulkan allocated memory to back an OpenGL texture. By using such a texture in an OpenGL framebuffer, you can pretty much render whatever you want to it, and then use the rendered results in Vulkan.

Export / Import example code

For example, on the Vulkan side, when you’re allocating memory for an image you can do this…

vk::Image image;
... // create the image as normal
vk::MemoryRequirements memReqs = device.getImageMemoryRequirements(image);
vk::MemoryAllocateInfo memAllocInfo;
vk::ExportMemoryAllocateInfo exportAllocInfo{
  vk::ExternalMemoryHandleTypeFlagBits::eOpaqueWin32 
};
memAllocInfo.pNext = &exportAllocInfo;
memAllocInfo.allocationSize = memReqs.size;
memAllocInfo.memoryTypeIndex = context.getMemoryType(
  memReqs.memoryTypeBits, vk::MemoryPropertyFlagBits::eDeviceLocal);
vk::DeviceMemory memory;
memory = device.allocateMemory(memAllocInfo);
device.bindImageMemory(image, memory, 0);
HANDLE sharedMemoryHandle = device.getMemoryWin32HandleKHR({ 
  texture.memory, vk::ExternalMemoryHandleTypeFlagBits::eOpaqueWin32 
});

This is using the C++ interface and is using the Win32 variation of the extensions. For Posix platforms there are alternative methods for getting file descriptors instead of WIN32 handles.

The sharedMemoryHandle is the value that you’ll need to pass to OpenGL, along with the actual allocation size. On the GL side you can then do this…

// These values should be populated by the vulkan code
HANDLE sharedMemoryHandle;
GLuint64 sharedMemorySize;

// Create a 'memory object' in OpenGL, and associate it with the memory 
// allocated in vulkan
GLuint mem;
glCreateMemoryObjectsEXT(1, mem);
glImportMemoryWin32HandleEXT(mem, sharedMemorySize,
  GL_HANDLE_TYPE_OPAQUE_WIN32_EXT, sharedMemoryHandle);

// Having created the memory object we can now create a texture and use
// the memory object for backing it
glCreateTextures(GL_TEXTURE_2D, 1, &color);
// The internalFormat here should correspond to the format of 
// the Vulkan image.  Similarly, the w & h values should correspond to 
// the extent of the Vulkan image
glTextureStorageMem2DEXT(color, 1, GL_RGBA8, w, h, mem, 0 );

Synchronization

The trickiest bit here is synchronization. The Vulkan specification requires images to be in certain states (layouts) before corresponding operations can be performed on them. So in order to do this properly (based on my understanding), you would need to…

• In Vulkan, create a command buffer that transitions the image to ColorAttachmentOptimal layout
• Submit the command buffer so that it signals a semaphore that has similarly been exported to OpenGL
• In OpenGL, use the glWaitSemaphoreEXT function to cause the GL driver to wait for the transition to complete.
  • Note that this is a GPU side wait, so the function will not block at all. It’s similar to glWaitSync (as opposed to glClientWaitSync)in this regard.
• Execute your GL commands that render to the framebuffer
• Signal a different exported Semaphore on the GL side with the glSignalSemaphoreEXT function
• In Vulkan, execute another image layout transition from ColorAttachmentOptimal to ShaderReadOnlyOptimal
• Submit the transition command buffer with the wait semaphore set to the one you just signaled from the GL side.

That’s would be an optimal path. Alternatively, the quick and dirty method would be to do the vulkan transition, and then execute queue and device waitIdle commands to ensure the work is done, execute the GL commands, followed by glFlush & glFinish commands to ensure the GPU is done with that work, and then resume your Vulkan commands. This is more of a brute force approach and will likely produce poorer performance than doing the proper synchronization.