Official Bindless Graphics feedback thread

I have some concerns about the driver’s memory management when using MakeBufferResidentNV. My understanding is that this function locks a buffer at its present VRAM location in order to provide a constant GPU address. If that is the case, this would seem to exacerbate the memory fragmentation of VRAM. If some randomly sized buffers are locked at some random positions in memory, the driver won’t be able to defrag the memory and later buffer allocations will eventually fail. How will the GL cope with this?

Regarding structures made of pointers, maybe it would be a good idea to add refcounts to resident GPU addresses. As it stands now, the application has to do this on its own in order to use a resident GPU address in multiple structures. It is really only safe to delete a resident buffer shared across multiple structures via its GPU address when its usage count drops to 0. Otherwise, it generates dangling pointers to deleted memory. Essentially, it seems to me that using GPU addresses shared across structures is an easy way to introduce hard to debug crashes.

By the way, I think its a great idea to ask for developer feedback like this. Now it remains to be seen if anything coming of this thread will actually makes its way in the spec/driver :slight_smile:

We released 185.81 beta drivers today, including for notebook. Please use those drivers if you are going to experiment with bindless graphics.

Barthold

bertgp, the gpu address is virtual. The virtual address can be constant without making the physical address constant.

This looks like a really good set of extensions.

I particularly like that the vertex buffer code should be easily hidden behind an existing application VBO abstraction.

Yeah, this is freaky cool.

Big thanks for the beta drivers!

This is definitely promising. It seems that it would be pretty easy to change my VBO code to do this. I assume the big wins here are a direct connection to GPU address, thus eliminating a bind id lookup, and the notion that you cannot edit, so you can rely on these functions being lightweight. I was wondering why there were no GL extensions to do something like this for textures, as drawing from a texture should take less work than setting up to update a texture on the driver side, no?

With virtual addresses, there can still be problems. Let’s say there are N memory pages and each one has one resident VBO locked in it. In that case, any allocation greater than the size of two memory pages would fail since it would not be possible to provide a continuous range of virtual memory which satisfies it.

Before resident buffers, the GL could shuffle data around as much as it wanted. With this extension, there are more restrictions to what it can do.

Being virtual doesn’t mean completely unconstrained, I agree, but the virtual address space of modern GPUs is in the terabyte range.

Agreed that giving the virtual address does add restrictions that didn’t exist with handles alone, but the handle-to-address cache misses were not an insignificant cost.

This seems like a perfectly reasonable way to go about eliminating that cost.

Yeah you’re right. I had completely forgotten that the addresses are 64 bits. We have some leeway before each page of the 64 bit range is taken!

And by the way, I wasn’t saying that this extension is useless, just pointing out a possible problem and wondering how Nvidia intended to handle the issue.

Is GL3.1 enabled in these?

Nope, but don’t let that deter you :wink:

I’ve been playing around with this extension, but one thing I was somewhat curious about…

In the spec example for “GL_NV_vertex_buffer_unified_memory”, it lists this function:

// get the address of this buffer and make it resident.
GetBufferParameteri64vNV(target,BUFFER_GPU_ADDRESS,&gpuAddrs[i]);

But I cannot find any such function as having been added in any of these extensions, although there is a similar function called GetBufferParameterui64vNV from the “GL_NV_shader_buffer_load” extension.

I have been using this second one since it seems to more or less work… well for a few minutes, and then the driver randomly crashes. I’m creating lots and lots of these buffers, probably at least 20k, perhaps there is a limit or something? For some reason when I use occlusion culling I crash much faster, with OC in use the program lasts about 10 seconds, with it off, more like a minute or so.

Yes, it’s supposed to be GetBufferParameterui64vNV (with a “u”), that’s a typo.

Can you provide a repro app for the crash?

jeffb I sure can, do you need source or just a .exe? What should I send it to? Hopefully it is just something stupid I did…

Fitz, I sent you a private message with more info

I’m probably missing something obvious, but where?

developer.nvidia.com: ver 180.51 (Apr 1) Linux
nvdeveloper.nvidia.com: ver 182.65 (Apr 29) Win

<u>EDIT</u>:
Never mind. Found it:
http://www.nvidia.com/Download/betadrivers.aspx aka
http://www.nvidia.com/Download/Find.aspx?lang=en-us

Just a heads-up: developer.nvidia.com->Drivers->Download Latest Drivers doesn’t get you the latest drivers. Google NVidia beta drivers to get the above links.

Wow. I own the NVIDIA DevZone site and didn’t know about this annoyance. I’m going to change the “Drivers” link on the left side to just go to http://www.nvidia.com/Download/Find.aspx from now on. Hopefully that will help!

Now we’re seeing some real changes :wink:

Anyway, this extension seems really cool. Might be some time until I get the time to start working on it for the GL renderer but I almost can’t wait for the moment :slight_smile:

We now have to push ATI/AMD to implement it also. I actually have real hopes that it will, since this is a major step forward in GPU programmability.

Thanks, David

I don’t hold out much hope; they don’t have as many resources when it comes to developer stuff as NV and certainly not as many much when it comes to driver dev.

The state of their dev. pages alone should be a good clue to this…