Too high CPU load when using DG1 for video encoding

[OTorg]

Hi,

We have discovered too high CPU consumption when using discrete DG1 for video encoding (compared with intergated graphics UHD 630).

Absolutely identical task was executed first on the UHD630, then on the DG1. Execution was monitored by VTune 2021.3.0.
Here are screenshots for comparison:

The task was as follows. 8 live uncompressed SD-video streams (720x576i50, 4:2:0 NV12) were encoded in realtime by GPU into h264. Input video frames were supplied to encoders via d3d11-videomem-surfaces. All encodings were performed within one win32-process, mfxSessions were joined. Encoding duration was 60 seconds.

Issues was observed with gfx-driver versions 9466, 9316, 9039 and 9667. Other versions haven't been tested. Screenshots are from version 9667, running on Supermicro X12SAE, i7-10700, ASUS DG1-4G.

Below is a screenshot of the most CPU-consuming area (DG1):

Perhaps the reason is inefficient access to video memory. When I reduce the number of DG1's pcie-lines from 8 to 4, the CPU consumption is roughly doubled.

When I run such task on two DG1 cards simultaneously (in parallel), the CPU load becomes 100% and encoding can't keep up realtime.

I can't post here my application on which test were made, because it is too massive. But you can reproduce issue using native imsdk samples, here is a reproducer:

https://drive.google.com/file/d/1Z6m4kYcpk6lhurI4S8AqHRG7IfT3mPqP/view?usp=sharing

[Gopika_Intel]

Hi,

Thank you for reaching out and providing all the necessary information. Could you also please share the Intel Media SDK version that you are using so that we can check internally and get back to you with an answer.

Regards

Gopika

[OTorg]

Hi,

If you are asking about the versions of igd*.dll and libmfx*.dll libraries, then they are exactly the ones contained in the driver packages I have indicated: igfx_win10_100.9466, 9316, 9039 and 9667.

If you are asking about the libmfx.lib version, which is compiled inside reproducer's sample_encode.exe, then it is from IMSDK 2021 R1 (1.35).

[Mark_L_Intel1]

Hi Alek,

DG1 is new, it would be tricky to report the issue.

I am trying to reproduce to figure out if this is the issue with configuration or driver. Could you tell me your workload(the application for your test)?

As a summary of the environment:

• Windows 10 64bit
• Hardware Supermicro X12SAE, i7-10700, ASUS DG1-4G
• You have tried the driver: 9466, 9316, 9039 and 9667
• Input is 8x(720x576i50, 4:2:0 NV12)

Also too more questions about your testing:

1. How did you tell the application is using DG1 not iGPU?
2. Could you tell me the CPU utilization with Windows Task Manager?

Since this is the first time I had DG1 question, I am also learning.

Mark

[OTorg]

Well, I will try to help in your difficult situation.

As I mentioned, using my original application would be awkward. But the issue can be reproduced using sample_encode.exe, which is provided with the Media SDK 2021 R1.

All the necessary props can be found here: https://drive.google.com/file/d/1Z6m4kYcpk6lhurI4S8AqHRG7IfT3mPqP/view?usp=sharing

sample_encode_N_iGPU.bat starts encodings on iGPU, sample_encode_N_dGPU.bat - on dGPU (card is selected there by -dGfx/-iGfx command-line switch).

I did new measurements using native sample_encode.exe with absolutely identical tasks (except iGPU/dGPU difference) and duration, results are below.

As you can see, usage of one DG1 card consumes 3x more CPU resources than encoding on P630.

And VTune system-wide profiling shows igd11dxva64.dll consumes 12 times more CPU resources when using DG1 (CPU consumption by other modules is about the same).

How else can I help you?

I can give you access to that computer with DG1 cards. Organize it?

[Mark_L_Intel1]

Sounds good, let me try to see if I can reproduce it.

Very appreciated for the detailed instruction and sharing.

Mark

[OTorg]

Hi Mark,

Were you able to reproduce the issue?

Is there any progress?

[Mark_L_Intel1]

Hi Alek,

Not yet. but I have report the issue to dev team.

The problem, I realized I can't reproduce if I don't clarify the configuration. From your report, you used current graphic driver assuming the integrated GPU. AFAIF, there should be 2 drivers, one for integrated GPU, other for discrete GPU. I can confirm this with your first report and screen capture of task manager. I can see both screen shot is from Xe graphic which should be Xe MAX graphic.

