When the Titan is your primary display and it goes unresponsive, the OS takes it's cues from that driver for the desktop display. The point is that Windows is monitoring this. If you set the samples too high, the GPU will become unresponsive long enough that Windows will actually reset the GPU driver and crash Blender (the operating system doesn't like when it's not sovereign over the affairs of the PC). ![]() You can see this when you enable Branched Path Tracing in the Sampling options. When the driver becomes unresponsive to the Windows kernel (i.e. In order to do this and keep the monitor updating the screen, lag is introduced when the GPU becomes unresponsive for short periods of time. You obviously know that the most efficient way to render is by keeping the GPU load as close to 100% for as long as possible. During that time, the Windows Desktop has to wait on Blender before it can update. When Blender gets assigned the GPU, it doesn't let go of it for an eternity in processing time. When the OS gets an interrupt requesting the GPU, it's put into a queue until the GPU becomes available. ![]() This may not be the answer you're looking for, but I'm pretty sure it has to do with how Blender interfaces with the GPU and how the Windows kernel reacts to that.
0 Comments
Leave a Reply. |