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

  • .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

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 10
  • Comments: 41 (6 by maintainers)

Most upvoted comments

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?

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.

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

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

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.

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?

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.

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 😦

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

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.

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.

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;
	}

@apisarev Thank you. Fixed

@DavidGretzschel I have an i7-1165G7 too.

@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.

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.

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?

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

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.