Ever since I picked up Titans during the summer sale the game has crashed after booting it up and playing for a few minutes, sometimes it will stay stable for 20-40 min, but it usually crashes well before then. Whenever I reboot the game, it then goes and says that a "possible graphics driver crash was detected". I have reinstalled the game several times, installed older driver versions, and completely removed all components of the driver software from PC and Registry. I talked to someone about it and they said it could be one of the issues with GTX 1070s and GTX 1080s and OpenGL that started in the creator's update but to come here to look for official help. Is there anything else I can try to prevent crashing? If any information besides the DxDiag file and log is needed I can post that as well.
Yes, you PA log indicates a crash in nvoglv64.dll which is the OpenGL part of the Nvidia drivers, so they may be right about that. One thing you can still try is to check the list of known incompatible software which is here: https://wiki.palobby.com/wiki/Windows_Incompatible_Software Also try the clean boot option mentioned at the end.
I checked the incompatible software list and had none of those programs installed, uninstalled a bunch of software I thought might have issues that were just sitting around on my PC, then tried safe mode and it still crashed. Does that mean it's something I have to wait for a driver update to fix the issue?
I'm not sure really. @NeonTheCoder has the same problem here: https://forums.uberent.com/threads/pa-exe-has-stopped-responding-1-5-minutes-into-game.72481/ (That's a GTX960 by the way) All I can really see is that the crash happens inside the driver, but I don't know why that would be. I tried searching for nvoglv64.dll crashes for a while, but couldn't really find much about it. Some reported success with rolling back to older drivers, but you have already tried that, so I am a bit at a loss.
I think know that crash, I have seen that stack frame before in a different context, in a Vulkan application. The Nvidia driver crashes if the fence is already started being waited on in another thread, while not yet submitted to the GPU. The crash then occurs in the thread trying to submit the fence. Requires a CPU side semaphore to block waiting on the fence until submission is complete.
Interesting. I haven't done OpenGL programming for a long time, so my knowledge is horribly outdated and simplistic at that. Isn't it usually the case that any OpenGL calls are limited to one thread? I think that was because there is little to be gained from doing drawing calls from multiple threads because they need to wait on the GPU anyway, but I'm not sure. And I thought one of the benefits of OpenGL over Vulkan was multithreading? Anyway, probably something for @mikeyh to look at then.
Usually, at least all calls which modify the state or submit work to the GPU are limited to a single thread. Fences are a special case, they are for waiting on the CPU side until a specific checkpoint has been reached on the GPU (e.g. until a buffer is safe to access), and the waiting may happen in other threads. There is just the limitation that the other thread must not start waiting on a fence which the GPU doesn't even know about yet. With Vulkan it's still similar. There are costly parts which may now happen in other threads (e.g. assembling command buffers for the GPU), but submitting them is then still single threaded. Another form of "threading" comes from the explicit exposure of multiple command queues per GPU which could (in theory) execute asynchronously on some platforms (so if e.g. one queue was blocked on an incomplete buffer copy, another one could be scheduled), but submitting to these queues is also still single threaded. So is also resource management, and possibly a few more aspects. Point about Vulkan is getting rid of the CPU load on the thread which is submitting, so that (unavoidable) idle times on the GPU can be reduced for situations where the individual work-shares on the GPU are only small, compared to the OpenGL API overhead required to describe them. There are some hacks possible with Vulkan which allow actual "multithreading", as the same Vulkan capable GPU can be instantiated virtually multiple times per application, providing completely isolated access in all regards including threading, but that is really messy, and not really a good option since exchanging data between these instances the becomes more challenging.