The other question is, if we have 2 driver, how we configure the MSDK to use the DG1 driver.

I will keep you updated.

Mark

[OTorg]

Well, I can clarify something.

1.

My DG1 cards have VEN_8086&DEV_4908. This DEV_ID is described as "Iris Xe Graphics" at iigd_dch_d.inf of any driver pack I tested (9466, 9316, 9039 and 9667). But the same marketing name is also used for other DEV_ID, including processor-integrated graphics, e.g. i5-1135G7.

Therefore, the marketing name is not a very reliable way of identifying:)

2.

In the screenshots from my previous posts, all devices use the same driver pack 9667. But, digging in the device properties, I see that DG1 card uses igdkmdnd64.sys, while UHD630 uses igdkmd64.sys. And you can see these different sys-files in the VTune-screenshots above.

3.

Driver pack 9039 is specialized for Xe-devices generation. It doesn't contain drivers for models 530, 630, 640, 655, etc. So, I've installed pack 9316 at first, and then pack 9039. After that I can see that driver 9316 is used by my UHD630, and DG1 uses driver 9039. And nothing has changed in CPU load, it is still high.

[Mark_L_Intel1]

Thanks Olek,

This is great! This is very important to us since it might point out a gap.

There are several problem here,

• The driver should not mix the ID of "Xe" and "Xe Max"
• The graphic driver you installed has the GPGPU context which might not include the video drivers.

I need a new request to dev team to clarify. Overall I believe this is some kinda expected since we are releasing DG1 not so long so the video part might be fall behind.

Let me check with dev team and keep you updated.

Mark

[Mark_L_Intel1]

Hi Olek,

Sorry I didn't pay attention your reproducing package. I found it and I run it on my 7506 device. I think I can reproduce the issue you reported.

I have update the ticket with your reproducer package and ask dev team the question again.

I will keep you updated.

Mark

[Mark_L_Intel1]

Hi Olek,

Just one more question, when you open Device Manager and unfold "Display Adapters", how many devices do you see and what are their names?

Mark

[OTorg]

Hi Mark,

Here they are:

This computer has three DG1 pcie-cards and one processor graphics.

[Mark_L_Intel1]

Hi Olek,

You should check your hardware platform since the device entries in Device Manager looked different from mine.

Based on the information from you, it seems related to device ID in the firmware. If you run Dell SupportAssist, it will tell you if you need to update driver, firmware, etc. For me, I updated new Firmware a couple days ago, unfortunately I didn't pay attention to the device manager entries before the update but after that, I had consistent 2 entries as showed above no matter how many time I uninstall the graphic driver.

For this 27.20.10.9466 driver I installed, I run your reproducer and found dGPU has 2x more CPU utilization than iGPU as showed below. But I believe this is the driver issue and will be fixed in the future, I am working with dev team to address this issue now.

CPU utilization on dGPUCPU utilization on iGPU

I am not sure if this related to the time when Dell release the device, mine bought about May. Could you check on your side and make sure the firmware correct?

Mark

[OTorg]

Hi Mark,

I don't quite understand what kind of firmware you are talking about. Probably, about the DG1 firmware.

Drivers/OS find their devices by the VEN_ID+DEV_ID identifiers, which are contained in the device firmware and are displayed outside through the PCI BAR mechanics.
Then we have a binding of DEV_ID to user-friendly device name through the driver's inf file.
This is a reasonably important information, flashing the wrong firmware can turn device into a brick.
And firmwares that change DEV_ID, I would classify as exotic or deeply engineering.

My Intel Driver & Support Assistant says all is up to date, and I didn't find any "update firmware" button inside it. The same goes for Intel Graphics Command Center. downloadcenter.intel.com also hasn't any GPU firmware available.

Can you show VEN_ID+DEV_ID of your graphics cards? I suspect that you and I simply have different versions of DG1:) And your is DEV_4905.

[Mark_L_Intel1]

Olek,

Thanks for the good knowledge of how firmware and driver works. I didn't touch this topic before so take me a while to find the INF file. I also realized this information is available under "detail" tab of display adaptors of Device Manager. I got the inf file name from here and find both TGL and DG1 inf file.

I have 2 inf:

The TGL inf:

