Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Mar 2013
Offline Last Active Yesterday, 10:01 PM

Posts I've Made

In Topic: [DX12] Constant Buffer Packing

07 February 2016 - 09:31 AM

You seem to have discovered for yourself, and Krzysztof mentioned, how arrays are stored in HLSL constant buffers.  A possible solution to this would be to just halve your sample count and use the full float4 for storage.  Your example would turn into:

static const int SampleCount = 64;

struct OffsetData
    float4 Samples[SampleCount];

Then just index into it for the value you want:

for(uint i = 0; i < SampleCount; ++i)
	for(uint j = 0; j < 4; ++j)

		float currentDataPoint = Samples[i][j];

You can update that loop to extract the float2 value if that's what you're after, the approach is essentially the same.


Edit:  Here's some documentation.  It's for SM4, but I'm almost positive it hasn't changed since https://msdn.microsoft.com/en-us/library/windows/desktop/bb509632(v=vs.85).aspx

In Topic: [D3D12] Command Allocator / Command List usage

23 January 2016 - 07:18 PM

It's OK to reset the command list immediately after submitting it as long as you use a different allocator or wait for a GPU signal that the submitted work has completed.

ID3D12CommandAllocator* pAlloc1, pAlloc2;
ID3D12GraphicsCommandList* pCmdList;

// later on
pCmdList->Reset(pAlloc1, nullptr);
// record some commands
pCommandQueue->ExecuteCommandLists(1, &pCmdList);
pCommandQueue->Signal(pFence, fenceValue);

// now you can reset the command list, but use pAlloc2 since pAlloc1 will still be executing
pCmdList->Reset(pAlloc2, nullptr);

After submitting the command list the second time (after recording into pAlloc2), you need to check the fence value set after the first submission to make sure it has completed before resetting with pAlloc1.  You can use more allocators to avoid the likeliness of actually blocking on a fence very often if at all, but allocators only ever increase in size, so the largest batch of commands submitted to one is how much memory that allocator will consume until it's destroyed (COM destroyed through Release, not Reset).


Command Allocator Reset: It seems as though this is literally destroying the contents of the heap, which may have command list data active on the GPU.


Kind of.  That's exactly why you'd want to ensure the job is done executing before resetting the command allocator, but it's likely more of a pointer reset to the beginning of the allocator's memory than any type of expensive deconstruction.


How does the memory ownership work between the command allocator and command list? Is the allocator doing implicit double (or more?) buffering on a command list reset?


The allocator owns the memory.  The command list is your interface to write into that memory, but it doesn't actually own it.  You've probably deduced from the previous parts of the post that the allocator does no additional buffering (double or otherwise), so again, that's why you want to ensure your work is done (fence) before resetting an allocator.

In Topic: HLSL Bilinear Filtering ?

15 January 2016 - 03:45 PM

Doesn't D3D11_FILTER_MIN_MAG_MIP_LINEAR enable trilinear filtering


Yes, that's correct.  As long as the samples are from non-fractional mip levels, the result is the same as bilinear filtering.  In the use case above, you could also use D3D11_FILTER_MIN_MAG_LINEAR_MIP_POINT for the same result.

In Topic: Questions About Blur Effect

04 January 2016 - 08:52 PM

Adam_42's way to increase the blur is one approach.  Another approach is to simply run the result of the first blur pass through the blur technique again.  In pseudo-code it would look something like this:

int numPasses = 3;
for(int i = 0; i < numPasses; ++i)

If you were using a 7-tap blur in your shader and ran it through that loop 3 times, you would have the same result as running a 21-tap blur.

In Topic: Subsurface Scattering - Transmittance

04 January 2016 - 08:43 PM

Unfortunately I haven't used either of the other approaches, so I won't be able to be too much help there.  If you render the front and back faces, you should be able to calculate the thickness of the geometry and use that as a replacement for the thickness value you'd get from the shadow map.  The difference, though, is that using that value won't account for other occluders in the scene that would otherwise obstruct the light and diminish or cancel the transmittance effect.