WIP: Vulkan rendering backend #9118
Conversation
cla-bot
bot
added
the
cla-signed
someone13574
force-pushed
the
vulkan-render
branch
from
bfbf78b
to
c29295d
Compare
|
Is there a specific problem you're having with the existing Blade renderer? All else being equal, we'd prefer to support as few renderers as possible :) |
|
@mikayla-maki blade requires |
|
It also requires |
|
"VK_KHR_dynamic_rendering" is not a Vulkan 1.3 extension. It's an extension that was promoted to 1.3 core. You don't have to have Vulkan-1.3 support. Moreover, this is not even a GPU capability per se, it's just driver-level functionality. As far I understand, it was designed with an idea in mind that all of the IHVs will update their drivers to support this (regardless of hardware). The only reason it's not supported on a machine is if it has an old driver. "VK_KHR_timeline_semaphore" is similarly supported at the driver level - it's not a hard ware functionality. You can see all sorts of hardware in the vulkandb. Just a matter of a driver update to get it. |
@kvark neither the old (better driver because of less critical bugs) or the latest driver have |
|
NVidia Tegra X1 looks like a very niche device. VulkanDB lists only 13 reports, of which 7 are on Android, 5 are on Ubuntu-18 (!!!), and one on Fedora-37. So it's not a technical limitation that NVidia didn't update the driver for them, it's probably just not in their interests to support. |
It isn't. All of Nvidia's Jetson product (pre-Orin, so TX1, TX2, and Xavier) are subject to the same limitations. Hundreds of millions (likely billions) of such devices have sold. They run Nvidia Jetpack and are geared towards the development of embedded systems, particularly compute/AI/robotics. Having a Vulkan backend that supports for these most popular embedded systems would be beneficial. If that can be done by improving blade to not require these extensions that would be suitable. |
the Vulkan Hardware Capability Viewer (what collects and uploads to VulkanDB) isn't offered prebuilt for ARM64 Linux. Developers clearly aren't wasting time for something that isn't benefiting them. The lack of reports isn't at all indicative of Jetson products reach. |
|
@theofficialgman Whats wrong with just using OpenGL though? I don't see why the Vulkan backend would need to be complicated when support can easily be done via OpenGL. We really just need a fallback to OpenGL built into blade. |
nothing besides additional overhead...
...once this gets added that is. right now it requires building from source in order to enable the GLES backend. |
Status: Very early stage WIP, just working through the Vulkan boilerplate, but I have next week off so it should progress fairly quick. Currently there isn't much in the way of a structure, with everything just being thrown into a single function, but I will separate parts out once its up and running and a good structure becomes apparent.
This is a PR to add a Vulkan renderer to GPUI using ash, which are Vulkan bindings for Rust. This would be more similar to the Metal renderer in that it is directly using the unsafe bindings for the underlying library which allows more control over the tech stack.
Release Notes: