I have a maxwell gpu at home so I only have tier 1 resource heaps and can't alias them like that :(. But I think it should work if you created a buffer and texture out of the same heap memory?

I did some testing and if you create a buffer with sequential data, copy it to a texture that was created using CreatePlacedResource, and then call ReadFromSubresource on the texture it returns a really funny pattern:

2, 64, 258, 320, 6, 68, 262, 324 ...

Kind of weird because doing this on a texture created CreateCommittedResource yields sequential data. I don't think this is a useful access pattern that it's giving me back. I'm not really sure what I'm looking at.

It was an unknown layout and copy-dest since it was in a readback heap. I tried putting it into the default heap too but that didn't change anything. So it's just upload buffer -> readback texture, results vary based on whether it's made with CreateCommittedResource/CreatePlacedResource.

Hey Guys,

I got a interesting finding:

For linear buffer reading Compute Shader is around 15% faster than Pixel Shader in my GTX 680m.

To be more specific: My dx12 program created a permanently mapped buffer in Upload heap and will copy image buffer from camera. Then I can use CS or PS to copy(render) this image into a Texture (swizzled buffer in default heap). So the CS/PS is simple and almost the same, just read and write/output, no TGSM (threadgroup shared memory) used in CS.

My expectation is that, since I didn't use TGSM in CS, PS should run a little faster, since I observed this PS speed up long time ago when copy Texture to another Texture buffer (but these texture buffers are all swizzled in default heap). However, the result suggests that for reading unswizzled buffer in Upload heap CS may be faster...

I can't find any reasonable explanations for this. So it will be greatly appreciated if someone could confirm this (it may be possible that I messed up something in PS to get worse result than CS) and explain why CS is faster.

Thanks in advance

Peng

Why aren't you just using a copy function to copy the texture data? Shouldn't that ideally be the fastest way since it doesn't involve pipeline state?

Also, yeah, pixel shaders probably won't be as fast at reading linear data because they render in sets of 2x2 quads, not like 32x1 lines. But your typical texture isn't going to be stored linearly -- even in this case you're really copying from a buffer and storing to a texture, not reading and writing to/from a texture, which is the more common gpu image operation.

https://developer.nvidia.com/sites/default/files/akamai/gameworks/images/lifeofatriangle/fermipipeline_distribution.png

Basically just note that stuff gets shaded in blocks -- if it were a linear distribution of shaders, you'd see it shaded as horizontal line strips.

Why aren't you just using a copy function to copy the texture data? Shouldn't that ideally be the fastest way since it doesn't involve pipeline state?

Also, yeah, pixel shaders probably won't be as fast at reading linear data because they render in sets of 2x2 quads, not like 32x1 lines. But your typical texture isn't going to be stored linearly -- even in this case you're really copying from a buffer and storing to a texture, not reading and writing to/from a texture, which is the more common gpu image operation.

https://developer.nvidia.com/sites/default/files/akamai/gameworks/images/lifeofatriangle/fermipipeline_distribution.png

Aha, I should be honest that I am not just read and output, I convert the data before output to satisfy my data processing requirement. And that's why I never think of using the copy function.

And thanks for your reply, that really help. But another following question is that the output is texture, so write to buffer is not linear, will PS be benefited by that? since PS should be optimized for swizzled and compressed output to rendertarget?

Thanks again

Are you rasterizing the colors using your pixel shader or writing them to a uav texture?