WPF - cannot redraw page on Intel 11th Core Iris Xe Integration graphic card

[LMing123]

• .NET Core Version: 3.1
• Windows version: (Windows 10 20H2)
• Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes

Problem description:
I use CefSharp with WPF on Intel 11th Core Iris Xe Integration graphic card, it can't redraw content. but when I closed WPF hardware acceleration, it can work normally.

Actual behavior:
open acceleration then CefSharp can't redraw content.

Expected behavior:
open acceleration, CefSharp can redraw content normally

Minimal repro:
the step for repeat problem can see from this Issues CefSharp

[lindexi]

Looks like this is Intel's bug

[LMing123]

Looks like this is Intel's bug

maybe, same build were tested on other platform, for example: Intel 10th Core CPU and 9th Core CPU, it work perfect.

[ryalanms]

Hi @LMing123. Thank you for the report. This is not something that can be fixed in WPF.

[LMing123]

Hi @LMing123. Thank you for the report. This is not something that can be fixed in WPF.

I have a question that who should be fix this problem?

[vatsan-madhavan]

This is not something that can be fixed in WPF.

Assuming this bug-report is valid (I'm a bit skeptical about these sorts of reports since often the problem is in a driver and not the hardware/processor etc.)...

• Are you sure that none of the processor-intrinsics or assembly code in WPF is implicated in this problem (WPF has some), for example ?
• .Are you sure that the compiler you are using to build WPF is not at fault ?
  • We have seen problems like this (recently, as in within the last year or so) wherein our compilers have produced processor-specific code that was bad and upgrading the toolset fixed the problem (a newer compiler already had the fix). The history I'm thinking of had nothing to do with drawing (it was a crash) but nevertheless the general point is that compilers produce processor-specific code and WPF has a native-renderer that relies on a C++ compiler.

If one of those is the case, then only WPF can this remedy this problem. A (true) processor-specific bug - esp. one that affects a new CPU/GPU architecture as a class and .NET Core 3.1 (which suggests that it would likely affect .NET 5 as well) - ought to be treated as a bad problem and fixed as quickly as you can. Please consider investigating this further. Since this affects .NET Framework, clearly this also affects Windows 10 and Surface devices...

If this is a driver problem that's common to 11th gen Intel chipset's integrated GPU, I'm sure we have the ability to reach out to them through internal channels and work with them to fix their drivers so that hardware-accelerated rendering works as expected.

/cc @SamBent

[tibor-synergy]

Any news here?

I believe that there is some kind of issue with Xe GPUs and WPF rendering, as we have a report of video not playing in one of our apps on a Xe GPU. I currently don't have access to a machine to test, but we use a WriteableBitmap, where we update the image by copying memory into its BackBuffer. Basically for each video frame we're drawing, we do:

b.Lock();
NativeMethods.CopyMemory(b.BackBuffer, buffer, bufferLength); // (win32 api CopyMemory)
b.AddDirtyRect(rect);
b.Unlock();

The outcome is that the first image renders successfully, but subsequent ones don't.

I may be able to provide more information and a minimal sample if I manage to gain access to such a machine and can find what exactly is causing the issue.

We also draw this from a separate Dispatcher running on its own thread (as in https://dwayneneed.github.io/wpf/2007/04/26/multithreaded-ui-hostvisual.html), but that could be unrelated.

The app is .NET 4.6.1.

Update: as expected, turning off HW acceleration for WPF through the Windows registry fixes the issue, but is not ideal.

[amaitland]

CefSharp uses a WriteableBitmap when the DPI is greater than 100% and InteropBitmap for DPI of 100%. Not sure which implementation was used when @LMing123 experienced problems. Likely also using Writablebitmap. CefSharp uses the default dispatcher. I don't have access to hardware modern enough to reproduce this.

The https://github.com/cefsharp/CefSharp.MinimalExample project includes a simple WPF project that should reproduce the problem using CefSharp. If you use the CefSharp.MinimalExample.sln then perform a Nuget restore before opening in visual studio or perform a Nuget restore in visual studio then close and reopen the solution (it used to restore correctly in vs2013/2015, changes in visual studio make this a nessicary step, at least for now).

Does the .Net Core implementation of WPF differ enough to warrant testing to see if this reproduces?

[amaitland]

It's possible this reproduces with InteropBitmap and WritableBitmap. Second report of this issue in the context of CefSharp cefsharp/CefSharp#3300 (comment)

[LMing123]

CefSharp uses a WriteableBitmap when the DPI is greater than 100% and InteropBitmap for DPI of 100%. Not sure which implementation was used when @LMing123 experienced problems. Likely also using Writablebitmap. CefSharp uses the default dispatcher. I don't have access to hardware modern enough to reproduce this.

The https://github.com/cefsharp/CefSharp.MinimalExample project includes a simple WPF project that should reproduce the problem using CefSharp. If you use the CefSharp.MinimalExample.sln then perform a Nuget restore before opening in visual studio or perform a Nuget restore in visual studio then close and reopen the solution (it used to restore correctly in vs2013/2015, changes in visual studio make this a nessicary step, at least for now).

Does the .Net Core implementation of WPF differ enough to warrant testing to see if this reproduces?

The DPI I tested on 100% and 150%, it both have same problem. I also tested on dotnet core WPF, which same thing happened again. this test I used CefSharp.MinimalExample and default dispatcher.

By the way, when I continuously resize application window, the content rendering becomes normal.

[kkwpsv]

I confirmed that a .net45 app (CefSharp.WPF) with WriteableBitmap has this issues.
The device is Dell Vostro 5301 with Iris Xe and NVIDIA MX350 graphic card. And the .net runtime is .net48 from Windows 10 2004.
Using NVIDIA graphic card in NVIDIA Control Panel or using software rendering in WPF can solve this.

And when resizing, it'll render the previous frame. So it'll seem to be normal when continously resizing.

[kkwpsv]

Any updates for this issue?

[LMing123]

Any updates for this issue?

there no any news , bugs still happily living.

[amaitland]

If this is a driver problem that's common to 11th gen Intel chipset's integrated GPU, I'm sure we have the ability to reach out to them through internal channels and work with them to fix their drivers so that hardware-accelerated rendering works as expected.

Is someone able to reach out to someone from Intel and get the ball rolling on fixing this issue? Or provide a suggestion on how we might contact Intel directly?

[ltetak]

Does recreating a new WriteableBitmap for every frame fix this for you?

[lindexi]

Does recreating a new WriteableBitmap for every frame fix this for you?

Yes. But if I do, my program will perform very low. Because before I only had to update dirty areas every time, but now I have to update the whole picture.

[HarlanHugh]

I acquired a machine to try and fix this issue for users of our application. I discovered that it happens even with Microsoft's example for WriteableBitmap, an extremely rudimentary drawing application. It does almost nothing when running on the Iris Xe. https://docs.microsoft.com/en-us/dotnet/api/system.windows.media.imaging.writeablebitmap?view=net-5.0

In our application we use SkiaSharp for rendering and it only draws the first frame. Subsequent updates do not appear unless a resize occurs. Tweaking SkiaSharp to use a new WriteableBitmap for every paint "fixes" the issue but causes massive memory and performance issues.

[hengway]

@HarlanHugh Hi, I face similar issue like yours, but mine one is video player, it always stuck at first frame. I did found asolution to solve this issue by change the WPF render mode to software only.

Do you have way to detect this issue when it happen? Because from my site, when this issue happen, it seem like not error been trigger. My plan is add condition to the application, if detect this issue then change the render mode to software only on the run time. But now stucked on capturing the issue by programming way.

[HarlanHugh]

@hengway no, unfortunately I don't know how to easily detect it. We added a preference to let people disable hardware rendering via a checkbox. I thought about trying to capture the screen after a second update to check the pixels and see if the changes were output but I haven't done this as of yet. Pretty sure it would work but I don't have time to do it right now and I'm hoping Intel fixes the problem soon.

[hengway]

@HarlanHugh actually we doing what you think of now, will update the bitmap, and perform screenshot and compare. Just it will be tedious and possible lead to bug if implement not well. But just hope intel will doing something to fix this issue, is ridiculous for this kind of bug to be happen.

[amaitland]

@hengway @HarlanHugh Have you considered querying windows say via WMI to determine the active video card? As this issue is hardware specific perhaps you can determine the video card programatically and set software rendering.

https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-videocontroller
https://stackoverflow.com/a/37524511/4583726 (Someone will need to test if this works)

[tibor-synergy]

I tried what @HarlanHugh suggested, reading back from the screen. I used Graphics.CopyFromScreen and it seems to work: when I draw green, then red, then CopyFromScreen, I read green on an affected machine while I read red on a non-affected machine.

The issues I have are:

• The pixels read from the screen are slightly different (in their RGB values) than what I drew, so I use the condition pixel.R > pixel.G instead of comparing the exact values.

• I'm not sure how to tell with certainty that what I drew has actually been drawn and will be returned by CopyFromScreen (perhaps waiting on CompositionTarget.Rendering would work but haven't tried it yet and I doubt it's a reliable method). Anyway, what I did was just wait 100 ms after drawing, but before invoking CopyFromScreen, and this works, but is pretty hacky and likely not 100% reliable.

The workaround we use for the rendering issue itself is just recreating the WriteableBitmap on every frame. This has a significant CPU usage impact with multiple bitmaps updated many times per second, but it's the most performant solution I've found so far.

Either way, it would be really nice if this was fixed at the source of the problem so we don't need to do this kind of stuff.

[kkwpsv]

@HarlanHugh Hi, I face similar issue like yours, but mine one is video player, it always stuck at first frame. I did found asolution to solve this issue by change the WPF render mode to software only.

Do you have way to detect this issue when it happen? Because from my site, when this issue happen, it seem like not error been trigger. My plan is add condition to the application, if detect this issue then change the render mode to software only on the run time. But now stucked on capturing the issue by programming way.

I use SetupDiEnumDeviceInfo and SetupDiGetDeviceInstanceId to get pid and vid for the graphic card. And check if the graphic card is Intel(R) Iris(R) Xe Graphics. It's faster than WMI. But in the case of multiple graphics cards, it may not be accurate enough.

[HarlanHugh]

The reason I don't think detecting the graphics card is the right approach is that if (hopefully when) this issue is fixed you will still be using software rendering unnecessarily.

[hengway]

actually I am considering to make the application permenently render in software only, because from MS documentation https://docs.microsoft.com/en-us/dotnet/api/system.windows.media.renderoptions.processrendermode?view=net-5.0, it look like encourage us to run WPF on software only, but I not sure why default is hardware first. I did get my team to test run the application on an intel core 2 dua cpu, so far it can run smoothly. but for graphic intensive application may cause performance issue.

[carwyn]

I've tried the latest Intel Xe driver version 27.20.100.9168 (date 8/1/2021) on a Dell 9310 XPS 13 and it's still there :-(

[DavidGretzschel]

If this is a driver problem that's common to 11th gen Intel chipset's integrated GPU, I'm sure we have the ability to reach out to them through internal channels and work with them to fix their drivers so that hardware-accelerated rendering works as expected.

Could this be an issue, that's specific to exactly the "i7-1165G7"-processor instead of the whole 11th gen of Intel CPUs?
On the TB-forum all three who have so far encountered the issue, have that exact model.
https://forums.thebrain.com/post/more-on-the-xe-igpu-problem-thinkpad-14s-with-i71165g7-performance-notes-11421653?pid=1322762396&highlight=hardware+acceleration
@kkwpsv
You have a Dell Vostro 5301, which also uses that one, too.
@ocardoso over in cefsharp/CefSharp#3300 links to an hp envy x360 with that processor:
cefsharp/CefSharp#3300 (comment)

So far I have seen 5 times the same model and no other 11th-gen.
Do we have a counterexample to that rule, anywhere?

@carwyn Could you tell me what CPU you have?
From "Dell 9310 XPS 13" it could be an i5-1135G7, i7-1185G7 or like everyone else so far [unless I missed a report]: an i7-1165G7.

If we only have reports of the i7-1165G7, someone could test literally any other CPU of that gen and we'd quickly know, whether it's model-specific or gen-specific.

[carwyn]

@DavidGretzschel I have an i7-1165G7 too.

[hengway]

@DavidGretzschel The issue happen to my intel i5-1135G7. Should not be only i7-1165G7

[DavidGretzschel]

oh well, was worth looking into Am Mi., 3. März 2021 um 13:40 Uhr schrieb hengway <[email protected]

…

: @DavidGretzschel <https://github.com/DavidGretzschel> The issue happen to my intel i5-1135G7. Should not be only i7-1165G7 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3817 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFVBKOKH34PKGZ2YFIFWVWLTBYU2VANCNFSM4TWIEW3Q> .

[DavidGretzschel]

Reported this to Lenovo, who told me to send it to Intel as well.
So I tried with the latest DHC-driver: 27.20.100.9316
And that didn't help either.
So I made an Intel Support Account and created a case, with video documentation and replication steps.
Was not that difficult to do, actually.

So hopefully this will be addressed soon.

[polipo]

Hi, any news from Intel?
or someone have found a programmatically solution for determine if HOST use "Intel Iris graphic integration card" for manage via software the enable o disable ProcessRenderMode = RenderMode.SoftwareOnly or Default?
Thanks

[HarlanHugh]

I found this documented on an official Intel site finally:

https://community.intel.com/t5/Graphics/Iris-Xe-and-AWS-Workspaces/td-p/1244351

Intel's bug #14013495876. The latest update from an Intel rep:

RonaldM_Intel
Moderator

‎03-10-2021 05:30 AM
125 Views
Hi everyone,

The latest news on bug ID# 14013495876 is that our driver dev team was able to replicate the issue and it is now under debugging process.

As soon as there is further updates I'll update this thread.

Regards,

Ronald M.

[apisarev]

According to Intel, the fix is included in the drivers version 27.20.100.9616
https://www.intel.com/content/www/us/en/support/articles/000058136/graphics/graphics-for-11th-generation-intel-processors.html

The ETA is June 9th
https://community.intel.com/t5/Graphics/Iris-Xe-and-AWS-Workspaces/m-p/1283236#M97290

Beta version is already available
https://downloadcenter.intel.com/product/80939/Graphics

Did someone already try the beta version? Did it fix the bug?

[kkwpsv]

I tested the drivers version 27.20.100.9616.
The issue has been fixed.

[lindexi]

@apisarev Thank you. Fixed

[DakotahVoet]

Just installed the 30.0.10.9667 drivers from 6/8/2021 and it appears to have been fixed. Running an 1165G7

[sfiruch]

Here's a snippet to work around the bug:

//work around a bug in old intel drivers: https://www.intel.com/content/www/us/en/support/articles/000058136/graphics/graphics-for-11th-generation-intel-processors.html
foreach (ManagementObject video in new ManagementObjectSearcher(new SelectQuery("Win32_VideoController")).Get())
	if ((string)video["Name"] == "Intel(R) Iris(R) Xe Graphics" && string.CompareOrdinal((string)video["DriverVersion"], "30.0.100.9667") <= 0)
	{
		System.Windows.Media.RenderOptions.ProcessRenderMode = System.Windows.Interop.RenderMode.SoftwareOnly;
		break;
	}

[lindexi]

@deiruch How about SetupDiGetClassDevsW function (setupapi.h) - Win32 apps

[ansolis]

I have a Surface Pro 8 with 11th gen Intel i7-1185G7, and it had an issue running a WPF application (Amazon Chime) until I disabled HW acceleration. It looked like only the first frame in the video stream was getting rendered. Looks like Intel is aware of the issue: https://www.intel.com/content/www/us/en/support/articles/000058136/graphics/graphics-for-11th-generation-intel-processors.html . Looks like Iris Xe Graphics driver version 30 or higher is required, but I only have version 27 on my machine, and automatic updates are not installing anything newer :(

[HknCore]

Just installed 30.0.101.1404 drivers from 3/8/2022 and it looks like the issue has appeared again. Running on Intel i5-1135G7.
Everything has been fine with 27.20.100.9616 before.

[kkwpsv]

Just installed 30.0.101.1404 drivers from 3/8/2022 and it looks like the issue has appeared again. Running on Intel i5-1135G7. Everything has been fine with 27.20.100.9616 before.

I tested again with Intel i5-1135G7 and 30.0.101.1404 drivers. The issue didn't appear.