Directx 11 constant buffer question

Graphics and GPU Programming Programming

Started by Wilhelm van Huyssteen August 11, 2014 04:23 PM

3 comments, last by Wilhelm van Huyssteen 9 years, 8 months ago

Wilhelm van Huyssteen

1,232

Author

August 11, 2014 04:23 PM

Hi.

I had the following constant buffer

cbuffer constantBuffer0 : register(b0)

{

matrix modelMatrix;

float3 colour_modifier;

float brightness_modifier;

float transparency_modifier;

}

Then i added one more float3 variable to it so i had:

cbuffer constantBuffer0 : register(b0)

{

matrix modelMatrix;

float3 colour_modifier;

float3 w; //<- added this one

float brightness_modifier;

float transparency_modifier;

}

But then it stopped working. somehow the other variables were no longer aligning properly with the data i send through. (I did add in the 12 bytes for the new float3)

then i tried the following:

cbuffer constantBuffer0 : register(b0)

{

matrix modelMatrix;

float3 colour_modifier;

float w1;float w2;float w3; //now using 3 normal floats instead of 1 float3

float brightness_modifier;

float transparency_modifier;

}

and then it worked... I simply replaced the float3 with 3 normal floats but I dont understand why that would make a difference (as far as i understand both would use the same 12 bytes). Im very new to directx so im hoping i might just miss something obvious.

Thnx!

Empire Rising

Buckeye

10,754

August 11, 2014 07:31 PM

as far as i understand both would use the same 12 bytes

Actually, because the variables in the buffer don't appear in GPU "memory" as they do on the CPU, the buffers you cite do not occupy the "same" 12 bytes. When a constant buffer gets loaded, each variable is loaded into 1 (or more) registers, each register comprising 4 float values. E.g., float3 w get loaded into 1 register. float w1, w2, w3 gets loaded into 3 separate registers.

If you have a graphics debugger (such as GPUPerfClient or the like), and you can look at the assembled shader code, you can see the difference in the loading code.

To determine why the second buffer you list above didn't work, you'd have to post the code for updating the resource and, possibly, the shader code that accesses the variables.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

Wilhelm van Huyssteen

1,232

Author

August 11, 2014 08:09 PM

Ok. I am busy writing a java directx wrapper in c++ to add directx support to my java game engine which only supported opengl up til now. C++ is also completely new to me same as directx so i might be making silly mistakes. I didnt know that constant buffers were futher split into registers.

Here is the relevant c++ code that creates and updates constant buffers. when updating A constant buffer I basically just point to a raw array of bytes. I handle the layout of that byte array java side only.

[source]

ID3D11Buffer* g_pConstantBuffer[14];

JNIEXPORT void JNICALL Java_dmdx_DmdxNative_createConstantBuffer(JNIEnv* env, jobject, jint slot, jint size)

{

D3D11_BUFFER_DESC bd;

ZeroMemory(&bd, sizeof(bd));

bd.Usage = D3D11_USAGE_DEFAULT;

bd.ByteWidth = size;

bd.BindFlags = D3D11_BIND_CONSTANT_BUFFER;

bd.CPUAccessFlags = 0;

HRESULT hr = g_pd3dDevice->CreateBuffer(&bd, nullptr, &g_pConstantBuffer[slot]);

if (FAILED(hr))

{

printf("c++ error 8");

printf(getErrorMessage(hr));

}

g_pImmediateContext->VSSetConstantBuffers(slot, 1, &g_pConstantBuffer[slot]);

g_pImmediateContext->PSSetConstantBuffers(slot, 1, &g_pConstantBuffer[slot]);

}

JNIEXPORT void JNICALL Java_dmdx_DmdxNative_updateConstantBuffer(JNIEnv *env, jobject, jint slot,jobject data)

{

g_pImmediateContext->UpdateSubresource(g_pConstantBuffer[slot], 0, nullptr, env->GetDirectBufferAddress(data), 0, 0);

}

[/source]

EDIT: ok so you said everything is stored in 16 byte (4 float right?) registers. By that Im thinking im just building up that array incorrectly. When i changed al my float3's to float 4's it started working perfectly. Then i thought i should simply pad my float3's with 4 bytes at the end so they fit into 16 bytes instead but that doesnt seem to work.

Empire Rising

MJP

20,295

August 11, 2014 08:38 PM

HLSL has some weird packing/alignment rules for constant buffers due to legacy hardware issues. The rules are described here, and I would suggest reading them.

What's getting you in this case is that your "w" value will get aligned to the next 16-byte boundary to satisfy the packing rules, which state that a vector type can't span a 16-byte boundary. So when w is a float3 it will start at byte offset 80, but when you use scalar types they start at byte offset 76.

The Blog | The Book