Jump to content
  • Advertisement
VietNN

DX12 D3D12: CreateShaderResourceView crash

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

Hi everyone, I am new to Dx12 and working on a game project.

My game just crash at CreateShaderResourceView with no infomation output in debug log, just: 0xC0000005: Access violation reading location 0x000001F22EF2AFE8.

my code at current:

CreateShaderResourceView(m_texture, &desc, *cpuDescriptorHandle);

 - m_texture address is: 0x000001ea3c68c8a0

- cpuDescriptorHandle address is 0x00000056d88fdd50

- desc.Format, desc.ViewDimension, Texture2D.MostDetailedMip, Texture2D.MipLevels is initalized.

The crash happens all times at that stage but not on same m_texture. As I noticed the violation reading location is always somewhere near m_texture address.

I just declare a temp variable to check how many times CreateShaderResourceView already called, at that moment it is 17879 (means that I created 17879 succesfully), and CreateDescriptorHeap for cpuDescriptorHandle was called 4190, do I reach any limit?

One more infomation, if I set miplevel of all texture when create to 1 it seem like there is no crash but game quality is bad. Do not sure if it relative or not.

Anyone could give me some advise ?

Share this post


Link to post
Share on other sites
Advertisement

A create view failure result into a device removed, but should not have crashed in the first place. Are you sure you did not destroy the texture and have a stale pointer ?

Share this post


Link to post
Share on other sites

Thank you guys, below is my answer

21 hours ago, turanszkij said:

In cases like this, turning on the debug layer for the directx device could help you a lot. 

Debug layer is on, i still l see some D3D12 warning, so I sure debug layer is working. but the warning is not relative to this, just clear value of some render target is not same as when it is create.

13 hours ago, galop1n said:

A create view failure result into a device removed, but should not have crashed in the first place. Are you sure you did not destroy the texture and have a stale pointer ?

No, there is no device removed in output log, and I did not destroyed any texture

11 hours ago, CortexDragon said:

When you created your descriptor heap how many records did you give it ?

Each descriptor just have about ~20 maximum NumDescriptors, it's quite small I think

Edited by VietNN

Share this post


Link to post
Share on other sites

Still stuck here, do I need to make sure m_texture is not update in any command list why it is being used to create shader resource ?view

Share this post


Link to post
Share on other sites

Hi @SoldierOfLight , I have an offtopic question, about this:

On 4/15/2016 at 11:09 AM, SoldierOfLight said:

The reason for the RowSizeInBytes parameter has to do with pitch alignment. The hardware requires a pitch alignment of D3D12_TEXTURE_DATA_PITCH_ALIGNMENT = 256 bytes, while each row may have less. Specifically, the last row is allowed to consist only of RowSizeInBytes, not necessarily the full row pitch. The pitch is simply defined as the number of bytes between rows, but is technically unrelated to the number of bytes in a row. Did you know that you can actually pass a RowPitch of 0 to read the same row over and over again

If i have a texture 128 x 128 with BC1 format, on mip level 2 it will be 32x32, so the RowSizeInBytes will be 64 (and numRow will be 8), but due to pitch alignment each row will be 256, will the rest be empty ? And when API use it, does it use 64 bytes to make a textures or make a texture with 256 x 8?

Edited by VietNN

Share this post


Link to post
Share on other sites

This question is vendor dependent for the textures. All hardwares use tiling and swizzling to improve texture reads, and they have a full set of tweak here even for a single format. You do usually use layout unknow for your texture so you don't know the exact padding structure. There is a 64k standard tiling that no one implement i believe and a 64k unknow for tile resources (with miptail)

 

You have the GetMemoryFootprint function (needed to know memory usage for a placed resource). So you can measure the delta between actual needed memory and actual data memory.

And you wont have a 256x8 texture, more likely the footprint of 256x64. Small textures waste the most memory, on GCN for example, BCn use 32pixel alignments. As for the row size aligned on 256, this is only for the transfer from/to buffers, it does not influence the texture layout.

Share this post


Link to post
Share on other sites

  • 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!