<p>When a shader accesses a resource (buffer or texture), it needs some information about that resource to be able to do so correctly. On a modern GPU, that information will generally just be some kind of number. It could be something as simple as a GPU virtual memory address (with the particular details of what kind of resource is being used defined by the shading language), or it may be an index into a table of resources.</p>
<p>But all modern GPUs need is a number.</p>
<p>From the CPU side, a resource is defined by some API-defined object. To bind a resource (API-agnosticly) means that you tell the API that the given API object's resource is to used by the shader through some resource binding location.</p>
<p>This process therefore requires the API to take that object and convert it into the number that the shader will receive. The object itself cannot just be that integer because the API needs ancillary information for managing the resource. But when you're <em>rendering</em> with the resource, the integer is all you really need.</p>
<p>So let's say you're rendering a complex scene. You may be rendering 100,000 different objects. That could mean 100,000 different binding operations per-frame. Each bind operation has to dereference an object pointer and fetch a single 64-bit integer from the object behind that pointer. And often, the nature of the API object requires <em>multiple</em> dereferences to get this integer.</p>
<p>This is not a cache-friendly operation, as you're fetching a piece of data from storage that has a bunch of <em>unrelated</em> data near it. So not only is the read likely to be a cache-miss, you're doing a whole memory fetch for <em>just</em> 64-bits of data, that will not be used for anything else before that cache line gets evicted. This represents poor cache coherency.</p>
<p>Across 100,000 objects at 60fps (or greater), that can add up.</p>
<p>A bindless API allows the user to store the integer themselves and marshal it to the shader in whatever way they see fit. Any resource integers for an object's rendering call can be stored near other data that is relevant to the rendering process, thus improving cache coherency.</p>
<p>It should also be noted that a bindless API means that any shader could access any information about any object, so long as it has been given access to the integers that represent those resources. This is rather important when doing something like ray-tracing.</p>
<p>So it's not <em>just</em> about performance.</p>

CC BY-SA 4.0
2021-04-01T14:09:50.977Z
2023-01-30T16:05:41.927Z
2023-01-30T16:05:41.927Z
Nicol Bolas
<p>I was trying to understand what exactly is 'binding'. I found an <a href="https://www.quora.com/What-is-binding-in-graphics" rel="noreferrer">answer on quora</a> on this. From this, binding basically sounds like sending data from to GPU with help from CPU. I got to know more about 'bindless' things as there is something called bindless textures in OpenGL. But how does GPU access the data in this case?</p>
<p><a href="https://www.nvidia.com/en-us/drivers/bindless-graphics/" rel="noreferrer">NVIDIA article</a> on bindless graphics talks about how the driver does not need to</p>
<blockquote>
<p>dereference a vertex buffer or constant buffer on the CPU in order for
the GPU to use it.</p>
</blockquote>
<p>in the case of bindless graphics.</p>
<p>So is this dereferencing thing the major difference? How does this help in hugely speeding up the application?</p>
<p>In a nutshell, what is the difference between graphics using binding and 'bindless' graphics?</p>

<gpu><buffers>
Binding vs bindless
Abhineet Pandey
# Binding vs bindless

(Asked by: username_0 on 2021-04-01)

I was trying to understand what exactly is 'binding'. I found an [answer on quora](https://www.quora.com/What-is-binding-in-graphics) on this. From this, binding basically sounds like sending data from to GPU with help from CPU. I got to know more about 'bindless' things as there is something called bindless textures in OpenGL. But how does GPU access the data in this case?

[NVIDIA article](https://www.nvidia.com/en-us/drivers/bindless-graphics/) on bindless graphics talks about how the driver does not need to

> dereference a vertex buffer or constant buffer on the CPU in order for
> the GPU to use it.

in the case of bindless graphics.

So is this dereferencing thing the major difference? How does this help in hugely speeding up the application?

In a nutshell, what is the difference between graphics using binding and 'bindless' graphics?

**Tags:** gpu, buffers


---

## 1 answers

### Answer by username_1 on 2021-04-01. Score: 7 | Accepted answer

When a shader accesses a resource (buffer or texture), it needs some information about that resource to be able to do so correctly. On a modern GPU, that information will generally just be some kind of number. It could be something as simple as a GPU virtual memory address (with the particular details of what kind of resource is being used defined by the shading language), or it may be an index into a table of resources.

But all modern GPUs need is a number.

From the CPU side, a resource is defined by some API-defined object. To bind a resource (API-agnosticly) means that you tell the API that the given API object's resource is to used by the shader through some resource binding location.

This process therefore requires the API to take that object and convert it into the number that the shader will receive. The object itself cannot just be that integer because the API needs ancillary information for managing the resource. But when you're *rendering* with the resource, the integer is all you really need.

So let's say you're rendering a complex scene. You may be rendering 100,000 different objects. That could mean 100,000 different binding operations per-frame. Each bind operation has to dereference an object pointer and fetch a single 64-bit integer from the object behind that pointer. And often, the nature of the API object requires *multiple* dereferences to get this integer.

This is not a cache-friendly operation, as you're fetching a piece of data from storage that has a bunch of *unrelated* data near it. So not only is the read likely to be a cache-miss, you're doing a whole memory fetch for *just* 64-bits of data, that will not be used for anything else before that cache line gets evicted. This represents poor cache coherency.

Across 100,000 objects at 60fps (or greater), that can add up.

A bindless API allows the user to store the integer themselves and marshal it to the shader in whatever way they see fit. Any resource integers for an object's rendering call can be stored near other data that is relevant to the rendering process, thus improving cache coherency.

It should also be noted that a bindless API means that any shader could access any information about any object, so long as it has been given access to the integers that represent those resources. This is rather important when doing something like ray-tracing.

So it's not *just* about performance.


---

