Jump to content

  • Log In with Google      Sign In   
  • Create Account


Paul__

Member Since 17 May 2012
Offline Last Active May 30 2012 09:46 PM
-----

Posts I've Made

In Topic: Append buffer: buffer byte stride vs resource view byte stride

30 May 2012 - 06:50 PM

Ah, thanks, that's how I thought I'd have to access the object.

In Topic: Append buffer: buffer byte stride vs resource view byte stride

30 May 2012 - 06:26 PM

Meaning that then the vertex shader will still report to dx a 32 byte stride? I assumed that the hlsl compiler looked at which struct was used with the StructuredBuffer. Oh well. Perhaps I'll live with the warning, or work out how to use a raw buffer with a counter. Thanks again!

In Topic: Append buffer: buffer byte stride vs resource view byte stride

30 May 2012 - 01:47 AM

Hi MJP, thanks for your reply. Dash it! I was hoping that there was some way around. I tried copying the buffer to another some weeks ago, but that was just too slow (the buffer is very large). I might give the raw buffer + atomic increment thing a go. Or change the vertex buffer to accept a 128 byte struct, and read from within that struct the one vert it needs. Thanks for the advice.

In Topic: Map/unmap, CopyStructureCount and slow down

17 May 2012 - 08:32 PM

Thanks for all your replies -- a great help.

MJP: thanks for clarifying about the app reading gpu resources and the effect it has. I guess this means that programmers avoid reading the gpu in an app if possible, because such an app can't have the cpu working many many frames ahead of the gpu. I suppose it does kind of make the cpu and gpu stuck to each other for every single frame, and means they can't operate independently.

Also, with the driver using buffer renaming, I guess also there's no point in an app multi-buffering its dynamic buffers, because it's already done for it?

About the primitive count and why it's important. In my app, the compute shader generates a variable amount of primitives. Variable, because it's creating water tiles and each chunk of terrain has a variable amount of water tiles. On top of that, the amount of water tiles for each chunk changes throughout the game, based on water physics and other factors. So regardless of whether I use DrawIndirect or Draw, I think I still need to know the amount of water tiles in order to render them, either through reading how many tiles the compute shader made, or by the app keeping track of each chunk's amount of water tiles and updating those counts when the water behaviour changes. Keeping track is difficult, because terrain data is duplicated in video ram, and is updated from the main ram version only when there's a change. But I can and probably will maintain such a tile count, even though it'll be a bit of a pain.

Anyway, thought I'd say why reading the gpu would simplify the code so much. But I'm now persuaded it's probably not a good idea!

In Topic: Map/unmap, CopyStructureCount and slow down

17 May 2012 - 04:27 AM

Okay, thanks Nik02, I think I understand the GPU/CPU relationship a bit better now.

PARTNERS