search

dotnet / wpf

WPF is a .NET Core UI framework for building Windows desktop applications.
MIT License
7.03k stars 1.17k forks source link

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

Closed LMing123 closed 3 years ago

LMing123 commented 3 years ago
lindexi commented 3 years ago

Looks like this is Intel's bug

LMing123 commented 3 years ago

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 commented 3 years ago

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

LMing123 commented 3 years ago

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 commented 3 years ago

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

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

It's possible this reproduces with InteropBitmap and WritableBitmap. Second report of this issue in the context of CefSharp https://github.com/cefsharp/CefSharp/issues/3300#issuecomment-739006981

LMing123 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Any updates for this issue?

LMing123 commented 3 years ago

Any updates for this issue?

there no any news , bugs still happily living.

amaitland commented 3 years ago

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 commented 3 years ago

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

lindexi commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 https://github.com/cefsharp/CefSharp/issues/3300 links to an hp envy x360 with that processor: https://github.com/cefsharp/CefSharp/issues/3300#issuecomment-739006345

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 commented 3 years ago

@DavidGretzschel I have an i7-1165G7 too.

hengway commented 3 years ago

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

DavidGretzschel commented 3 years ago

oh well, was worth looking into

Am Mi., 3. März 2021 um 13:40 Uhr schrieb hengway <notifications@github.com

:

@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 https://github.com/dotnet/wpf/issues/3817#issuecomment-789686434, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFVBKOKH34PKGZ2YFIFWVWLTBYU2VANCNFSM4TWIEW3Q .

DavidGretzschel commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

lindexi commented 3 years ago

@apisarev Thank you. Fixed

DakotahVoet commented 3 years ago

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

sfiruch commented 2 years ago

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 commented 2 years ago

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

ansolis commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.