Issue summary
We are developing a CAD application for Windows 10, using DirectX 11 for rendering. We encountered a problem with ID3D11DeviceContext::GenerateMips() when our app runs using the Intel Iris Xe GPU. The symptom is that mipmap level 2 (counting from 0) gets a blocky artifact. This is visible in the app (when rendering a face at a certain distance and angle from the camera) and also visible in frame captures (in Visual Studio Graphics Analyzer). See runtime_capture.mp4 (look at how the linear sampler interpolates between the 1st and 2nd level of Bottom slice as it rotates) and VSGA_mipmap_level2.mp4 for more.
The issue is stable and reproducible (although the blocky artifact does seem to be indeterministic) on Windows 10 and Intel Iris Xe GPU. The issue is not reproducible with the dedicated GPU of the same machine (NVIDIA T500), so we suspect it to be a bug in the Intel driver (not sure). I attach the details of my system in msinfo32_SystemSummary.png, msinfo32_Display.png, DxDiag.txt and a report from Intel SSU in Intel_SSU.txt.
Sample application
I also attach a sample program (MipmappingBugSample.zip) to demonstrate the issue. The project was created with Visual Studio 16.10.0 but any version of VS2019 should be able to open it. About the sample program:
It generates a mipmapped 2D texture array of 6 textures and renders them on the sides of a cube. The cube rotates around axis Z until the program terminates.
The program was based on the built-in Visual Studio 2019 template: DirectX 11 App (Universal Windows - C++/CX). See VS2019_proj_template.png.
In case you don't know the template: it renders a rotating cube with simple vertex coloring. I modified very few things:
- Replaced the vertex and pixel shaders with Content/textureVS.hlsl and Content/texturePS.hlsl
- Changed the cube mesh in Sample3DSceneRenderer by adding UV coordinates (I split the vertices because of different tex. coordinates for every cube face)
- Added 1 texture array and a shader resource view to Sample3DSceneRenderer (for texturing the cube).
- Added 6 binary files (Assets/decalX.texdata) containing the texture array slices' raw pixel data (256x256 resolution, 1 channel -> 64KB)
The program uses the default sampler states (thus the warning on the debug console) but that is fine. You can see the mipmapping issue instantly in the app and by doing a frame capture in Visual Studio (and inspecting the texture array).
I attach the list of DLLs loaded during running the sample program on my machine in VS2019_Modules_Window.csv (as shown by the 'Modules' window of VS2019).
Some further observations about the issue
- Reducing the texture size from 256x256 to 64x64 seemed to fix the issue. 128x128 is buggy too, so 64x64 is the max.
- Restricting mipmap levels to 4 (instead of all 9 possible levels) also fixed the issue
- Adding std::this_thread::sleep(2s) before/after GenerateMip doesn't help (not a timing issue probably)
- I have plenty of free memory during running the sample app and never touch the memory allocated for the texture resources (I know Intel Iris has a unified memory architecture) after/during mipmap generation
- It doesn't matter whether I create the ID3D11Device with or without debug flag
- The issue occurs with several pixel formats I tried: DXGI_FORMAT_R8_UNORM, DXGI_FORMAT_R8_SNORM, DXGI_FORMAT_R32_FLOAT, DXGI_FORMAT_R8G8B8A8_UNORM. Although the probability of observing the issue is much higher with DXGI_FORMAT_R8_UNORM
- The issue always occurs on mipmap level 2
Link Copied
I forgot to mention that even though my current driver version is 27.20.100.9510, I originally encountered the issue with version 27.20.100.9268. But then I updated in the hope of fixing the problem. Which didn't help.
By the way I went and checked the manufacturer's site (Lenovo) and the recommended driver version is what I have (27.20.100.9510):
