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!]