I am working on a QT application for which I've integrated DirectX 11 into a custom widget. The application renders a scrolling display - a graphical representation of data being read from a file. The user can speed up and slow down the scrolling speed.
For the most part, this is working great. The DirectX 11 rendering is presented to my custom widget just as I'd expect. The problem is that the graphics driver randomly hangs and crashes my program. I say "random" because I have been testing this with the same data file and it never seems to crash at the same point in the file, after a specific amount of time, or at a specific scrolling speed (the faster the scrolling speed, the more work being done by the GPU per frame).
When the application hangs, my screen freezes for a moment, goes black, then returns with a nice message from NVidia that it has recovered from a driver crash. The Debug Output in Visual Studio contains the following:
D3D11: Removing Device.
D3D11 ERROR: ID3D11Device::RemoveDevice:
Device removal has been triggered for the following reason
(DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of
time to execute its commands, or the hardware crashed/hung. As a
result, the TDR (Timeout Detection and Recovery) mechanism has been
triggered. The current Device Context was executing commands when the
hang occurred. The application may want to respawn and fallback to
less aggressive use of the display hardware). [ EXECUTION ERROR #378:
DEVICE_REMOVAL_PROCESS_AT_FAULT]
I have discovered that by simply commenting out the IDXGISwapChain1::Present call, the application will run through the file at blazing speed. Graphics-wise it is still pushing data to the GPU and drawing to render targets, it just never gets displayed to my window.
What I'm hoping for is help with ideas of what types of things cause driver hangs. My shaders are incredibly simple - basically just positioning my vertices using a projection matrix. And considering what I described in the above paragraph, shaders should still be cranking through vertices and pixels even when Present isn't being called, yes?
I was suspicious that this could be a compatibility issue with Qt - I know DirectX isn't officially supported by Qt. So I tried creating a separate window using CreateWindowEx and using that for my swap chain instead of the custom Qt widget. It rendered to that window but also hung the driver just like before.
I was also suspicious of a driver bug in my laptop, so I tried running the application on a beefier desktop PC that regularly runs another DirectX 11 application (non-Qt) without a hitch (worth mentioning that this other application renders similar data in a scrolling display as well, using shaders that are a lot more complex). But my QT application hangs the driver on that PC as well.
Anyone know of a way I can get a more detailed description of what is causing the driver to hang?
Thank you in advance for any help you can offer.
UPDATE: 2013-08-01 17:16 CST
I am currently investigating a possible thread syncing issue that may be the culprit. Will continue tomorrow morning and post if I solve this on my own.
After some testing today, it appears to have been a threading issue. I have run several times today with no graphics crash. So my problem must be fixed, unless I've just been getting lucky with my tests today (or unlucky, rather - if this shows its ugly face again in a day or two).
I was aware that the immediate device context is not thread safe. Rather than using deferred contexts, though, I was using critical sections to sync my threads and coordinate use of the device context. What I did not realize is that it is not safe to call IDXGISwapChain1::Present while another thread is using the device context. Makes sense, but since it is not call directly from the device context itself, I overlooked it. I literally moved my Present() call a few lines up into my critical section block, and it hasn't given me a crash since.
Related
I have installed Domino Designer in a Windows VM on VirtualBox on OS X.
When I start entering code in the JavaScript editor, Domino starts to work for every letter I type. The hourglass icon appears and the network symbol on the status bar flashes. This operation takes up to several seconds for every letter I type.
If I try to type anything before the hourglass disappears, the keyboard may hang up and the result is a long list of the same letters that I have to delete again (causing the hourglass to appear for each letter I delete again).
I have tried to disable functionality like "Content Assist", "Quick Diff" and other helpful stuff without luck.
I would really appreciate hints or tips to make this nightmare vanish...
I've not used domino designer, but first thought would be that your VM isn't handling the processing required by the designer.
What are the specs on you windows VM? Did you allocate enough RAM, for example? Make sure they match the requirements to run the designer:
http://www-969.ibm.com/software/reports/compatibility/clarity-reports/report/html/softwareReqsForProduct?deliverableId=1351628933716&osPlatform=Windows
Thanks to Joel for leading me into the right path.
I did several things, and together it now seems that I have a much better environment. I still see the hour glass from time to time, but it does not mess up my code anymore, and most of the time it does not bother me.
What I did was the following:
Changed the memory settings for Domino in this file:
[notes dir]\framework\rcp\deploy\jvm.properties
New values:
vmarg.Xmx=-Xmx1024m
vmarg.Xms=-Xms512m
vmarg.Xmca=-Xmca512k
Then I changed the virtual memory of my guest Windows install to a fixed swap file of 4096 MB.
At least I connected my Mac to a faster network using Thunderbolt to Ethernet cable adapter. I don't think the last thing did any difference, but at least I now have a faster and more reliable network connection.
this is a more unusual question so give me a hint when stack overflow isn't the right place for it. ;)
I have a problem with Visualstion 2012 where it freezes every so often when I compile my project.
I am currently working on a Qt project so the Qt add-in is installed. I am sure you can't remote-fix my problem but I would like to ask what could cause such freezes.
Here are some important infos:
the PC doens't freeze every time I compile (seems to be a bit random)
the freeze takes from 5 to 15 minutes. In most cases, it ends with the screen switching to black and then back to "normal"
I often try to open the task manager which returns an exit code after the freeze which says that the task manager couldn't start
the PC comes back to life after 5-15 minutes but many applications (incl VS) aren't responding for additional ~5 minutes.
the hardware components are fine for what I can tell. (I tested HDD and RAM, temps are fine)
I hope you can give me a hint where the cause of the freezes could be hiding. ;)
You could start by analyzing what is unique about your system.
Perhaps you are using an unusual source control system, anti-virus, network connections, mapped drives or some weird form of integration that nobody else uses. My guess is that this may be your source control integration or some server connection that is triggering an unusual locking condition.
I am having an issue with connecting the Color Converter DMO object in graphedit (graphstudio, and in code). It works on one machine and turns green in graphedit, however on the machine I have to demo the program on it will not connect! I've looked at sdks, installs, and the machine should mimic my machine.
I also noticed that I can reregister the filter on my machine with regsvr however it fails on the other machine.
Any ideas as to what the culprit could be?
Why would you want to re-register it, it is either a core OS component, or not available at all
It is not a filter, it is dual interface DMO/DSP and while it is available within DirectShow through DMO Wrapper Filter, this use scenario is not guaranteed to work out smoothly and you possibly have to workaround issues.
Having wrapped it through DirectShow.NET library, the number of issues might increase, so you have to gather and provide more details about the errors on the way (HRESULTs etc).
I use a third-party DLL (FTD2xx) to communicate with an external device. Using Qt4, in debug mode everything works fine, but the release crashes silently after successfully completing a called function. It seems to crash at return, but if I write something to the console (with qDebug) at the end of the function, sometimes it does not crash there, but a few, or few dozen lines later.
I suspect a not properly cleaned stack, what the debug build can survive, but the release chokes on it. Did someone encounter a similar problem? The DLL itself cannot be changed, as the source is not available.
It seems the reduction of the optimization level was the only way around. The DLL itself might have problems, as a program which does nothing but calls a single function from that DLL crashes the same way if optimization is turned on.
Fortunately, the size and speed lost by the change in optimization level is negligible.
Edit: for anyone with similar problems on Qt 5.0 or higher: If you change the optimization level (for example, to QMAKE_CXXFLAGS_RELEASE = -O0), it's usually not enough to just rebuild the application. A full "clean all" is required.
Be warned - the EPANET library is not thread safe, it contains a lot of global variables.
Are you calling two methods of that library from different threads?
I have this very strange problem on a big flex app where it would run fine with the debug swf if the user has debug flash installed but will have some disparities for people with standard version of flash.
These disparities include:
No pop ups
loose all event catching
Weird positioning of a button
I read somewhere that updatedisplaylist was handled differently ?
For now i will try the export release way instead of the bin-debug swf, and to go back in the commits to see what was the turning point.
Any similar experiences ?
I've been using Flex for a long time and have never heard of any problems like these being related to using the debug vs standard versions of the Flash player, but I have experienced problems similar to what you're experiencing.
When an exception occurs in your application, like attempting to access something in a null class or trying to access element 10 in an array that only has 9, the debug player will pop up a window stating that an exception has occurred and give you a stack trace, even if you're not actively debugging the app. The standard player does not, so the user will have no way of knowing that something went wrong.
In my experience after an uncaught exception occurs it can make all running code from that point on very unstable, causing all of the problems you list and more.
I doubt your problem has anything to do with the two different players beyond the standard one not giving you any feedback about the state of your app.