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]

The short answer is, I do not have a timeline in mind as I don't want to rush out new features that I also haven't wrapped my head around yet.

Having said that, having more options for resource binding in LLGL is definitely a priority for me over other features like ray tracing or mesh shaders. Right now, LLGL only supports a single ResourceHeap per PSO layout, so that would probably have to be refactored as well. But perhaps there's an elegant solution that requires very little modification of the public interface that allows to use the bindless declarations but I have to look more into the new HLSL Dynamic Resources documentation first.

Any proposals of how the interface could look like for bindless resources is appreciated.
Ideally, this would only require a single new flag in the ResourceHeapDescriptor or PipelineLayoutDescriptor.