nvidia catching up with ogre 2.0( new azdo extention )

[frostbyte]

https://github.com/nvpro-samples/gl_com ... /README.md
nice..just hope nvidia would not sue anybody here...

[dark_sylinc]

Not sure what's the topic of this thread.

But I can make a few comments:

I applaud Nvidia's effort to enable an interface for managing a GPU-based command buffer. Something we've been asking for a while.

However as is, Nvidia's extension:

• Is overly complicated. I prefer D3D12's bundles. Lots of functionality needs to be done via their specific functions that have been added via this extension that already have non-extension counterpart.
• Their extension mixes functionality aiming towards GPU command buffers (good) with functionality aiming towards workarounding lack of indexing constant in the GLSL shader (bad), to make old-style of programming shaders fast (set per-draw-constants right before issuing the draw command).
• It's all bindless. Which means maintaining compatibility with D3D11 would be a nightmare. For example 2.0 Final is using texture arrays. Bindless textures would be great, but D3D11 and GLES3 don't support bindless textures (nor does D3D10 hardware).
• NVIDIA has the habit of making extensions that expose and manage naked GPU pointers directly to the CPU in the name of performance. Khronos and AMD dislike this approach in the name of security and stability. There are arguments and counter arguments in favour of both. Personally I'm on Khronos side this time. Regardless, the point is, while Khronos maintains this stance and until devs don't actively request or adopt naked GPU pointers, I highly doubt such extension will make it to anything other than being NVIDIA-specific. However, we might see a multi-vendor extension that works in a slightly different way to avoid exposing naked pointers.
• For all of the reasons above, this extension basically should be named "NV_Entirely_Different_API".

Point 2 is actually very important. A quick look at their sample suggests they're comparing the worst case scenario glDrawElements vs their bindless method. Of course it's gonna make a huge margin.

By contrast, they should compare against building an UBO from ground, firing up MultiDrawIndirect, and address the per-draw data in the GLSL shader.
Their extension provides a way to avoid modifying the GLSL shader.

I'm a bit pissed because they took something great (GPU-side command buffers), and intrinstically mixed it with a feature that is blatantly aiming at making old titles (that require drastic changes to their GLSL shaders and buffer management; like the ones we've been doing for 2.0 Final) faster at the expense of changing the API calls for their NV-extension counterpart.
This isn't the future, this is just a workaround for old tech.

[frostbyte]

Not sure what's the topic of this thread.

GPU-based command buffer. Something we've been asking for a while.

thats what i meant with the topic...but yes, maybe it belong to the off-topic forum...

this extension basically should be named "NV_Entirely_Different_API".

ahha, i got exactly the same feeling....trying to divert from gl next in favour of their customers...
same like with cuda and opencl... wouldn't be supprised if they start paying folks to use it...
this is one crazy commercial driven market where every body lose...glad i got off this wagon...

making old titles (that require drastic changes to their GLSL shaders and buffer management; like the ones we've been doing for 2.0 Final) faster

it does feel a bit hackish...( lets just jit the whole stuff... and every body happy... )

This isn't the future, this is just a workaround for old tech.

patching old wounds and stuff...sure hope its not the future..what happend with crystal based computers?
regardless, gl-next is miles away, azdo is lots of work( and still is patching of old wounds ), so i guess this is the crack that this nv extension is supposed to fill...

thanks for all, appriciate your work and knowlege sharing...cheers...