LLGL and Bindless Resources

[gdianaty]

Hello 👋

Recently, in my toy renderer that uses LLGL I was attempting to get up and running with bindless resources. As of Shader Model 6.6, HLSL is able to access dynamic resources (seen here). There are also some really interesting conversations happening around bringing equivalent intrinsics for DXC's Vulkan support.

I do know that LLGL treats OpenGL as the minspec, and as I understand it something like it is very possible in OpenGL. Furthermore, Apple's Metal implements bindless rendering using Argument Buffers. Overall this functionality seems like it's nearly universally available across APIs.

The question that stands out in my mind is this: would permitting the above functionality be possible? What (other than the obvious trivial root signature changes) would need to happen within LLGL? Is the described functionality even within the scope of LLGL?

Thank you.

[LukasBanana]

I do know that LLGL treats OpenGL as the minspec

Yeah, I try to keep the GL backend compatible down to GL 2.x just to be able to run a simple test even on my VMs which don't have the best support for HW acceleration.

would permitting the above functionality be possible?

I'm definitely interested in bringing more modern API features to LLGL and not all of them have to be supported across all APIs, since a 100% compatibility across all renderers is simply not feasible, Vulkan and Metal for instance don't support arbitrary sampler border colors while D3D12 only restricts them to static samplers, but those are rarely needed features to begin with.
Anything that is limited to a certain set of renderers should simply have their compatibility set mentioned in the documentation (e.g. as in borderColor) and/or a respective field in the RendererFeatures struct.

What (other than the obvious trivial root signature changes) would need to happen within LLGL?

There is at least one thing I want to fix first before I start adding new features and that is getting rid of ResetResourceSlots. I started with another approach but haven't found the time yet to finish it. It's been on my TODO list for a long time now and it's bothering me that the D3D11 binding validation is giving me a hard time to find an efficient way to keep track of resource bindings to avoid the necessity for this function. No other backend needs this function and I dislike the concept of manually "unbinding" resources in an interface that allows a heap of resources to be bound at once. On top of that, SetResource uses mapped binding indices, i.e. the actual binding slot is defined in the pipeline layout while ResetResourceSlots uses direct binding slots - not a great design, but these things grew over time :)
Other than that, I assume the ResourceHeap and PipelineLayout interfaces are just the right place to support bindless resources.

Is the described functionality even within the scope of LLGL?

Absolutely, and resource binding is probably one of the most important parts of a rendering abstraction layer. Other features like conditional rendering for instance are obsolete at this point but for now I just keep it in to support older hardware as well.

[gdianaty]

It's good to hear that there's interest in adding bindless resource management to LLGL! As I said I tried it but realized I was hacking around a little too much to be comfortable with charging forward, lol. I'm eager to help work out implementation specifics for the APIs, and how they should behave. I'd also like to volunteer but I'm admittedly still learning the newer DirectX APIs (I've been stuck on Source Engine for a long time, and it's D3D9).

I will admit that the lack of bindless resources has turned into somewhat of a blocker in my project. However, we can continue to charge forward in other places and use the existing binding model where needed.

I will note that on DX12, bindless resources are a first-class feature now, as where in Vulkan it's an extension. However, I find DX12's descriptor heap system to be exceedingly complex to use at the frontend. I think there's a lovely API to be had if we follow the overall grammar of LLGL. Admittedly, I know even less about the Vulkan API for bindless resources but I can certainly go find out!

[gdianaty]

Hello again @LukasBanana!

I was wondering if you had a particular timeline for this idea in mind, now that you've seemingly retired ResetResourceSlots. Are you still waiting to homogenize CommandBuffer::SetResource and the binding indices for resource heaps?

Trying to decide if I should implement a workaround for now. There is nothing more permanent than a temporary solution, lol.

[LukasBanana]

I do not call the WriteResourceHeap function during encoding, but rather, before encoding ever starts.

Ok good, that's how it's intended.

I'll look into making a reproducible sample but life has been keeping me busy, unfortunately.

That would be fabulous of course :)

It does sounds like the out of sync issue could be a problem with the scheduling of the descriptor heaps internally. Have you tried using a command buffer with only a single native buffer, i.e. CommandBufferDescriptor::numNativeBuffers=1? If that fixes the issue, it could narrow down what causes the out of sync with sampler descriptors. This should only be a temporarily solution of course, because you wouldn't want to limit your command buffer to a single native command buffer unless it's encoded only once.

[gdianaty]

@LukasBanana

I was able to try setting all my CommandBuffers (both the ones for the viewport that are per-buffer and the bundles used in my codebase) to use numNativeBuffers = 1 and I had no immediate effect.

So no dice there, unfortunately.

[gdianaty]

@LukasBanana

Hello! It's been a good while hasn't it :) lol

I'll be honest, I've overhauled my engine's resource heap system and made one very small (yet seemingly very large) change:

Before I was adding the texture and sampler using an initializer list call to WriteResourceHeap, something like this:

pLLGL->WriteResourceHeap(*pResourceHeap, nResourceHeapIdx, { pTexture, pSampler });

And then in the GPU, I would simply access ResourceDescriptorHeap and SamplerDescriptorHeap with the same value, nResourceHeapIdx.

However, now I perform them as two resource heap writes as a consequence of some internal API changes:

pLLGL->WriteResourceHeap(*pResourceHeap, nResourceHeapIdx, { pTexture });
// and then, later on in another part of the code:
pLLGL->WriteResourceHeap(*pResourceHeap, nResourceHeapIdx, { pSampler });

And it works just fine. Not really sure why this is the case but it is. I know you mentioned wanting to reimagine the API surface for WriteResourceHeap for bindless, especially for d3d12. Frankly, at the moment the current API for interacting with d3d12's distinctly separate descriptor heaps is less than ideal. As of right now, I am maintaining an internal cpu-side map of heap indices to resource pointers. This was ideal for my workflow and I'm happy to share more details if you think it could be valuable. I would love to see this feature merged into the main branch of LLGL, but I'm not sure what your plan would be for supporting this on Vulkan as well. I'm interested to hear your thoughts on that.

Broadly, though, bindless has been working great for our use case for the last several months and continues to be perfectly serviceable. Recently I implemented bindless StructuredBuffer vertex data streams -- super cool!

[LukasBanana]

I faintly remember that work and I haven't synced that branch in a while, I bet there will be quite a few merge conflicts, but I certainly wouldn't want this to go to waste.
I think this worked because the descriptor indices were mapped differently between the Sampler and Non-Sampler internal heaps. If that was depending on the input resource, that would explain why it behaves this way even though you use the same input index. That's not by design, however.
I wouldn't mind giving this another try now that I worked a bit more on and with the D3D12 backend.
Would love to see some of your work and how you use LLGL :)

[gdianaty]

I think this worked because the descriptor indices were mapped differently

Yes I seem to vaguely remember reading the underlying code that's responsible for the behavior and coming up with this workaround. Again it would be awesome to refine the API a little and get it merged into main, but running on a stable but stale branch is not a show stopper by any means.

Would love to see some of your work and how you use LLGL :)

My username on DIscord is gmdianaty and I'd love to show you some of what we're doing with LLGL but I'm not ready to share it with the world at large just yet :)