Jump to content

  • Log In with Google      Sign In   
  • Create Account


DirectX11: Reading raw texture data on the CPU


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 dr4cula   Members   -  Reputation: 250

Like
0Likes
Like

Posted 03 November 2013 - 10:40 AM

Hello,

 

I'm trying to read the raw texture values of textures in DirectX 11 and I've run into a bit of a weird problem. My code seems to work fine for 512x512 textures but as soon as I try reading data from a 1024x1024 texture, I get a crash at the memcpy() line.

 

Here's relevant code:

// set up the loaded textures as subresources
D3D11_SUBRESOURCE_DATA* subresources = new D3D11_SUBRESOURCE_DATA[texCount];
 
// copy the loaded texture data into the subresource structures
for(UINT i = 0; i < texCount; ++i) {
D3D11_MAPPED_SUBRESOURCE mappedSubResource;
 
HRESULT mapResult = p_deviceContext_->Map(textures[i], 0, D3D11_MAP_READ, 0, &mappedSubResource);
 
if(FAILED(mapResult)) {
MessageBox(NULL, L"Failed mapping a subresource.", L"Error", 0);
return;
}
 
// size of the texture's data defined by the length of a single row of data * the total number of rows (texture height)
subresources[i].pSysMem = new BYTE[mappedSubResource.RowPitch * texHeight];
memcpy(const_cast<void*>(subresources[i].pSysMem), mappedSubResource.pData, mappedSubResource.RowPitch * texHeight);
subresources[i].SysMemPitch = mappedSubResource.RowPitch;
subresources[i].SysMemSlicePitch = mappedSubResource.DepthPitch;
 
p_deviceContext_->Unmap(textures[i], 0);
 
}
 
I'm not quite sure as to why this crashes with 1024x1024 textures. What makes it even weirder is the fact that the textures have the same format, all I've done is scaled the higher resolution ones down.
 
Something similar was happening when I was using OpenGL as well: loading in textures 1024x1024 seemed to crash the application. However in this case, the textures get loaded in without a problem, it's just the reading that fails. (NOTE: I'm not writing to the textures using the GPU, so there are no CPU/GPU read/write access problems).
 
Thanks in advance!


Sponsor:

#2 N.I.B.   Members   -  Reputation: 1060

Like
3Likes
Like

Posted 03 November 2013 - 10:52 AM

Maybe an issue with the last row. RowPitch tells you the offset between rows, it doesn't say anywhere in the spec that last row should be RowPitch in size.

I suggest you try to loop on each row, and copy exactly (PixelSizeInBytes*TexWidth), maybe it will help.

 

BTW, this is a good advice in any case - you then allocate less system memory, and everything in consecutive in memory, resulting in better cache behavior.


Edited by N.I.B., 03 November 2013 - 10:52 AM.


#3 dr4cula   Members   -  Reputation: 250

Like
0Likes
Like

Posted 03 November 2013 - 02:08 PM

Maybe an issue with the last row. RowPitch tells you the offset between rows, it doesn't say anywhere in the spec that last row should be RowPitch in size.

I suggest you try to loop on each row, and copy exactly (PixelSizeInBytes*TexWidth), maybe it will help.

 

BTW, this is a good advice in any case - you then allocate less system memory, and everything in consecutive in memory, resulting in better cache behavior.

 

Thanks for your quick reply! I'm not quite sure how to loop row by row, the following code crashes around j = 344:

 

UINT pixelSize = mappedSubResource.RowPitch / texWidth;
BYTE** pixels = new BYTE*[texHeight];
void* dataPointer = mappedSubResource.pData;
 
for(int j = 0; j < texHeight; ++j) {
pixels[j] = new BYTE[pixelSize * texWidth];
memcpy(pixels[j], dataPointer, pixelSize * texWidth);
dataPointer = static_cast<char*>(dataPointer) + (pixelSize * texWidth);
}
 
I tried changing my original code to copy rowPitch * (texHeight - 1) to discard the final row but that didn't change anything.
 
Thanks in advance once more!
 
EDIT: could it be because of the format of the textures? Currently it's DXGI_FORMAT_BC2_UNORM.

Edited by dr4cula, 03 November 2013 - 02:25 PM.


#4 Adam_42   Crossbones+   -  Reputation: 2419

Like
4Likes
Like

Posted 03 November 2013 - 03:15 PM

Yes, it's because you're using BC2. The data in a BC2 texture is effectively one byte per pixel. It also rounds the width and height up to a multiple of four.

 

For the details how how BC2 textures encode their data look at: http://msdn.microsoft.com/en-us/library/windows/desktop/bb694531%28v=vs.85%29.aspx#BC2



#5 dr4cula   Members   -  Reputation: 250

Like
2Likes
Like

Posted 04 November 2013 - 06:09 AM

1314029819767.png
 
When I was loading the textures, I used ZeroMemory() to fill in the D3DX11_IMAGE_LOAD_INFO struct and only set the format, usage and CPU access flags myself. However, this caused the full mipmap chain to be created because
 
 

MipLevels
Type: UINT
The maximum number of mipmap levels in the texture. See the remarks in D3D11_TEX1D_SRV. Using 0 or D3DX11_DEFAULT will cause a full mipmap chain to be created.

 
 
Once I changed the MipLevels value to 1, my original copying code worked. Oops!
 
Thanks for your replies though!






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS