Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DesktopDuplication call releaseFrame before acquireNextFrame #373

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Womifa
Copy link

@Womifa Womifa commented Jul 15, 2020

According to the documentation ( https://docs.microsoft.com/en-us/windows/win32/api/dxgi1_2/nf-dxgi1_2-idxgioutputduplication-releaseframe ) the method releaseFrame should be called before the method acquireNextFrame.

@psieg-jenkins
Copy link
Collaborator

Can one of the admins verify this patch?

1 similar comment
@psieg-jenkins
Copy link
Collaborator

Can one of the admins verify this patch?

@psieg
Copy link
Owner

psieg commented Jul 19, 2020

Thanks for the PR!

The issue with this is that it makes the grabbing block until the next frame has been rendered on the GPU. This means that the effectively captured frame rate is ~half of what the grab timer is configured for. (For example, for a 60 FPS monitor/game with 50ms grab interval the theoretical grab FPS is 20. With this, I get only 10.
I don't have a good solution on how to make this work in a way that has a reasonable user experience, I'm open to suggestions.

Do you have any data on how much this reduces GPU load? IIUC the DDupl-capturing is purely GPU, the expensive part of the whole operation is copying the frame buffer back to the system memory, which is unaffected by this. In desktop workloads, the impact of this certainly is near zero (maybe relevant for battery life on laptops, which won't use Prismatik), in gaming >30 FPS there could be some gain.

You should reset m_releaseFrame when the duplication is re-created as well - At the same time, incorrectly calling releaseFrame has no relevant consequences so to me not adding the boolean would be fine as well.

On a side node, please don't reformat half the file for a 4 line patch.

@Womifa
Copy link
Author

Womifa commented Aug 22, 2020

The effect of halving the framerate is weird, I reverted the changes for now and will test it some more when I have time.

I don't have any data of the GPU load, but I noticed a significant drop in performance when using DDupl as it is right now when playing Gears 5 which is why I started searching for some relief.
For now I am testing Windows 10 Hardware-accelerated GPU scheduling. This seems to result in DDupl having less of a performance impact, but at the cost of DDupl starting to stutter when the GPU is under full load (Game running at 70 fps, DDupl struggles at maybe 5 fps).

As for your side note: I didn't mean to change all of that formatting, however Visual Studio 2019 did...

@zomfg
Copy link

zomfg commented Aug 22, 2020

see this for your fps

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants