pouët.net

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
added on the 2016-05-27 12:58:44 by EvilOne EvilOne
I used SSBOs for vertex data, worked perfectly.
added on the 2016-05-27 13:09:24 by cupe cupe
Do you have encountered any performance penalties?
added on the 2016-05-27 13:13:15 by EvilOne EvilOne
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.
added on the 2016-05-27 13:38:23 by cupe cupe
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.
added on the 2016-05-27 13:58:19 by EvilOne EvilOne
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.
added on the 2016-05-27 20:21:55 by arm1n arm1n
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.
added on the 2016-05-28 00:15:44 by smash smash
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.
added on the 2016-05-30 13:02:10 by EvilOne EvilOne
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.
added on the 2017-02-21 05:38:42 by iq iq
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.
added on the 2017-02-21 09:08:03 by arm1n arm1n
I meant the post-transform cache. Does that still exist these days?
added on the 2017-02-21 09:46:51 by iq iq
I thought that that's how the post-transform cache works?
added on the 2017-02-21 11:15:45 by arm1n arm1n

login