VAO and Bindless

[Aleksandar]

What is the proper way to setup VAO in order to use Bindless?

I didn't expect that introduction of mandatory VAO in NV R280+ drivers would create such a headache. A naive approach: "create, bind and forget" simply doesn't work. The application crushes at first glDrawElements() call with NULL pointer assignment. There are no GL errors or anything else that debug_output can catch. The same code with standard VBO access works perfectly with bounded VAO. Without binding VAO, Bindless works fine (furthermore it is a code that has been working correctly for years).

[Alfonse Reinheart]

A naive approach: "create, bind and forget" simply doesn't work.

That sounds like a driver bug to me.

[kRogue]

(Shudders). If memory serves correctly, bindless performance gits hurt a touch with VAO (I have memory of reading that somewhere in these forums). But on the other hand, since you are using bindless anyways, that means you must be using NVIDIA hardware, NVIDIA who have gone on record stating that core profile is slower than compatibility profile. Why not just make a compatibility profile GL context and call it a day? [On a side note, for my own code, apparently I accidentally avoided the issue by only creating and binding a VAO at startup if bindless was not present. I wonder if under core profile a future(or current!)driver revision will make that break?]

[Aleksandar]

That sounds like a driver bug to me.

Yes, it sounds like a bug, but I cannot claim anything.
The problem is in the fact that the presented behavior is exposed on older (pre-R280) drivers. Even if it is a driver bug, adding support for R280+ means breaking up support for older releases. Till now I was quite happy since there was no need to use VAO on NV, and I haven't tried to combine VAO and Bindless.

I hope that there is something that I have overlooked, and VAO and Bindless can coexist after all. That's why I've asked if anyone has succeeded to use them together.

If memory serves correctly, bindless performance gits hurt a touch with VAO (I have memory of reading that somewhere in these forums).

Yes, the memory serves you well. The bindless offers much superior access to resident buffers than any other methods. Using VAO can hurt performance. But the problem is that now I have no choice, at least for the core profile.

But on the other hand, since you are using bindless anyways, that means you must be using NVIDIA hardware, NVIDIA who have gone on record stating that core profile is slower than compatibility profile.

That is what Mark said, and there is no reason not to believe him.
It would be interesting to hear from the community what the real-life experiences are. I've just tried the same scene with both core and compatibility profile on R266 drivers and Vista 32-bit, and depending on the scene setup; results vary from 0.07% to 3.7% in favor of the core profile.

Why not just make a compatibility profile GL context and call it a day?

I'll try it for R285. Well, I have believed the core profile was the right path to follow all these years.

[Alfonse Reinheart]

Yes, it sounds like a bug, but I cannot claim anything.

OK, allow me to rephrase: it is a driver bug.

The set of state stored by a VAO is defined by a reference to certain state tables. Bindless is also defined by expanding this state table. Therefore, the new state that Bindless defines is automatically encapsulated by VAOs.

You should be able to just bind a VAO and continue working as normal. If you can't, then that is a driver bug.

[Aleksandar]

OK, you have convinced me.
I'll try to make a repro-case sample and send it to NV.

[kRogue]

I've just tried the same scene with both core and compatibility profile on R266 drivers and Vista 32-bit, and depending on the scene setup; results vary from 0.07% to 3.7% in favor of the core profile.

Admittedly the numbers are not that big, but that real world results goes against what has been stated! Are the code paths of the code identical? [I would assume so, but, you never know!]

[Aleksandar]

Admittedly the numbers are not that big, but that real world results goes against what has been stated!

My naive tests should not be the reference for stating anything. What Mark said is quite reasonable, but several years have pasted since that presentation and who knows what exactly is happening inside the drivers. Probably there are additional checks for core profile, but also maybe core profile excludes something else. That's why it would be interesting to gather as much real-life experiences from the other people to create a snapshot of the current situation in the drivers development and performance.

[Ludde]

After reading that statement from Mark(or from this forum) I also tested with my scene last month and got something around 0.5%-1% in favor of core(v4.1) if I remember correctly.

[Aleksandar]

Thanks Ludde!

Please post manufacturer and driver version, because there are differences between AMD and NV, as well as among different versions of drivers.