Jump to content
  • Advertisement
Sign in to follow this  
Husbj

Size of subresource?

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

I was wondering if there is any way to retrieve the byte size of a subresource in D3D11?
I know that ID3D11DeviceContext::Map returns row and depth pitches as part of a D3D11_MAPPED_SUBRESOURCE structure but I'd rather not have to go down this presumably very costly route.

 

In case there are other workarounds, my goal is to determine the width and height of the mip levels of an arbitrary Texture2D resource.

From what I can tell the mip maps may either be calculated by progressively dividing the "full" texture width and height by two and rounding it up to the nearest integer value, or it will be clamped to the nearest power-of-two of such a division. Which one to use of these doesn't seem to be set in stone however and from what I can tell D3D11 basically supports any size of the individual mip levels, if you now wanted to do that.
Of course I could try to capture this information upon creation (for example loading a dds file) but it feels like it should be available to the runtime and therefore be possible to query somehow?

 

 

Thanks for any input.

Share this post


Link to post
Share on other sites
Advertisement

The size of mip N + 1 is the result of taking the dimension of mip N, dividing by two and rounding down, except where such a calculation results in a dimension of 0, in which case it's rounded back up to 1.

 

The calculation is very simple:

 

WidthOfMipN = max(Width of Mip 0 >> N, 1); // >> is the operator that does bitwise shifts to the right.

HeightOfMipN = max(Height of Mip 0 >> N, 1);

 

D3D11 resources can have GetDesc called on them which provides you the dimensions of Mip 0, and therefore provides all the information you need to calculate the size of any mip in a one-line calculation, no repeated dividing and rounding.

Share this post


Link to post
Share on other sites
As above, mips are always half the size of the previous level, rounded down, qnd clamped at 1px. The smallest mip is always 1x1(x1).

A shorthand estimate is that a texture with a full mip-chain is 4/3rds the size of one without a mip-chain.

Resources can vary in size because you don't always have to have a full chain all the way down to 1x1 -- you might only have 1 or 2 mips.

However, this knowledge only lets you compute the ideal size of the resource. Pitch padding, subresource alignment, tiling/swizzling may all affect the actual memory requirements on the GPU, and D3D11 gives you no way to query these details.
The trick of mapping a texture to discover it's pitch won't work -- that possibly relocates the data / changes it's layout. Usually GPU-allocated textures use swizzled/tiled addressing instead of pitch-based addressing in tge first place, making it irrelevant!

Share this post


Link to post
Share on other sites

Hm so it is rounded down, not up, I see. Thanks for pointing that out.

Also I was under the impression that the mip levels could technically be of any size smaller than the previous one (technically though of course this wouldn't make much sense in practice), but I guess that isn't so then?

 

I'm mainly interested in the size to ensure I can provide a correctly sized replacement buffer to UpdateSubresource, so I assume this will do any tiling, etc. needed from a "raw" texture (mip) block and so that won't be a problem. There were never any issues doing this with the topmost mip level at any rate. But I will try it and see. Thanks again for your explanations :)

Share this post


Link to post
Share on other sites

Hm so it is rounded down, not up, I see. Thanks for pointing that out.

Also I was under the impression that the mip levels could technically be of any size smaller than the previous one (technically though of course this wouldn't make much sense in practice), but I guess that isn't so then?

 

Correct, a mip chain is always strictly "divide by two and round down (min of 1)" relative to the previous mip, there are no scenarios where that's not the case.

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!