• 12
• 12
• 9
• 10
• 13
• ### Similar Content

• By Krypt0n
Finally the ray tracing geekyness starts:
https://blogs.msdn.microsoft.com/directx/2018/03/19/announcing-microsoft-directx-raytracing/

https://www.remedygames.com/experiments-with-directx-raytracing-in-remedys-northlight-engine/
• By lubbe75
What is the best practice when you want to draw a surface (for instance a triangle strip) with a uniform color?
At the moment I send vertices to the shader, where each vertice has both position and color information. Since all vertices for that triangle strip have the same color I thought I could reduce memory use by sending the color separate somehow. A vertex could then be represented by three floats instead of seven (xyz instead of xys + rgba).
Does it make sense? What's the best practice?

• Hey all,
I'm trying to understand implicit state promotion for directx 12 as well as its intended use case. https://msdn.microsoft.com/en-us/library/windows/desktop/dn899226(v=vs.85).aspx#implicit_state_transitions
I'm attempting to utilize copy queues and finding that there's a lot of book-keeping I need to do to first "pre-transition" from my Graphics / Compute Read-Only state (P-SRV | NP-SRV) to Common, Common to Copy Dest, perform the copy on the copy command list, transition back to common, and then find another graphics command list to do the final Common -> (P-SRV | NP-SRV) again.
With state promotion, it would seem that I can 'nix the Common -> Copy Dest, Copy Dest -> Common bits on the copy queue easily enough, but I'm curious whether I could just keep all of my "read-only" buffers and images in the common state and effectively not perform any barriers at all.
This seems to be encouraged by the docs, but I'm not sure I fully understand the implications. Does this sound right?
Thanks.
• By NikiTo
I need to share heap between RTV and Stencil. I need to render to a texture and without copying it(only changing the barriers, etc) to be able to use that texture as stencil. without copying nothing around. But the creating of the placed resource fails. I think it could be because of the D3D12_RESOURCE_DESC has 8_UINT format, but D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL enabled too, and MSDN says Stencil does not support that format. Is the format the problem? And if the format is the problem, what format I have to use?

For the texture of that resource I have the flags like: "D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET | D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL" and it fails, but when I remove the allow-stencil flag, it works.

• I know vertex buffer is just another GPU resource represented by ID3D12Resource, but why is it said that vertex buffer don’t need a descriptor heap??
Other resources like depth/stencil resource, swap chain’s buffer need to have descriptor heaps. How does these resources differ from vertex buffer.

# DX12 [DX12] Constant Buffer Packing

This topic is 773 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey all,

I'm trying to wrap my head around some weird behavior I'm seeing in my compute shader. It looks to be related to packing and the nature of float4 vectors on GPUs, but it's super unintuitive.

Basically, I have a constant buffer (HLSL 5.1).

static const int SampleCount = 128;

struct OffsetData
{
float2 Samples[SampleCount];
};

ConstantBuffer<OffsetData> offsetData : register(b1);


In C++, I have a similar layout:

struct OffsetData
{
static const size_t SampleCount = 128;

void Compute(float angle, float width, float height)
{
const float CoCMultiplier = CoCSizeMax * 0.05f;
float x = 0.5f * CoCMultiplier * cosf(angle) * (height / width);
float y = 0.5f * CoCMultiplier * sinf(angle);

for (size_t i = 0; i < SampleCount; ++i)
{
float t = static_cast<float>(i) / (SampleCount - 1);
samples[i][0] = Lerp(-x, x, t);
samples[i][1] = Lerp(-y, y, t);
}
}

float samples[SampleCount][2];
};


I then have a shader that renders the contents of the constant buffer to the screen. Basically, I map the current uv from [0, 1] -> [0, SampleCount - 1] and then return the contents of the constant buffer as the buffer color.

I get really weird results:

If I change everything to use floats (i.e. OffsetData.Samples is an array of SamplesCount floats), I get this:

[attachment=30560:float1.PNG]

This is indexing the constant buffer from 0 to SamplesCount - 1. It's basically skipping the buffer in increments of 4.

For float2:

[attachment=30561:float2.PNG]

Float3 (this one looks really weird, I don't even understand what happened):

[attachment=30562:float3.PNG]

And finally, the "correct" one where everything uses float4's:

[attachment=30563:float4.PNG]

Naturally, it seems like there's something inherent to vec4's going on. But it doesn't make sense. I should be able to index an array of floats, right? What am I missing?

##### Share on other sites

Alright, I just found out something a little more illuminating.

If I change my constant buffer in HLSL to use a float2 array, but then force my C++ code to use a float4 array (where I only put data into the x and y components), everything works fine. What packing semantics am I missing? This just seems obtuse to me.

-Z

##### Share on other sites

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:

[unroll]
for(uint i = 0; i < SampleCount; ++i)
{
[unroll]
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

Edited by WFP