Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

117 Neutral

About Oetker

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1.   Brian,   Thanks for your reply. On the D3D11 case: after copying the old data to the new buffer, I map with MAP_NO_OVERWRITE, and this works fine... As for D3D12, no idea why the copy operation doesn't generate an error message. I'll just have to look for another approach. I've tried a custom heap but didn't manage to find a combination of flags that worked for me, maybe I'll give it another try. Or maybe I'll keep around the old buffers and draw those instead of copying over the data. In this case, the cost for a buffer that's too small is multiple draw calls for a single frame, after which the new, larger buffer will be used. Only thing I'll have to watch out for is that primitives or triangle strips cannot span multiple buffers.
  2. Unfortunately it's not possible to do so; I don't have control over the application that drives the renderer. The suggestion of using Reserved Resources sounds like it could work, but I'd still like to know what I'm doing wrong. When uploading textures (i.e. copying from an upload to a default heap), is the resource barrier enough, or do you also need a fence to know when the texture is ready for use?
  3. I fill UploadA, when it's full I allocate larger buffer UploadB, then I use CopyBufferRegion to copy UploadA into UploadB. Then any new data gets written into UploadB, and I destroy UploadA once the current frame has been rendered. So in any case my issue isn't UploadA being destroyed too early, though it might be that I'm using (writing other data to the end of, and drawing) UploadB before the data has been copied.   By having the CPU copy the data, do you mean just using memcpy? In D3D11 (accidentally) reading from DYNAMIC buffers was extremely slow, though I guess the solution for that would just be to mark it was CPU readable. I could see that being faster than having the GPU perform the copy depending on if the data is kept in CPU memory and only read by the GPU on drawing, or if it's actually immediately sent over the bus.
  4. I'm porting over my D3D11 dynamic vertex buffer class. That worked basically like std::vector; I'd create a USAGE_DYNAMIC buffer, map it with WRITE_DISCARD, and if the size turned out to be insufficient, I'd unmap it, create a new larger buffer, CopySubResourceRegion() over the old data, and map the new buffer. Of course, other approaches would be to immediately draw the contents of the old buffer and discard it, or to keep the old buffer and don't copy over the data (a more deque-like approach), but this worked for me. For D3D12 I'm creating a vertex buffer on an UPLOAD heap, I map it, and if it's too small, create a new buffer. Now comes the issue. I'm trying to copy over the old data using ID3D12GraphicsCommandList::CopyBufferRegion() function, and it doesn't seem to work properly. Note that the debug runtime doesn't complain about anything, which it will if trying to do a plain CopyResource() with an UPLOAD heap as destination. One issue I can imagine is that the GPU tries to draw from my buffer before the copy is complete. However, I'm unable to insert a resource usage barrier, as for upload heap resources only D3D12_RESOURCE_STATE_GENERIC_READ usage is accepted; if I try to use anything else the debug runtime complains. Any idea what I'm doing wrong? Do I need to use a fence (I'm not too clear on when a barrier is enough and when a fence is required), or copy to a default usage buffer?
  5. Oetker

    Fastest way to draw Quads?

    Another approach is not to bind a vertex buffer, and use an instanced triangle strip. You then draw n instances of four non-existent verts, and use SV_VertexID to position them. However, maybe someone could shed light on if the overhead of using instancing still applies in this case? Otherwise, the approach described in that linked presentation (no vertex buffer, but drawing and indexed triangle list) would still be better, if a bit more complex.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!