[IDXGISwapChain::Present with !m_bVSyncOn unnecessary burns GPU
ChemistAion opened this issue · comments
Premise: GPU suffers "burn" for no reason...
[Simple]
Change bVSyncOn
to true
here:
glTFSample/src/DX12/GLTFSample.cpp
Line 260 in 11f4bc7
[Moderate]
IMHO you should consider better pump-massage handling... my snippet:
for (;;)
{
//TODO: vectorize handles...
DWORD result = ::MsgWaitForMultipleObjectsEx
(
0,
NULL,
1,
QS_ALLINPUT,
MWMO_ALERTABLE | MWMO_INPUTAVAILABLE
);
if (WAIT_OBJECT_0 == result || WAIT_FAILED == result)
{
while (::PeekMessage(&msg, 0, 0, 0, PM_REMOVE))
{
if (WM_QUIT != msg.message) [[likely]]
{
::TranslateMessage(&msg);
::DispatchMessage(&msg);
[[likely]] continue;
}
goto Terminate;
}
}
...UPDATE...
...BEGIN_FRAME...
...RENDER...
...END_FRAME...
}
Terminate:
"Buckle your seatbelt Dorothy, 'cause Kansas is going bye-bye!"
...DONE...
Yep, there is a goto
there - change my mind...
For single-thread you could count messages up to some level (e.g. 8-16) before fire "work" stuff...
So you're looking for a renderer option that causes it to not present as quickly as possible, unless there is input of some kind, ideally something that causes new GPU work?
I am just wonder, for what we are rendering (one-thread based engine) hundreds/thousands of frames?
OK, as a showcase - I understood: here we have and we could do so many fps
...but still, IMHO it should "start" with some kind of sync for learning purposes
To be straight: now, GPU howls with all the fans for no reason... due to VRAM usage threshold (1080Ti here, but others too...)
We could close this now, but at least please consider "it"...
What do you think?
I'm happy to consider a demand-based rendering mode for a future release, which does have uses other than power limiting. Thanks for the suggestion!
Done :) I will leave this "Open" for now.