; TGL
INTEL_DEV_9A49 = "Intel(R) Iris(R) Xe Graphics"   
INTEL_DEV_9A40 = "Intel(R) Iris(R) Xe Graphics"   
INTEL_DEV_9A59 = "Intel(R) UHD Graphics"   
INTEL_DEV_9A60 = "Intel(R) UHD Graphics"   
INTEL_DEV_9A68 = "Intel(R) UHD Graphics"   
INTEL_DEV_9A70 = "Intel(R) UHD Graphics"   
INTEL_DEV_9A78 = "Intel(R) UHD Graphics"   
INTEL_DEV_9AC9 = "Intel(R) UHD Graphics"   
INTEL_DEV_9AF8 = "Intel(R) UHD Graphics"   
INTEL_DEV_9AC0 = "Intel(R) UHD Graphics"   
INTEL_DEV_9AD9 = "Intel(R) UHD Graphics"  

Vender ID:

; DG1
%INTEL_DEV_4905% = iDG1D_w10_DS, PCI\VEN_8086&DEV_4905

; 13 DG1 TGL
%INTEL_DEV_4905% = iDG1D_w10_DS, PCI\VEN_8086&DEV_4905&SUBSYS_09DD1028

; 14 DG1 TGL
%INTEL_DEV_4905% = iDG1D_w10_DS, PCI\VEN_8086&DEV_4905&SUBSYS_0A051028

; 15 DG1 TGL
%INTEL_DEV_4905% = iDG1D_w10_DS, PCI\VEN_8086&DEV_4905&SUBSYS_09DE1028

; 17 DG1 TGL
%INTEL_DEV_4905% = iDG1D_w10_DS, PCI\VEN_8086&DEV_4905&SUBSYS_09DF1028

The DG1 inf:

; DG1
INTEL_DEV_4905 = "Intel(R) Iris(R) Xe MAX Graphics"   

Vender ID

; DG1
%INTEL_DEV_4905% = iDG1D_w10_DS, PCI\VEN_8086&DEV_4905

; 13 DG1 TGL
%INTEL_DEV_4905% = iDG1D_w10_DS, PCI\VEN_8086&DEV_4905&SUBSYS_09DD1028

; 14 DG1 TGL
%INTEL_DEV_4905% = iDG1D_w10_DS, PCI\VEN_8086&DEV_4905&SUBSYS_0A051028

; 15 DG1 TGL
%INTEL_DEV_4905% = iDG1D_w10_DS, PCI\VEN_8086&DEV_4905&SUBSYS_09DE1028

; 17 DG1 TGL
%INTEL_DEV_4905% = iDG1D_w10_DS, PCI\VEN_8086&DEV_4905&SUBSYS_09DF1028

As a general rule, you should first use vender to update system to make sure the correctness system-wise, then download from download center. I used Dell SupportAssist to update the system. I checked its history, it has BIOS updated at 7/6/2021(System BIOS 1.6.0) Not sure if this also updated the firmware related.

Mark

[OTorg]

Hi,
Is there any news on the issue under discussion?

[Mark_L_Intel1]

Hi Oleg,

Sorry I didn't get update from dev team yet. I hav asked them again.

The discussion we have is about the driver installation, I tried driver version 9466 and 9040 for DG1 but I can't reproduce your issue. Since we have different platform, I don't know the reason why your driver for DG1 is older than mine. Could you also install the same driver on your side and re-run the test?

Mark

[OTorg]

Hi Mark,

I can't understand your phrase "why your driver for DG1 is older than mine".

I can easily give you access to my system and you can run all the tests you need. RDP, AnyDesk, TeamViewer, UltraVNC - what suits you?

[Mark_L_Intel1]

Hi Olek,

My apology for not pay attention to your previous post, it has been a while and I was not quite following.

I was trying to make sure the driver version clarify while I am asking dev team to clarify your issue, but this was too much and caused confusion. It is more clear to me:

• Windows 10 64bit
• Hardware Supermicro X12SAE, i7-10700, ASUS DG1-4G.
• You have tried the driver: 9466, 9316, 9039 and 9667 on both iGPU an dGPU.
• Input is 8x(720x576i50, 4:2:0 NV12)

I will be more focus on how the dGPU is configured next. If you see this announcement, you should realize DeepLink takes important role in dGPU. This is the issue I am trying to clarify. Since DeepLink might imply the memory sharing mechanism.

Does this make sense to you? Let me know if you have other concerns in mind.

Mark

Mark

[OTorg]

Mark, your last replies make me think that you have little understanding of the current topic.

In addition, you are not making any real effort to move towards a solution, you are only coming up with ridiculous arguments to answer me at least something.

Сan you transfer control of the current issue to another technician?