Jump to content
  • Advertisement
Sign in to follow this  

Vulkan Row pitch when copying from VkBuffer to VkImage

This topic is 616 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'm working through adding texturing to my program by following vulkan-tutorial.com and was wondering about row pitch. The tutorial states that images must obey the implementation's row pitch amount, which makes sense.

However, the question I'm running into is that I want to use a VkBuffer for staging rather than a separate staging VkImage. From what I can tell, the only way to get the needed row pitch is from the linear tiled staging image. I'm assuming the optimal tiling image will have a different row pitch, and I can't find anything stating either way.

Can I use the row pitch from the destination optimal tiling image, or do I not have to worry about the pitch it in this case?

Edited by CirdanValen

Share this post

Link to post
Share on other sites

Using a copy from a VkBuffer instead of from a linear texture is definitely the right track. Trying to use a linear texture for staging is an exercise in frustration because you run into the irritating limitations that apply to linear textures (like limited format/mipmap support).

You shouldn't have to worry about implementation specifics though. Section 18.4 contains pseudocode describing how it expects your texture data to be laid out in your VkBuffer prior to a call to vkCmdCopyBufferToImage.

Assuming you're not using a block compressed format, the spec says:

rowLength = region->bufferRowLength;
if (rowLength == 0)
    rowLength = region->imageExtent.width;

imageHeight = region->bufferImageHeight;
if (imageHeight == 0)
    imageHeight = region->imageExtent.height;

elementSize = <element size of the format of the src/dstImage>;

address of (x,y,z) = region->bufferOffset + (((z * imageHeight) + y) * rowLength + x) * elementSize;

where x,y,z range from (0,0,0) to region->imageExtent.{width,height,depth}.

There is no need to worry about implementation specifics for staging texture data, that's the driver's problem/responsibility.

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!