Intel HD 620 corrupt texture readback with glGetTexImage

[Dyami_C_]

Our software uses glGetTexImage to read back a simple 2D texture and save it to disk.

We have been using this technique for several years with no problem.

Recently, two different users with new computers have reported crazy artifacts on the images we save with this technique. In both cases, the users had Intel HD 620 graphics cards. One user took his computer back, got a different computer with the HD 620 card, and experienced the same issue. So we've seen the problem on three different machines.

I'm attaching an image that was read with glGetTexImage. When the texture was originally drawn on the screen, there were no artifacts. They are only introduced during the readback.

Steps to Reproduce:
---------------------------

1. Upload a valid 2D texture to the Intel HD 620 via OpenGL.
2. Read back the texture with glGetTexImage

Expected Results:
----------------------------
The texture data read back should be the same as the texture data sent to the graphics card.

Actual Results:
----------------------------
The texture data is corrupted, with lots of light-blue blocks in place of most of the expected image.

Here is the machine information:

Windows 10
Manufacturer = HP
Model = HP Notebook
SystemType = x64-based PC
NumberOfProcessors = 1
CPU = Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
Driver Vendor   = Intel
Driver Renderer = Intel(R) HD Graphics 620
Driver Version  = 4.4.0 - Build 21.20.16.4471

And another one:

Windows 10
Manufacturer = Acer
Model = Aspire E5-575
SystemType = x64-based PC
NumberOfProcessors = 1

CPU = Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz
Driver Vendor   = Intel
Driver Renderer = Intel(R) HD Graphics 620
Driver Version  = 4.4.0 - Build 21.20.16.4526

---

Our code to read from the texture is:

// texture context is current

glBindTexture(GL_TEXTURE_2D, textureId);

glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, GL_TEXTURE_WIDTH, &w);
glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, GL_TEXTURE_HEIGHT, &h);

if (w > 0 && h > 0)
{
  // allocate buffer == w * h * 4 bytes
  f->glGetTexImage(GL_TEXTURE_2D, 0, GL_BGRA_EXT, Z_TEXTURE_DATATYPE, (void*)buffer);
}

[Michael_C_Intel2]

Hi, Dyami,

I have filed the issues and will get the driver team to investigate. I will update you once we know something.

-Michael 

[Dyami_C_]

The line that reads the texture should be:

glGetTexImage(GL_TEXTURE_2D, 0, GL_BGRA_EXT, GL_UNSIGNED_INT_8_8_8_8_REV, (void*)buffer);

[Dyami_C_]

We have seen this again, this time with the HD 530 running on Windows 8.

Windows 8
Manufacturer = CyberpowerPC
Model = TRACER Series
SystemType = x64-based PC
NumberOfProcessors = 1
CPU = Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz

Driver Vendor   = Intel
Driver Renderer = Intel(R) HD Graphics 530
Driver Version  = 4.4.0 - Build 21.20.16.4542

Is there any news on this? I can provide a license to our software for testing if you would like it?

[Dyami_C_]

I have been able to duplicate this locally on a machine with the HD 520.

It appears to be an issue with the 7th generation driver "15.45/21.20" versions.

It is not fixed in the current beta (21.20.16.4552).

It only occurs with "GL_UNSIGNED_INT_8_8_8_8_REV" and only on 32-bit applications.

Changing the pixel type for the returned data to GL_UNSIGNED_BYTE resolves the issue.

[Dennis_L_]

We have the same issue with our software with glGetTexImage.
Current driver for HD 520 Intel graphics and all tested drivers by us for 7th generation have this issue.

We does not the occured this issue on Nvidia and AMD graphics cards.

GPU info:
Session type     : local
Profile          : Shader base
Vendor           : Intel
Renderer         : Intel(R) HD Graphics 620
API version      : OpenGL 4.4.0 - Build 21.20.16.4627
Driver version   :
Max texture      : 16384
Vertex cache size: 73
Available memsize: 1024 MB

Is there a chance for a bugfix for the next driver version?

[#7]

We have been seeing this issue for a little while now on all of our NUCs with Iris Pro 580.

>> We have found that 15.40.4539 (Beta) are WORKING and do not exhibit these artifacts. <<

While using some older and some newer drivers do show the corruption.

I've just tested using 15.45.16.4627, and simply using Apitrace and double clicking on a command that has a depth buffer bound will show the issue. I'm guessing apitrace gets the content of the buffers using a read pixel or getTexImage, as clicking multiple times on the same frame will show different corruption in the depth buffer surface, all my other framebuffers and textures were ok, though. Only my GL_DEPTH_ATTACHMENT was corrupted. (I tried both with stencil 24_8 and simply depth 24. Unlike Dyami, I see this on 64 bit applications)

[Guillaume_A_1]

I think the problem really is with GL_UNSIGNED_INT_8_8_8_8_REV.

A PBO transfer with glReadPixels GL_UNSIGNED_INT_8_8_8_8_REV, causes artifacts, while GL_UNSIGNED_INT_8_8_8_8 with manual byte flipping to get the correct output format does not cause any corruption. And indeed, using 15.40.4539 with the same code using _REV works.

Operating System: Windows 10 Pro 64-bit (10.0, Build 14393) (14393.rs1_release_sec.170327-1835)

BIOS: KYSKLi70.86A.0041.2016.0817.1130
Processor: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz (8 CPUs), ~2.6GHz
Card name: Intel(R) Iris(TM) Pro Graphics 580
Driver File Version: 21.20.0016.4627 (English)
Driver Version: 21.20.16.4627