We noticed that our application is no longer able to use QuickSync hardware acceleration for customers that have upgraded to the new Intel DCH driver.
We have analyzed the problem I will describe the behavioral change in the QuickSync implementation by comparing:
=> Bug #1: DCH does not remove the installed files from %WINDIR%\System32 and %WINDIR%\SysWow64 during uninstallation (via Control Panel > Programs > Uninstall)
The actual showstopping bug is a change of behavior regarding device initialization (=> MFXInit)
For Windows there has always existed a direct correspondence between the mfxIml enum value and the D3D device's adapter number like follows:
mfxImplD3D Device Adapter number MFX_IMPL_HARDWARE 0 MFX_IMPL_HARDWARE2 1 MFX_IMPL_HARDWARE3 2 MFX_IMPL_HARDWARE4 3
With the MSDK libraries version 8.0.0.083 this is no longer true. I will illustrate the change of behavior with an example:
mfxImplD3D Dev# D3D Device Name MFXInit (8.0.0.068) MFXInit (8.0.0.083) MFX_IMPL_HARDWARE 0 NVIDIA GeForce GTX 750 Ti MFX_ERR_UNSUPPORTED MFX_ERR_NONE MFX_IMPL_HARDWARE2 1 NVIDIA GeForce GTX 750 Ti MFX_ERR_UNSUPPORTED MFX_ERR_UNSUPPORTED MFX_IMPL_HARDWARE3 2 NVIDIA GeForce GTX 750 Ti MFX_ERR_UNSUPPORTED MFX_ERR_UNSUPPORTED MFX_IMPL_HARDWARE4 3 Intel(R) HD Graphics 530 MFX_ERR_NONE MFX_ERR_NONE**
** No error, but doesn't report the same encoding and decoding capabilities as with 68 and dev 0
This is obviously a bug. MFXInit succeeds, but as soon as an application tries to create a D3D surface on the GeForce device and tries to use that with QuickSync, everything will fail.
That problem is not only specific to our own application, it also affects the use of QuickSync with ffmpeg - which is officially supported and documented by Intel as usage scenario for QuickSync.
=> This is bug #2:
I modified the "sample_decode" sample to demonstrate the bug.
This is based on the media samples from SDK version 220.127.116.112.
Everything is done directly in the main function. The code tries to initialize an MFX session for all hw impl values and displays the corresponding D3D devices.
Run this on a normal system, then install the new DCH drivers. Run again and see the difference.
ATTENTION: If the test system had DCH drivers installed before, you won't see a difference because the uninstaller has a bug as well. It does not remove the MSDK versions that it installs.
You need to test this with a system that never had DCH drivers.
And of course (probably obvious): It must be tested on a system where the Intel graphic adapter is not adapter #0!
I am apologized not been responsive to the forum and long time delay to the problem.
Yes, I have some update. We have also the similar issue reported about DCH driver and we are investigating on it.
If possible, could you make Intel as Adapter 0 to see if it can fix the issue?
I will keep you updated.
thanks for your reply and looking into this issue.
As to your question: Yes it works when Intel is adapter 0. But that's the whole point of the bug, that adapter selection doesn't work anymore.
We are developing a software that needs to work in all user scenarios (and in the same way as it has been working over the past years), so we are not looking for a "fix" for a single system.
It's a regression bug in the Intel drivers and we hope that you can get it fixed.
Please tell me, if you need any further assistance.
The dev team had a conclusion, it is related to dispatcher. This issue should be fixed in 2018R1 or 2018R2 release.
Which MSDK version are you using?
If you did use one of these two versions, please tell me the full steps to reproduce it.
we're using the dispatcher that is commonly used for building ffmpeg:
There has been an update on December 28, 2018
I assume, therse are the changes you are referring to?
Could you use the dispatcher binary in MSDK 2018R2 from the release directly? I have confirmed with dev team that your issue should be fixed in this release.