• Advertisement
Sign in to follow this  

Can we use 16bit 8bit float for StructuredBuffer

This topic is 683 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

Hey Guys,

 

We could make almost StructuredBuffer as equivalent to Typed DXGI_FORMAT_R32G32B32A32_FLOAT by defining our stuctured buffer only contain 4 32bit float. and specify the right size

 

But how could make StructuredBuffer equivalent to DXGI_FORMAT_R16G16B16A16_FLOAT?  I have tried the naive way, but it didn't work.

 

So to generalize the question, how could we use 16bit or 8bit float in structurebuffer?

 

I know we could use DXGI_FORMAT_R32G32_UINT for 4 16bit float and to the conversion in shader, but I hope not to do the conversion in shader.

 

Any suggestions or comments will be greatly appreciated.

 

Thanks

Share this post


Link to post
Share on other sites
Advertisement

You can't do what you ask, Structured Buffers are typed by the structure in HLSL, so that means 32bit int/uint/float only.

 

The question is, why do you need to use a StructuredBuffer? What's wrong with a Buffer<float4> created using the R16G16B16A16_FLOAT format?

Share this post


Link to post
Share on other sites

Thanks Adam, just want to benchmark StructuredBuffer TypedBuffer Texture. And sometime, I don't think I need 32bit float, for example, I may need a buffer with 5 channels each only need 16 or 8 bit precision, which cannot fit within one TypedBuffer, and it's waste of memory and bandwidth to use 2 typedbuffer,  so I am wondering...

 

But thanks for the clarification

Share this post


Link to post
Share on other sites

I'm not sure why you think using two typed buffers for 5 channels of data is a waste of bandwidth or memory? One of R16G16B16A16_FLOAT and one of R16_FLOAT sounds fine to me.

Share this post


Link to post
Share on other sites

hummm......You are right, I didn't know we have R16_FLOAT there.... But this brought me another question: It seems all structuredbuffer can be break into multiple different tryped buffer, so in what scenario do we really want to use structuredbuffer?  Do we get better performance to bond only one big structuredbuffer over multiple typedbuffer?

Edited by Mr_Fox

Share this post


Link to post
Share on other sites

Questions like that are heading into the territory of "you'll just have to try it and find out".

 

There are some things that can only be done with structured buffers like being an Append/Consume buffer or whose elements supporting Interlocked operations. There's also a lot of unhelpful rules about BIND flags in D3D11 (most of which I've forgotten) that mean some types of buffers can/can't be viewed as Buffer<>/StructuredBuffer<>.

 

Multiple buffers aren't inherently a bad thing, especially if it means you can compress your data in a way that's either more difficult with a StructuredBuffer or costs you instructions to decompress it manually. I tend to ask myself the question: "How much of my structure am I actually accessing at each time that it's used?". If the answer is "I always need to read/write the entire structure", then a single buffer is fine. If the answer is "Sometimes I only want to read a subset of the structure" then I may look to split the structure apart into two separate buffers so I don't waste bandwidth reading the bits I don't want. You commonly see this with vertex buffers where 'Position' is split out into a separate buffer in order that shadow passes don't read attributes they don't need (Normals, Colours, Tangents, etc).

 

Your first priority should probably be to keep your data as compact as possible and then think about how to lay out your buffer(s) in a way that is designed around what data gets read/written at what time. Don't be afraid of multiple buffers though. Just don't be silly about it and put every float in a separate buffer just for the sake of it.

Edited by Adam Miles

Share this post


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

  • Advertisement