Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Mar 2013
Offline Last Active Yesterday, 06:26 PM

Posts I've Made

In Topic: git add . vs git add -A , didnt do the same thing

19 September 2016 - 07:27 PM

The default behavior for 'git add .' changed with Git 2.0.  It's now the equivalent of 'git add .; git add -u'.


Here's the release notes:  https://github.com/git/git/blob/f99a38c0121456822f8a9dfb7928eefceaa98201/Documentation/RelNotes/2.0.0.txt#L32-L36

In Topic: Pixel Shader 'stage Did Not Run'

24 July 2016 - 09:31 AM

Is there a depth buffer bound?  And if so, is depth testing enabled?  First glance looks like it's getting rejected. If you look in the event history (usually on the side of the graphics debugger) you may see a little symbol that looks like a crossed out 'Z' (if I'm remembering correctly).

In Topic: Magic Number 8 Used For Energy Conservation, One Reason ?

13 July 2016 - 06:34 PM

It's an approximation of the Blinn-Phong normalization factor for the specular distribution function.


See Fabien Giesen's article here for the correct factor:  http://www.farbrausch.de/~fg/stuff/phong.pdf

In Topic: Resource barrier pre and post states

26 April 2016 - 03:55 PM

Subresources can be in different states, but the rules still apply when setting resource barriers in that the before and after states must be correct.  So for example, you could set mip level 0 to a shader resource and mip level 1 as a render target.  See the documentation for D3D12_RESOURCE_TRANSITION_BARRIER, specifically the Subresource member.

In Topic: [D3D12] About CommandList, CommandQueue and CommandAllocator

20 April 2016 - 06:24 PM

You can definitely re-use command lists, as well as command allocators, albeit at different paces.


You can think of a command list as providing the interface to write instructions to the command allocator.  The command allocator is basically just a chunk of memory that lives somewhere.  It doesn't really matter exactly where - that's for the driver implementer to decide.  When you submit a command list to the command queue, you're basically saying "this is the next chunk of work for the GPU to complete and here's the chunk of memory that contains all the instructions".  Even if the GPU immediately takes that work on (it probably won't), you still need that chunk of memory containing the instructions to be available the entire time they're being processed and executed.


So for command lists, you can reset them as soon as you have submitted them to the command queue and immediately begin to reuse them, because all you're really resetting is the command allocator they're using.  However, you must not reset the command allocator that's just been submitted until you are completely sure that all GPU work has completed.  Once you're sure the GPU has finished working on the tasks submitted to it, then you're free to cycle back and reset/reuse that allocator.


I'd recommend searching this site for ID3D12Fence.  I'm sure I've seen a few posts over the past few months that have touched on this topic and show how to synchronize command list and allocator usage across multiple frames.  To get you started, though, you'll need to think in terms of having enough allocators to cover however many frames of latency you'll be working with.