• Advertisement
Sign in to follow this  

Directx 11 constant buffer question

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

 

Share this post


Link to post
Share on other sites
Advertisement

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.

Edited by Buckeye

Share this post


Link to post
Share on other sites

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.

Edited by Wilhelm van Huyssteen

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement