Jump to content
  • Advertisement

Funkymunky

Member
  • Content Count

    2491
  • Joined

  • Last visited

Community Reputation

1415 Excellent

About Funkymunky

  • Rank
    Contributor

Personal Information

  • Interests
    Art
    Audio
    Business
    Design
    DevOps
    Education
    Production
    Programming
    QA

Recent Profile Visitors

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

  1. Funkymunky

    DX12 Debug Interface memory leak?

    This is what PIX shows when I do a memory capture: I suppose that trend points to a leak? EDIT: Sorry, that image is with the debug layer enabled. This is what it looks like without it: And it sounds like Adam is saying this is a known leak. So, cool, thanks.
  2. I am running an Nvidia 1080 Ti with the latest drivers, and it seems as though even if I make a barebones application (creates a swapchain and just clears and fences between two frames), I have a perpetual, linear rise in memory usage when I use the DX Debug layer. Without the debug layer, I'm stable for hours at the same amount of memory used. Does anyone else see anything like this?
  3. Awesome, thanks to both of you for the thorough and illuminating replies. So it sounds like the normal rule of thumb applies, don't go nuts over-engineering something to mitigate cache misses, but if you can group some commonly used items together contiguously, then yeah go for it.
  4. Ah, so that brings up a good point with the root constants. Those are copied directly into the root signature when you call SetGraphicsRoot32BitConstants. So then does SetGraphicsRootDescriptorTable copy in the descriptors from the heap, or just tell the shader where to look in the heap for them? If it copies them, I see no reason to be overly-concerned with the locality of the descriptors.
  5. Does anyone know how the GPU's scheduler uses the descriptors? Does it attach them to the warp/wavefront directly, or does it look up the associated resource first? In other words, when a warp/wavefront runs and accesses buffers/textures, is each thread bouncing through the indirection of the descriptor every time, or does it have direct access to the resource at that point? I ask because it seems like lining up contiguous tables in the descriptor heap to reduce cache misses could be useful, but only if that indirection doesn't happen per-thread. Otherwise I'd be more inclined to just scatter the tables throughout the heap in a more space-efficient manner.
  6. I'm reworking my descriptor heap strategy, so I'm digging through everything again. On nVidia's DirectX 12 Do's and Don'ts page, they say: Make sure to use just one CBV/SRV/UAV/descriptor heap as a ring-buffer for all frames if you want to aim at running parallel asynchronous compute and graphics workloads I was under the impression that calling SetDescriptorHeaps could cause a flush. Am I to understand that if all frames use the same descriptor heap, there won't be a flush, and the compute work can continue to access the descriptors despite newer graphics command lists calling SetDescriptorHeaps? Does anyone have any additional information about managing memory to support async Compute?
  7. Funkymunky

    CopyDescriptors between different heaps

    Ah okay. So when I call CreateConstantBufferView and pass it a descriptor, I'm really writing that View into the descriptor heap. Then when I call CopyDescriptors, I'm copying that View into a different heap. Which means I can copy to a different location in that heap. Thanks!
  8. How does CopyDescriptors work when copying from a CPU-only heap to a Shader-Visible one? The D3D12_CPU_DESCRIPTOR_HANDLE structure is just a size_t, but if I use CD3DX12_CPU_DESCRIPTOR_HANDLE to create it then it uses the result of GetCPUDescriptorHandleForHeapStart() to offset those size_t's to be specific to that heap. Is CopyDescriptors from one heap to another going to make all the descriptors be specific to that new heap? Also, calls like CreateConstantBufferView and CreateShaderResourceView take a descriptor as one of their parameters (which points to a specific location in a heap). How is that going to get updated for the new heap location?
  9. I have 3 PSOs that all use the same code for their vertex shader. If I pass the same pointer into each of their D3D12_GRAPHICS_PIPELINE_STATE_DESC::VS fields, does that mean that they'll actually share the vertex shader? Or are they each going to make individual copies of the shader? (And by extension, does doing this eliminate a state change on the GPU?)
  10. Funkymunky

    Memory Leak Detection and DX12

    Ah, but I don't just want to see a listing of DirectX object lifetime problems, I want to see general heap memory leaks as well.
  11. I've gotten used to using Visual Leak Detector on another program and would like to migrate it to my DX12 code. It's nice because after running my code, I can check the console output to see if any memory leaks popped up. I've used both Visual Leak Detector and just the CRT Heap detection stuff. Both work fine in my other programs, but in my DX12 program I get no output on the console (even if I manually introduce a memory leak). Using the CRT model, you can either call _CrtSetDbgFlag to trigger output on exits points, or call _CrtDumpMemoryLeaks before exiting the program. That first option doesn't work, and the second isn't that great because anything that hits a destructor after its called will be incorrectly flagged as a leak. Anyone have any lucky using memory leak detection with DirectX 12? I'd prefer if it printed to the console rather than running as a separate program, and I'd really prefer something free...
  12. Funkymunky

    Vertex Shader to Multiple Pixel Shaders

    Cool. So just to be clear, on a technical level, the options are either stream-output or compute shader transformation to a buffer that I then bind to a pass-through vertex shader?
  13. I'm doing some mesh skinning in my vertex shader, and I have a depth pre-pass in place. I'm not crazy about doing all the vertex transformation twice for the skinning; is there a way to have one vertex shader be the input to multiple pixel shaders? Or do I have to do a vertex shader stream-output, and then set that as the input for the pixel shader somehow?
  14. Funkymunky

    OMSetRenderTargets per Command List?

    I guess that's as clear cut as it gets.  Thanks!
  15. Funkymunky

    OMSetRenderTargets per Command List?

    Is it a necessity per list though?  Wouldn't putting in a fence to ensure the correct setup has been processed be less work for the GPU than calling OMSetRenderTargets, RSSetViewports, and RSSetScissorRects for every list?  To clarify, I'm making those calls per list now, but I'm just wondering if there's a better way to do it...
  • 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!