QuickSync functionality broken with DCH driver (25.20.100.6444)

[softworkz]

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:

• The DCH driver: 25.20.100.6444 further referred to as 'DCH'
• with the latest..
• Non-DCH driver: 25.20.100.6373 further referred to as 'STD'

Differences:

Installed Versions:

• DCH installs QuickSync/MSDK binaries of version 8.0.0.083
• STD installs QuickSync/MSDK binaries of version 8.0.0.068

Installation Locations:

• DCH installs all MSDK  libraries into %PROGRAMFILES%\Intel\Media SDK, %WINDIR%\System32 and %WINDIR%\SysWow64
• STD installs MSDK  libraries only into %PROGRAMFILES%\Intel\Media SDK

=> 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: 

[softworkz]

I modified the "sample_decode" sample to demonstrate the bug.

This is based on the media samples from SDK version 8.3.26.352.

• You need to replace the files in both, the sample_decode and the sample_common folders with the attached files
• Open the sample_decode solution
• Compile 
• Run sample_decode.exe

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!

[softworkz]

Any news on my issue?

[Mark_L_Intel1]

Hi Workz,

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.

Mark Liu

[softworkz]

Hi Mark,

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.

Thanks again,

softworkz

[Mark_L_Intel1]

Thanks Workz,

This is a good feedback and I will forward it to the dev team. I will keep you updated for the progress.

Mark

[Mark_L_Intel1]

Hi Workz,

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.

Mark

[softworkz]

Hi Mark,

we're using the dispatcher that is commonly used for building ffmpeg:

https://github.com/lu-zero/mfx_dispatch

There has been an update on December 28, 2018

https://github.com/lu-zero/mfx_dispatch/commit/a7d95e5f7e5b4967b8beb8164fd978d9572aba71

I assume, therse are the changes you are referring to?

Thanks,

softworkz

[Mark_L_Intel1]

Hi Workz,

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.

Mark

[Robinson__UK]

We've had what appears to be the same issue.  After updating the dispatcher the issue has been resolved.  Thank you.