Sign in to follow this  
Medo Mex

Depth Problem In Release Mode

Recommended Posts

Hello,
 
Sometimes, when I run the EXE file in release mode, I either don't see the depth working at all (most common) or I see a depth problem as it appear in the screenshot:
[attachment=31589:D Problem.png]
 
I'm doing assert(SUCCEEDED(hr)) on HRESULT for D3D11 initialization functions
 
I don't have this problem in debug mode, and mostly I don't have this problem if I'm running release mode from visual studio, the problem mostly appear if I'm running the EXE directly from release folder.
 
I'm using C++ / D3D11
 
Anyone know what could be causing the problem or how do I debug that kind of problem?
 

Share this post


Link to post
Share on other sites

 

what could be causing the problem or how do I debug that kind of problem?

 

 

Could be uninitialized variables.

When compiled in debug mode, visual studio will initialize all variables with well-known values.

It doesn't mean it is initialized to something your code would expect, but at least program's behaviour will be deterministic.

In release mode uninitialized variables will have random garbage, so actual behavior will change randomly between runs, giving weird results.

Share this post


Link to post
Share on other sites

@vstrakh: I'm doing ZeroMemory() on all the structures that I give to D3D11 in the initialization before I put any values, the weird thing is that the problem occur most of the time when I run the release EXE (but not all the time)

Share this post


Link to post
Share on other sites

I'm doing ZeroMemory() on all the structures that I give to D3D11 in the initialization before I put any values, the weird thing is that the problem occur most of the time when I run the release EXE (but not all the time)

And you don't change render states between draw calls?

You may fill D3D structures correctly, but uninitialized variables in other place makes your code to take wrong actions.

It could be you're filling D3D structs based on wrong inputs.

Edited by vstrakh

Share this post


Link to post
Share on other sites

1. add "while(true){Sleep(0);}" at the beginning of "main"

2. start the application externally

3. attach the debugger

4. break at the Sleep

5. set the next line as the point to continue the execution (right click context menu)

6. debug what's different :)

7. fix it

8. transfer out of gratefulness all your moneyz to my account (that's optional, but 7. might break if you don't.)

Share this post


Link to post
Share on other sites

@Hodgman: When I start it with RenderDoc, the game crash after few seconds (during loading), when I attach VS debugger, I see it's crashing during a call to D3DX11CreateShaderResourceViewFromFile()

 

Unhandled exception at 0x0fa813e0 (renderdoc.dll) in Program.exe: 0xC0000005: Access violation writing location 0x00000000.

 

It's only crashing when I run the program from RenderDoc.

Share this post


Link to post
Share on other sites

Okay, all the comments were helpful here.

 

With RenderDoc, I found a warning that the depth stencil buffer size is not the same as the render target view size, so I had to create a depth stencil view for each render target view based on it's size.

 

I also found that I have uninitialized variable m_depthEnabled

 

@Hodgman: I'm still trying to get RenderDoc to work, it's still crashing, please check out my above comment

 

@Krypt0n: Number 8 failed hence number 7 failed as well :D

Share this post


Link to post
Share on other sites

Do you have any repro details you can share for the RenderDoc crash? e.g. is your application available online anywhere to test?

 

I found some source project that was using D3DX11CreateShaderResourceViewFromFile(), but it works OK - so I guess it's something particular that's crashing. If you download one of the latest nightly builds it comes with pdbs too, so getting the callstack with file:line information would be helpful.

Share this post


Link to post
Share on other sites

@baldurk: It seems that I only get this problem if I do many calls to D3DX11CreateShaderResourceViewFromFile() to load a large image file (13,125 KB jpg)

 

I created a demo project which has the same problem.

 

Since the attached files are limited to 8.48MB, I uploaded the project here:

http://www.4shared.com/rar/GkQJa80Gce/Test_Crash.html

 

 

Share this post


Link to post
Share on other sites

Thanks, I repro'd the crash. It's actually simply running out of memory - the program is creating a ~90MB texture every second or so. By default renderdoc saves a copy of this data on the CPU in case the texture is modified (so it can track changes in-place rather than needing to save every delta), eventually the allocation fails. I guess since it's a 32-bit process. I'm surprised how soon it fails actually as it only hits ~1.3GB for me, but maybe memory has fragmented enough that there isn't a large enough contiguous block. That's a complete guess.

 

I'll maybe see if I can add a heuristic so that large textures aren't shadowed unless absolutely necessary, but that still might not help depending on how many of the images are referenced in a frame. If they're all referenced, renderdoc will still allocate memory to readback their contents, and will be back to square one. I'd suggest either switching to 64-bit or using smaller textures if possible :).

Share this post


Link to post
Share on other sites

@baldurk: Unfortunately, I have the same problem even if I reduce the image size to 2.5 MB in the project that I'm working on, although my entire project itself never exceed more than 250 MB of RAM during loading if I'm not using RenderDoc, it reaches 1.5 GB and then crash if I'm using RenderDoc.

 

@bioglaze: Thanks!

Share this post


Link to post
Share on other sites

Do you have another repro project to share that still runs out of memory with smaller images? It's expected to see higher memory usage while using RenderDoc since it is storing shadow (CPU-side) copies of graphics resources. The memory for those graphics resources for the GPU is not counted in task manager, so it's 'invisible'.

 

Also just in case there is some confusion you mention that you reduce the image size to "2.5MB" which doesn't quite make sense. Even though your image is stored as a .jpg, the disk size makes no difference and compressing it further will not change the memory usage in D3D11. The memory usage is entirely determined by the resolution, format and number of mip levels - in this case the .jpg in the example project you uploaded is 5184x3456 and it is created as uncompressed R8G8B8A8 with a full set of mipmaps. That's where the memory use comes from not the file size on disk.

 

btw, this might be more appropriate to move to a github issue.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this