Bindless Vulkan is in some ways simpler than binding for each draw. But there are now more synchronization conditions.

That big table of descriptors is an unusual data object. It's normally mapped as writable from the CPU and readable from the GPU. The CPU side has to track which slots are in use. When the CPU is done with a texture slot, the GPU might not be done yet, so all deletes have to deferred until the end of the frame. This isn't inherently difficult but has to be designed in.

The usual curse of inefficient Vulkan is maxing out the main CPU thread long before the GPU is fully utilized. This is fixable. There can be multiple draw threads. Assets can be loaded into the GPU while drawing is in progress, using transfer queues and DMA. Except that for integrated memory GPUs, you don't have to copy from CPU to GPU at all. If you do all this, GPU utilization should reach 100% before CPU utilization does.

Except most of this stuff doesn't work on mobile or WebGPU yet. Portable code has way too many cases. Look at WGPU.

What you get by using Unity or Unreal Engine is that a big team already worked through all this overhead. Most of the open source renderers aren't there yet. Or weren't as of a year ago.

▲

loup-vaillant 17 hours ago | parent [-]

> What you get by using Unity or Unreal Engine is that a big team already worked through all this overhead.

Obviously, given the low-level subject matter, this post wasn't aimed at turnkey engine users. In fact, people interested in this stuff are probably actively trying to be independent of those engines.

I will add that we probably need more people able to implement rendering engines. Having to chose between two corporate giants and suboptimal engines isn't ideal, neither for developers nor for players.

▲

Animats 16 hours ago | parent | next [-]

In the Rust graphics community, we have My First Renderer about four times, and no good renderers. It's about a year of work to get to where you can load the standard glTF examples and render them. Those are all small static scenes. Then you hit the scaling, performance, and dynamic update issues, where it gets hard.

The effort level for a good renderer in Rust is not yet known, but it's above two developer years. I'd guess three to five. Currently, there are three failed efforts and one in progress with some EU funding.

For multi-platform (desktop, laptop, browser, phone) add another year or two. All those use Vulkan, but with slightly different subsets and constraints.

I'm a user of renderers, not a developer of one.

	▲	ahefner 3 hours ago \| parent [-]
		It's there in the name - "Rust graphics community" as opposed to simply "the graphics community". Language fetishization above the end goal - or, rather, the language fetish is the real goal.

▲

bitwize 14 hours ago | parent | prev [-]

But it's Yet Another Reason, if you are looking to develop a game, to shitcan your dreams of writing it from scratch Jonathan Blow-style and just use one of the established engines.