Why are we still using index/vertex/instance buffers?

As you've pointed out, on any recent hardware/API there's nothing stopping you from doing fully programmable vertex fetch. There's 3 things you should keep in mind though:

1. The performance between programmable and fixed-function vertex fetch may not be the same. There's still GPU's out there that have dedicated hardware for vertex fetch, and using it could possibly be the fastest path depending on what you're doing. On the other hand, some hardware (for instance anything made by AMD in the last 7 years) has no dedicated vertex fetch, and will generate shader code that implements your input layout. But even then there can be differences depending on what types of resources you fetch your data from (structured buffer vs. formatted buffer vs. textures), and your data layout (AoS vs. SoA). For an example, here's what happened when someone benchmarked a bunch of different ways to fetch vertex data on their GTX 970.
2. GPU's will typically tie their post-VS cache to indices from an index buffer, so you'll still need to use a dedicated index buffer to benefit from it. You may want to look through this thread for some ideas on how to do interesting things within the limitations of standard index buffers.
3. Input layouts let you have some decoupling between your vertex buffer layout and your actual vertex shader, which can be convenient in some cases. However it's possible that different input layouts will cause the driver to generate different permutations of your VS (or different VS preludes) behind the scenes.

Thank you! I actually didn't think of using a dedicated index buffer but I see now that it still has value. What I am also interested in is that this way you can easily do hard edge normals and UV discontinuities without duplicated position vertices. I am already using deinterleaved vertex buffers (for more efficient shadow rendering/zprepass) so implementing that should not be very hard.

Oh and something to keep in mind: graphics debuggers (at least Nsight) cannot visualize geometry information without an input layout, that is certainly a downside of it.

BTW since it wasn't explicitly stated what you do is you use a null vertex buffer, this will allow you to generate vertex's procedurally or by fetching them manually using the SV_VertexID and SV_InstanceID system values. It has been documented here:

https://www.slideshare.net/DevCentralAMD/vertex-shader-tricks-bill-bilodeau

or

At the end of the day, vertex buffer and index buffer is just another buffer with semantics attach..as pointed out above I think vertex caching is one of the biggest reason for the having this distinction still as without this, the API will have to be able to flag a generic buffer as being cacheable..

MJP point 2 is the most important, you need an index buffer in order to benefit from post vertex transform cache, besides that you could, if you only target recent hardware, go SoA (not interleave your vertex data) and fetch manually, that's what will happen on any GCN anyway.

As mentionned by MJP also, nVidia hardware works differently, not sure about latest gen, all consoles being GCN we tend to optimise for it...

Ugh, I implemented it in my engine for every scene mesh render pass and it performs significantly worse on my GTX 1070 than using regular vertex buffers. I was rendering shadows on the sponza scene in 2ms for 6 point lights and the custom vertex fetch moves it up to 11 ms which is insane). The Z prepass of 0.2 ms got up to 0.4ms. These passes are using position and sometimes texcoord and instance deinterleaved buffers.

The vertex buffers are float4 buffers which I create as shader resources with DXGI_FORMAT_R32G32B32A32 views. In the shader I declare them as Buffer. The instance buffers are structured buffers holding 4x4 float matrices.

I don't understand what could be going on but it is very fishy, I expected a very minor performance difference.

I haven't implemented this myself, but you could try eliminating the overhead of automatic type conversion that buffers have. i.e. the buffer SRV contains a format field, specifying that the data is in a particular format, and the HLSL code says that it wants it converted to DXGI_FORMAT_R32G32B32A32_FLOAT format -- this ability for general purpose conversion might have an overhead on NV?

To avoid that, you could try using a ByteAddressBuffer, and something like asfloat(buffer.Load4(vertexId*16))., which hard-codes the expectation that the buffer will be in DXGI_FORMAT_R32G32B32A32_FLOAT format.

Alternatively you could try using a StructuredBuffer.

I'd be very interested to know if these three types of buffers have any performance differences... :wink:

Yeah I will check with the other buffer types too and post my findings. And double check my implementation too, maybe I missed something more obvious. And I am using a hardware index buffer by the way.

You should use a ByteAddressBuffer as suggested by MJP.

Thanks guys, I will thoroughly experiment with different methods and GPUs. I will be conducting benchmarks on the Sponza scene with Nvidia GTX 1070, GTX 960, AMD RX 470 and Snapdragon 808 GPUs. All of them will be timed for Input layout rendering method, Custom fetch with typed buffers and custom fetch with raw buffers.

I will post results in this topic when I am finished.

A Quick spoiler: AMD RX470 is performing surprisingly well even with typed buffers custom fetch (screw that it has virtually no difference whatsoever), while GTX 960 suffers greatly with doubled rendering time.

I have done the testing for an AMD and an NVIDIA GPU, the Snapdragon 808 will have to wait as setting up the scene for that will take some more time. I will also post the results for the GTX 1070 later.

Here you go:

I have attached a txt file with easier readability.

This is quite painful for me because I wanted to implement some features which require the custom fetching but seeing that it works so slow on nvidia it seems like wasted effort.

By the way, to quickly implement this, I bound my vertex buffers to texture slot 30 and upper, could it matter in performance?

Side note: It seems that this way the CPU time is also higher because VSSetShaderResources takes a longer time than IASetVertexBuffers. :(

Are you using 1 buffer for all attributes or 1 per attribute ?
If you're not using 1 for all attributes you should probably try that.

I am using 1 buffer per attribute (SoA). I recently switched from AoS layout to SoA layout and a complete rewrite of the scene rendering pipeline to allow more flexible buffer binding and more cache efficiency in depth only passes of which there are a lot more than regular passes. This gained me a substantial performance boost on both AMD and Nvidia, I am not interested in going back.

I meant 1 buffer and all Positions, then all Normals and so on...

So still SoA but in a single buffer, each attribute array appended to the next if you will.

In general, the reason for different types of seemingly similar resources is that at least one major IHV has (potentially legacy) fast-path hardware that differentiates between them. There are a number of buffer types which perform differently on NV GPUs while AMD's GCN GPUs simply don't care. You're seeing hardware design issues leaking through the software abstractions.

Ideally, we would just have buffers read by shaders and nothing else, not even textures. (I mean come on, texture buffers?) GPUs haven't reached that level of generalized functionality yet. MS originally pitched this design when they were sketching out D3D 10 and of course the IHVs explained it wasn't feasible.

I meant 1 buffer and all Positions, then all Normals and so on...

So still SoA but in a single buffer, each attribute array appended to the next if you will.

Why do you think it would be better? I imagine it would be harder to manage, because now you would even had to provide the length of the buffers to know the correct offset in the shaders.

Why do you think it would be better?

On 2017/6/1 at 11:59 PM, turanszkij said:

I am using 1 buffer per attribute (SoA). I recently switched from AoS layout to SoA layout and a complete rewrite of the scene rendering pipeline to allow more flexible buffer binding and more cache efficiency in depth only passes of which there are a lot more than regular passes. This gained me a substantial performance boost on both AMD and Nvidia, I am not interested in going back.

I did some tests on mobile GPU, all tests use AOS style buffer.

Adreno 418, SSBO is slower (50fps) than Vertex Buffer (55fps),

Adreno 512, no performance difference between SSBO and Vertex Buffer, this might because Adreno 512 has a unified memory model.

Mali(T7xx, T8xx, G71), none of those GPU support SSBO in vertex shader(although they support opengl es 3.1).

GL_MAX_TEXTURE_BUFFER_SIZE is about 64KB on Mali, so I can't use texture buffer for vertex pulling either.