NVIDIA Command-List Support In Newest Drivers To Lower GL Overhead

[phoronix]

Phoronix: NVIDIA Command-List Support In Newest Drivers To Lower GL Overhead

While NVIDIA is working towards Vulkan and SPIR-V support, they aren't done optimizing for OpenGL as OpenGL will still be in use for years to come and there's many titles still seeking better performance. With the newest NVIDIA drivers, there's now NV_command_list support for further lowering the OpenGL overhead within the NVIDIA binary blob...

http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Drivers-Command-List

[plonoma]

Very interesting extension.
Can't wait for benchmarks and comparisons.

[log0]

Very interesting extension.
Can't wait for benchmarks and comparisons.

Nah, reads like display lists 2.0, mostly useful for (semi-)static scenarios like CAD and co.

I guess this is what OpenGL will mutate towards after Vulkan is out, a CAD oriented API.

[plonoma]

@log0
Oh my, you don't sound very positive about it?

Big difference it's possible to do physics effects with the compute shader, allowing much more dynamic scenes.
And look at the savings in latency. The lower overhead.

By the way, what do you think about bindless vertex processing?
https://www.opengl.org/registry/spec...ied_memory.txt

[log0]

@log0
Oh my, you don't sound very positive about it?

Big difference it's possible to do physics effects with the compute shader, allowing much more dynamic scenes.
And look at the savings in latency. The lower overhead.

By the way, what do you think about bindless vertex processing?
https://www.opengl.org/registry/spec...ied_memory.txt

The lower overhead is shown for static scenes from what I can see. They pretty much record draw calls and state changes related to them. This is what makes it less useful for dynamic scenes, where you have things like level of detail and frustum culling and objects added and removed from time to time.

[stefandoesinger]

Nah, reads like display lists 2.0

Calling it display lists 2.0 gives it more credit than it deserves. This looks more like a reinvention of IDirect3DExecuteBuffer from the mid-90s.

If you have never heard about it: It's the reason why John Carmack never liked Direct3D: http://rmitz.org/carmack.on.opengl.html (scroll to the bottom for code examples).

[log0]

Calling it display lists 2.0 gives it more credit than it deserves. This looks more like a reinvention of IDirect3DExecuteBuffer from the mid-90s.

If you have never heard about it: It's the reason why John Carmack never liked Direct3D: http://rmitz.org/carmack.on.opengl.html (scroll to the bottom for code examples).

Indeed I haven't.

As I wrote above, my guess is that this is catering to the CAD guys, who can't be bothered to deal with Vulkan and co.

[computerquip]

Its meant to be synonymous to command buffers in modern APIs. Not sure whats with the hate.

[efikkan]

According to the sessions at GDC Vulkan will not include the bindless features pioneered by Nvidia, but might provide it as an optional extension. It's really sad to see the single greatest improvement in graphics programming the past 5 years not being included in Vulkan. Vulkan does some things right, like minimizing state changes and reducing the overhead of some API calls, all of this you can also do in OpenGL by using the right features, but Vulkan does not yet take any step forward in terms for GPU programming. Vulkan is even more reliant on API-calls, which is actually a step backwards. The only step forward is to move functionality from the API calls from the CPU into the shading language which removes the need for most of the API calls. Vulkan is designed to maximize the amount of draw calls, which is suited for low-end (mobile) GPUs, and is partly designed like old console APIs. Removing the need for most API calls will always be superior to just trimming the latency of the API calls. Even though Vulkan reduces the overhead per draw call, the rendering will still be draw call driven. Which means the more objects you want to render, the more overhead you'll get. All current GPUs can easily render meshes of 1 million polygons or more in a single batch, but if you try to render 1000 objects of different meshes and textures(~1000 polygons), you will quickly run in to an API bottleneck. This problem exists for OpenGL, Direct3D, Mantle and Vulkan. In teory a GPU should be able to render these batches at approximately the same performance level, but in reality the performance will suffer terribly. Reducing the API overhead will help a bit, but reducing the need for API calls which bindless graphics can do helps a lot more. Bindless graphics(regardless of OpenGL or Vulkan) is still far from perfect, but it's at least a step in the right direction.

[DebianLinuxero]

All this stuff sounds good, but ...

Which hardware will be supported?

Only 9xx series?

And could we see a Vulkan driver for 2xx series?