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

DXVA2: adjust memory limit for 4K decoding from 3000 MB to 2960 MB #18980

Merged
merged 1 commit into from
Dec 23, 2020

Conversation

thexai
Copy link
Member

@thexai thexai commented Dec 23, 2020

Description

  • Adjust memory limit for 4K decoding from 3000 MB to 2960 MB
  • Change fallback strategy to limit decoder surfaces to 16 instead of exit

Motivation and Context

Try to improve some situations where the hardware is at the limit to be able or not to use DXVA2 HEVC 4K decoding:

See https://forum.kodi.tv/showthread.php?tid=359216 This system has really 3 GB video memory: 2 GB dedicated (GT 1030) 1 GB shared (only 2GB system RAM).... number reported is 2989 MB and should be considered 3 GB.

See https://forum.kodi.tv/showthread.php?tid=359247 This system has only 4 GB RAM and no dedicated video memory and Celeron J3455 has not power enough for SW HEVC decoding. The only possibility is limiting decoder surfaces to 16 as Intel video driver does not use additional refs by CPU cores and HEVC files never has more than 8 refs frames. Maybe on other cases does not work but is better that nothing (SW on 4K).

These changes are safe to merge because on more habitual systems (+3 GB video memory or +4 GB RAM) nothing changes.

How Has This Been Tested?

Tested on ASUS ZenBook UX305UA (4 GB RAM, Intel HD graphics 520) limiting decoder surfaces to 16 works pretty well on this system and able to use DXVA2 HEVC 4K decoding. Only observed some green glitch when seek to random point and it normalizes after a few seconds playing.

Waiting feedback from forum users....

Screenshots (if appropriate):

Types of change

  • Bug fix (non-breaking change which fixes an issue)
  • Clean up (non-breaking change which removes non-working, unmaintained functionality)
  • Improvement (non-breaking change which improves existing functionality)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that will cause existing functionality to change)
  • Cosmetic change (non-breaking change that doesn't touch code)
  • None of the above (please explain below)

Checklist:

  • My code follows the Code Guidelines of this project
  • My change requires a change to the documentation, either Doxygen or wiki
  • I have updated the documentation accordingly
  • I have read the Contributing document
  • I have added tests to cover my change
  • All new and existing tests passed

Change fallback strategy to limit decoder surfaces to 16 instead of exit
@enen92 enen92 requested a review from afedchin December 23, 2020 17:12
@enen92 enen92 added Component: DirectX rendering Type: Fix non-breaking change which fixes an issue v19 Matrix labels Dec 23, 2020
@enen92 enen92 added this to the Matrix 19.0-RC1 milestone Dec 23, 2020
@fritsch
Copy link
Member

fritsch commented Dec 23, 2020

Do you need the 2960 MB or could we go down even more? Perhaps combining it with less render buffers?

@fritsch
Copy link
Member

fritsch commented Dec 23, 2020

Looking at the standard: The maximum for HEVC Level 5.1 is 6 (!) at 3840x2180. So you could go down even more - but what you did here will obviously work. So would be fine with me. If you see no need to e.g. go down to 12 or something I can approve your Request.

@thexai
Copy link
Member Author

thexai commented Dec 23, 2020

This is not a trivial topic in Windows... there is a lot of work already done behind it:

See:
#18284
#18195

and

https://forum.kodi.tv/showthread.php?tid=355800

especially https://forum.kodi.tv/showthread.php?tid=355800&pid=2963390#pid2963390

The general answer is that the safe memory limit cannot be lowered much further and can not be used less of 16 surfaces especially on powerful and current NVIDIA / AMD hardware because needs additional surfaces depending on CPU cores (video drivers can use multi threading for HEVC decoding).

This PR only tries to improve some specific cases (on old hardware) without endangering or impairing the correct operation in the most modern hardware that 90% of users use today.

@fritsch
Copy link
Member

fritsch commented Dec 23, 2020

Okay - fine with me. Thanks.

@enen92 enen92 merged commit 877b8b5 into xbmc:master Dec 23, 2020
@thexai thexai deleted the dxva2-memory branch December 26, 2020 19:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants