Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

  • Days Won


SoldierOfLight last won the day on August 2

SoldierOfLight had the most liked content!

Community Reputation

2368 Excellent

1 Follower

About SoldierOfLight

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

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

  1. SoldierOfLight

    Management of CommandQueue/CommandAllocator/CommandList

    Yes, command queues are thread-safe.
  2. If you want to asynchronously copy contents into your texture, you can do the CopyTextureRegion on a copy queue, and create your font texture with D3D12_RESOURCE_FLAG_ALLOW_SIMULTANEOUS_ACCESS. Theoretically, you could also use WriteToSubresource to populate your resource directly from the CPU, but you'd have to use CUSTOM heap properties to place your texture in system memory, which would probably have very poor performance on discrete GPUs (though probably great on integrated). You'd still need SIMULTANEOUS_ACCESS for this pattern. Alternatively, yes you can use barriers to properly synchronize access and insert your copy in the middle of other rendering work. Rather than trying to speculate which one would be faster, I suggest you try one, profile it, and if you don't like the results, try the other and profile that.
  3. SoldierOfLight

    Drawcall isn't working out

    See https://github.com/baldurk/renderdoc/commit/4f872b8c8dea365fd92e4483e6f5ad9214bb6ca8.
  4. You might want to try taking a time travel debugging capture of your app. Using that, you can find exactly where your data is getting corrupted. If you do take one, and want to send the trace to me, I can also help you debug it.
  5. Are you sure you're not doing something on another thread somewhere while you're calling this function?
  6. SoldierOfLight

    Use Texture2DArray in D3D12

    While you can do this, I'd not recommend it in general practice. This can be a great optimization for UMA (unified memory architecture, i.e. integrated) GPUs, but for discrete GPUs, this requires putting your resource in L0 memory, i.e. RAM and not VRAM, which will probably have catastrophic results on performance. As zhangdoa mentioned, the general-purpose approach is to create your resources with HEAP_TYPE_DEFAULT and use HEAP_TYPE_UPLOAD buffers to get data into them. This is much better for discrete architectures, without really harming integrated.
  7. SoldierOfLight

    Resize window in D3D12

    WaitForPreviousFrame isn't sufficient, and also isn't a good implementation of what it says it does. It says it waits for the previous frame, but in reality, it waits for the work that was last executed against the current back buffer. Before you can resize the swapchain, you need to wait for the work that was executed against *all* back buffers, not just the current one.
  8. SoldierOfLight

    Resize window in D3D12

    You have to wait for your GPU to idle before you can resize.
  9. SoldierOfLight

    Synchronization in DX12

    Yes, you can signal the same fence multiple times on the same queue, or multiple fences back-to-back, there's no issues there. Can you be more specific about how you're using the various APIs? Some pseudocode for what each thread is doing, including how many queues/fences/events you have, and where fence values are incremented and stored would be helpful.
  10. SoldierOfLight

    Synchronization in DX12

    Which APIs are you using for interacting with the fences? Using APIs on the fence itself does CPU timeline signals/waits, where queue waits are GPU timeline. That's the only trivial thing that comes to mind.
  11. No. Since D3D12 uses FLIP model swapchains, the API requirements of those include a ResizeBuffers after a fullscreen transition before you can Present again.
  12. Try DX11? ID3D11DeviceContext::UpdateSubresource should be a pretty easy way of doing it.
  13. SoldierOfLight

    DEVICE_REMOVED on long renders

    There's also the D3D11_CREATE_DEVICE_DISABLE_GPU_TIMEOUT flag.
  14. SoldierOfLight

    DX11 Render Target Picking

    The CPU can queue up three frames. If your GPU work is super fast, and you're fullscreen or using windowed flip model, and you requested VSync, then the GPU will only render two frames, and then stop and wait for the screen/compositor to be done with one of your buffers before continuing. If you're using windowed blt model, or not using VSync, then the number of buffers you have doesn't matter, because the GPU never needs to wait for anything before overwriting them. If your GPU work is slow, then the GPU doesn't need to wait because it was busy working while the buffers were being used.
  15. SoldierOfLight

    DX11 Render Target Picking

    Back buffer count isn't the right value here, you're looking for maximum frame latency, which is the number of frames that can be queued to the GPU before the CPU starts waiting. This defaults to 3.
  • 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!