Hey Guys,

I currently working on a project which need to use GPU to run a bilateral filter over an depth frame, and need to do it as fast as possible. So basically I will read a depth buffer into GPU and run a separable bilateral filer on it (which first filter it horizontally and then vertically)

So here are some decisions I have to made:

1. Should I make the depth frame a Texture2D or Buffer?

I have read some articles which says Texture is good for random access (Morton pattern memory layout), while Buffer is good for linear access. But in my case, during the first pass my PS or CS will read the data kinda linearly since its a horizontal pass, but when I run the vertical pass, in terms of memory access, it's more like a random access style since I will be reading data in a column by column pattern... I am not super sure whether there are other differences between Buffer and Texture, so I need advises and explanation on this.

2. Should I use pixel shader or compute shader?

I have see the constant time CS filtering algorithm, which is amazing. But I also profiled some of my image filtering algorithm between PS CS, and find out PS can run much faster than CS when filter kernel size is small. Also I was told the PS has some special hardware which are not exposed to CS to do Texture related things faster (which make question 1 more interesting). So I think I need to know which kind of task is good for PS or CS.

I know I should profile it myself and use the faster one based on the result. But having more advises before I start is always better :-) Also my project will be targeting on future GPU, so I think those decisions should be made based on the understanding of Texture, Buffer, CS\PS advantages, rather than blindly trying these combinations on current GPU.

Thanks in advance.

Peng

Thanks Jason and Adam for such quick reply. I really appreciated.

"You mention that there are some hardware filtering options available to PS that isn't available to CS, but I can't think of any. What did you have in mind?" --Adams

When the CS get first introduced, I was very interested in the overhead introduced by kicking off the CS, my guess during that time is CS will be faster since it doesn't need those extra setup and launching of vertex shader and rasterization ,etc. so I write a very naive Gaussian filter in CS(without the use of groupshared memory) and PS, the result I got shows PS is a lot faster, which confuses me for a long time... Then later I got intern in Activation working with one of their principle technique director, and I ask him about my confusion. He told me there are decent number of transistors in GPU that is not available for CS, and he named some tasks which use these graphic specific hardware which including texture filtering, and faster write to RT (compressed format) (sorry I didn't ask for more details and forget other tasks he mentioned...). And Dingeberry may know more detail according the reply. It will be so great if someone could talk about those specific hardware and explain their jobs.

"You say that you want "read a depth buffer into [the] GPU". Does that mean this depth buffer wasn't generated by the GPU itself? Where did the data come from originally?" --Adams

The depth map is generated by a depth sensor (Kinect2) so it is from CPU. And this got me another questions:

Should I create the texture/buffer directly from the upload heap or first copy my depth map to upload heap and then copy to a texture/buffer in Default heap? The msdn docs says upload heap is not fast as default heap (I am super curious what make upload heap access is slower than default heap, are there different vdram zones for them? or cache settings cause the perf difference?). In my project, the depth map will be generated around every 16ms, and after copying to GPU, there will be only my bilateral filter pass touching this buffer/texture directly (this pass will output the result to a default heap for later process for sure), so I guess I have to profile this to see whether the overhead of the extra copy from upload heap to default heap worth it...

"Based on what I've seen titles do you may still want to be able to do some bilinear reads when reading the input (you lose that if you go for a Buffer<> approach). " --Adams

Yes, I have seen some one use one linear sample to extract enough information he need for that pixel location along with its neighbor pixels within that quad. I guess that is a little faster trick I hope to have.

Thanks guys for sharing your knowledge, I will let you know what I have found.

Peng

Check out http://international.download.nvidia.com/geforce-com/international/pdfs/GeForce_GTX_980_Whitepaper_FINAL.PDF

On page 10:

To reduce DRAM bandwidth demands, NVIDIA GPUs make use of lossless compression techniques as data is written out to memory

AMD does something similar (I think it's basically the same thing). Compute shaders don't use rops so they aren't going to get any benefits from them. A compute shader is pretty generalized so the data it outputs isn't necessarily going to be correlated, or even coherent.

Is that offering a competitive advantage over texture sampling using a texture cache though?

How do you undo the morton pattern? Would you create it with something like D3D12_TEXTURE_LAYOUT_STANDARD_SWIZZLE? That seems not not be the intended usage of the flag but it also implies that an undefined swizzle will be, well, undefined.

If the hardware is automatically translating texture indices for you, could you maybe alias the texture memory as a buffer, write a known pattern, and then undo the pattern?