Jump to content
  • Advertisement
Sign in to follow this  
Sindharta Tanuwijaya

DirectX11: Hull Domain Shader Crash

This topic is 2857 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,

I've been doing some experiments with DirectX11, and I am currently having a bug, probably in my shader code, or probably in the CPU codes which set the Hull shader, domain shader, etc.

When I debugged, I found out that my computer crashes each time
m_pSwapChain->Present(0, 0)

is called, and I have to restart my PC.

In the case of DirectX 10, usually you'll notice that your objects are rendered incorrectly if there are bugs, but in the case of DX 11 (my current experience anyway), I'm experiencing computer crashes instead, which are much worse.

As I'm still early in the experimental stage and I'm sure that I'm going to face bugs (many of them) down the road, I don't want to restart my PC everytime there is a bug.

I'm wondering if anyone had the same problem before ?

Share this post


Link to post
Share on other sites
Advertisement
Your computer isn't supposed to crash (mine doesn't).If it crashes when you call present the swapchain is most probably not initialized properly.

after creating the swapchain use FAILED(hResult) to check if it did create properly and also if it fails exit the program otherwise it will crash ( or just say not responding ).

Hope that helps

Share this post


Link to post
Share on other sites
Hi,

I've checked it, and the swap chain is initialized correctly. I'm sure of this because I can load objects which only use VS and PS successfully.

But when I try to load objects with subdivision surfaces info (for tesselation), the program crashes. I think it's because there is a bug somewhere in setting the DX11, like Hull Shader, Domain Shader, or maybe even the InputLayout for subdivision surfaces, but I don't know where yet.

I don't mind debugging to look for what I am doing wrong, but I am concerned about these crashes.

Even if the swapchain is not correctly initialized, will it cause the system to crash ? I would expect that a runtime error message would appear instead.

[Added]
By the way, what video card are you using ? I am beginning to think that perhaps this has something to do with the card.
I just updated my video driver today, so I suppose I can't do anything about the driver if it's the problem, but maybe I can change my video card.


[Edited by - Sindharta Tanuwijaya on October 20, 2010 12:27:02 AM]

Share this post


Link to post
Share on other sites
Driver bugs are a common source of crashes. Sometimes, bound checking and stuff like that is even deliberately left out from some parts of the drivers in order to get more runtime performance at the cost of stability on exotic use cases.

The reference rasterizer (REF) is a software driver which emulates a real hardware/driver combination. It can be used to verify your D3D usage and it can provide extensive debug information about your calls. The only con is that it is very slow compared to actual hardware, but you can switch between it and hardware at runtime if you use D3D11. This way, you can render only specific frames (those that crash) using it if you need to navigate your application to the correct state first.

Share this post


Link to post
Share on other sites
Thanks. If I use REF, my computer doesn't freeze. The compiler also outputs debug information, and what I got is something like this:

D3D11: ERROR: Reference Rasterizer: Hardware Exception: Out of bounds control point index: 4717

Going to check about it soon.

However, I still find it a little bit inconvenient if we have to switch to REF everytime we want to fix a bug. What's more, my Visual Studio crashes everytime I stop the application from running (after having that error). I guess that's better than my PC crashing everytime though.

Any other suggestions ?

Share this post


Link to post
Share on other sites
Well, the underlying issue is an access violation which should be considered a critical bug even though it would only involve CPU-side logic.

In this case, you should be particularly careful about the contents of the index buffer in conjunction with the length of the vertex buffer. I assume that one or several indices point past the valid range of the current vertex buffer (read access violation), and you can probably imagine that the behavior of the system cannot be well defined in this type of scenario. Yet, until the rasterizer actually tries to execute the draw command against the data, the data itself seems valid to the system (it could well be random numbers).

The reference rasterizer is also affected because the memory allocated to its internal buffers conceptually behaves the same way as a real hardware memory bank.

Share this post


Link to post
Share on other sites
Also, use the "switch to ref" layer if you want to toggle between REF and real hardware at runtime. This way, you can enable the reference device for specific frames that you want to debug. This is as convenient as it gets.

Share this post


Link to post
Share on other sites
Someone told me yesterday that I might have my registry keys incorrectly set, and it appears that he was right.

At first, I had the Timeout Detection and Recovery (TDR) disabled completely. But after I set it using the default values described in:

http://www.microsoft.com/whdc/device/display/wddm_timeout.mspx

my screen just flickered and the system was restored everytime I executed the critical bug, which was causing my system to freeze before.

I wonder how it got disabled in the first place. Factory settings maybe, hmm.

Now, on to debugging the bug !




Share this post


Link to post
Share on other sites
The TDR disable is a good option to have when you're debugging GPU stuff such as compute shaders, wherein you don't necessarily know in advance how much time your shaders may consume and it is probable that some shader executions take more than two seconds to complete. But it is a two-sided coin like you noticed - the system will crash easily upon bugs if that particular safety net is taken away.

The bug itself - in your case - is probably caused by a logic error in filling your index buffer. In particular, check that for each index, there actually exists a corresponding vertex in the bound geometry streams. The problem is (again probably) that some of your indices point past the available vertex data.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!