UAV/SSBO instead of vertex buffers?
category: code [glöplog]
Let's face it, vertex buffers and buffer binding are a pain in the ass... in GL it's a prosaic 1000 liner and in D3D it's the fucking oh-you-need-a-shader-first to create an input layout bullshit... and I find it rather inflexible.
So before I'm starting to throw away lots of code (that handles the above) - maybe someone has experience with this? The idea is to use UAV/SSBO for vertex data and pull them in via SV_VertexID/gl_VertexID.
Some stories you want to share, before I start coding complete bullshit?
:-D
So before I'm starting to throw away lots of code (that handles the above) - maybe someone has experience with this? The idea is to use UAV/SSBO for vertex data and pull them in via SV_VertexID/gl_VertexID.
Some stories you want to share, before I start coding complete bullshit?
:-D
I used SSBOs for vertex data, worked perfectly.
Do you have encountered any performance penalties?
nope, was all good. didn't do any real measurements or comparison since, well, I couldn't be bothered to write the VBO code... But as I understand it from what I read, on hardware it's the exact same thing that will happen anyway.
I wonder if the same holds for textue buffer objects, or if they go throught the texture sampling hardware as they have to be read using texelFetch... glFast is using texture bufferes only.
i used textures to hold vertex data in one of my dx11 engine experiments and it worked great. Actually I even stored them as R32G32B32F DDS images on disk, so loading meshes just reused the DDS loader. Just bind the texture and do a vertex texture fetch in the vertex shader (via SV_VertexID) - From what I understood this is how AMD GCN architecture fetches vertex data internally anyway.
There's a presentation by Dan Baker of Oxide Games, where he did the same for their Mantle/DX12 engine.
There's a presentation by Dan Baker of Oxide Games, where he did the same for their Mantle/DX12 engine.
the difference between reading from vertex buffers and reading textures/structured buffers in vertex shader is in theory that the vertex buffer data gets read in by the input assembler, where as texture/buffer reads in the shader happen later on during execution of the shader, which makes it subject to branches/causes read stalls and so on.
on older / mobile GPU architectures it was quite a big difference. nowadays on a modern i'm not so sure how much it affects things, or if there's any difference anymore (is the IA just tacked onto the start of the vertex shader?).
we use structured buffer reads in vertex shaders extensively, anyway.
on older / mobile GPU architectures it was quite a big difference. nowadays on a modern i'm not so sure how much it affects things, or if there's any difference anymore (is the IA just tacked onto the start of the vertex shader?).
we use structured buffer reads in vertex shaders extensively, anyway.
Yeah... seems to me that SSBO/UAV vertex pulling is the way to go on modern hardware. And yes, smash is right, some AMD presentation states that the IA is indeed just tacked infront of the vertex shader.
If you pull the data yourself you are skipping the vertex cache. Assuming vertex caches still exist these days, and assuming that you don't have any tessellator going on and hence such a cache mattered something.
iq: As far as I understand this, the vertex cache is in fact properly utilized. You are still using a normal hardware indexbuffer, and the GPU uses the associated vertex index to determine, if the given vertex was already transformed by the vertex shader. If yes, it just pulls the corresponding data from the cache.
I meant the post-transform cache. Does that still exist these days?
I thought that that's how the post-transform cache works?