3
\$\begingroup\$

With the DX11 pipeline, would it be much quicker for the vertex buffer to pass one single UINT with one byte per channel to the input assembler, as opposed to three floats? Then the vertex shader would convert the four bytes to four floats, which I guess is the required colour format for the pipeline. In this instance, colour accuracy isn't an issue.

The vertex buffer would need to be updated many times per frame, so using a single UINT and saving 12 bytes for every vertex could well be worth it: quicker uploads to vram and also less memory used. But the cost is the extra shader work for every vertex to convert each 8 bits of the input UNIT into a float.

Anyone have an idea if it might be worth doing?

Or, is it possible for the pipeline to be set to just internally use a four-byte colour format? The swap chain buffer has been initialised as DXGI_FORMAT_R8G8B8A8_UNORM, so ultimately that's how the colour will be written.

Thanks!

\$\endgroup\$
1
  • \$\begingroup\$ Hey Paul, what were your findings (performance wise)? I'm doing something similar and need to rapidly update & resize vertex buffers: \$\endgroup\$
    – Dr. Andrew Burnett-Thompson
    Commented Jan 4, 2013 at 14:57

1 Answer 1

Reset to default
3
\$\begingroup\$

The pipeline will always be floating point internally, and the hardware does the int/float conversions for you, so that part of it should be very fast. If your app is vertex-bound, either on the CPU side updating the buffer or on the GPU side reading it, then the thinner UINT format could make a difference. You'll have to measure and compare the performance to see which is faster.

\$\endgroup\$
4
  • \$\begingroup\$ Thanks Nathan. Looks like I'll need to do some profiling. \$\endgroup\$
    – Paul
    Commented Apr 15, 2012 at 7:29
  • \$\begingroup\$ Speed -- unpacking the four bytes from one uint into four bytes will take a few lines of code, as it'll involve using bit shifts and masking the results with bitwise ANDs, then multiplying the result to get it into the range 0.0f to 1.0f. Using a union would be quick, but HLSL doesn't have unions. \$\endgroup\$
    – Paul
    Commented Apr 15, 2012 at 7:35
  • 1
    \$\begingroup\$ @Paul In sounds like you're loading the value as a single uint and unpacking it yourself in HLSL? Why? You should just use DXGI_FORMAT_R8G8B8A8_UNORM in your input layout, so the API will do the unpacking for you. \$\endgroup\$
    – Nathan Reed
    Commented Apr 15, 2012 at 18:22
  • \$\begingroup\$ Wow Nathan, thanks a huge amount. Had no idea that it would be done by the API. \$\endgroup\$
    – Paul
    Commented Apr 16, 2012 at 8:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .