Skylake opengl texture uploaded if RGB texture width >16384 bytes (and not px)

[Marco_v_]

I have a (delphi) opengl unittest that uploads textures to opengl (PBO via glmapbuffer). I noticed that uploading "wide" RGB textures  on more recent intel GPUs are corrupted, while my Intel reference machine (i5-2500) didn't have this problem.

I found the tilting point seems to be near 5460px wide, which is remarkable since .times 3 bytes/pixel = 16380....  I tried to do the same vertically, and that was no problem. (5460x7000px vertical ok,  5468xanything goes wrong)

So it seems max texture size in pixels and bytes are mixed up, or am I misunderstanding the meaning of texture limits?

Note that the reference (sandy bridge) machine is still at win8.1pro 64-bit

CPU SKU: G4400  (LGA 1151)
GPU SKU: HD 510
Processor Line: G
System BIOS Version:-
CMOS settings: -
Graphics Driver Version: 20.19.15.4300
GOP/VBIOS Version:
Operating System: Windows 10pro 64-bit
OS Version: Windows 10pro 64-bit
API: OpenGL (3.0 contexts, core profile)
Occurs on non-Intel GPUs?:No, and neither on older Intels.

(All used Windows versions are 64-bit)

OK non intel:  various systems with AMD HD5450 and one with HD7850 nvidia 9600GT. All Win8.1pro 64-bit, except AMD 5450 also tested with win7

OK Intel :  Sandy Bridge i5-5460 with windows 8.1pro.  Ivy Bridge  i3-3230T with windows 7. 

Fail Intel : G4400 (see above), and a friend reported that his Haswell i5-4210U HD4400 drv 10.18.14.4264  laptop with win v8.1, failed too, but I couldn't  verify that myself. 

The fail behaviour is different, Haswell seems to blacken the screen, skylake draws vertical bars in 4 different colors, but this differing behaviour could be the different driver due to windows version (10 vs 8.1)

I uploaded a test app to http://www.stack.nl/~marcov/glbug.zip ; (exe + original image).

Some relevant code excerpts for the uploading:

    glActiveTexture (GL_TEXTURE0);
    glGenBuffers(1, @fpboid);
    glBindBuffer(GL_PIXEL_UNPACK_BUFFER, fpboId);
    glBufferData(GL_PIXEL_UNPACK_BUFFER, texturesize, 0, GL_STREAM_DRAW);
    glBindBuffer(GL_PIXEL_UNPACK_BUFFER, 0);
 

    glBindBuffer(GL_PIXEL_UNPACK_BUFFER,fPBOid);
    glBufferData(GL_PIXEL_UNPACK_BUFFER, texturesize, 0, GL_STREAM_DRAW);
    pb:=glMapBuffer(GL_PIXEL_UNPACK_BUFFER, GL_WRITE_ONLY);
    move (pbyte(pixels)^,pb^,texturesizeinbytes);
    glUnmapBuffer(GL_PIXEL_UNPACK_BUFFER); // release pointer to mapping buffer
    glBindTexture(TEXTURETYPE, atexture);

    // first time glteximage, else subimage
    glTexImage2D(TEXTURETYPE, 0, GL_rgb, SizeX, SizeY, 0,
                     GL_BGR, GL_UNSIGNED_BYTE, 0);

or
    glTexSubImage2D(GL_TEXTURE_2D, 0, 0,SizeX, SizeY, 0,
                   GL_BGR, GL_UNSIGNED_BYTE, 0);

P.s. add Delphi to "Programming Language"

[Michael_C_Intel2]

Hi Marco,

I have passed this along to our driver team to investigate.

-Michael

[Marco_v_]

Thanks, one mistake to correct:

>OK Intel :  Sandy Bridge i5-5460 with windows 8.1pro.

I don't know where that 5460 came from, obviously this should be the earlier mentioned i5-2500 (non K)

[Michael_C_Intel2]

We are still investigating the issue, should have an update soon.

-Michael

[Marco_v_]

Any update on this?

[Michael_C_Intel2]

Hi Marco,

Yes there is, we have found the root cause and and working on implementing a fix. The fix is taking some time but we hope to have it in done soon. 

-Michael 

[Marco_v_]

According to my logs the issue is now an year old. Any update? 

[Marco_v_]

Lately we have received a customer complaint, which reminded us to a former complaint of almost 2 years ago.
This inspired us to do a little research again, but now with most recent graphics drivers.

1. All setups use Windows10 64bit creators update OS
2. We just run the glbug.exe binary and observe weather the cat picture (ok) or vertical colored bars picture (not ok) is displayed.

Result    Brand (CPU type)        GPU        Driver version
ok    AMD                hd5450        15.201.1151.1008
ok    Nvidia                9600M GS    21.21.13.4201
ok    Nvidia                gt710        22.21.13.8528
ok    Nvidia                gt720m        22.21.13.8528
ok    Intel (N2830-Bay trail)        hd graphics    10.18.10.4653
ok    Intel (I3-3217U-Ivy bridge)    hd4000        10.18.10.4653
ok    Intel (I3-3220T-Ivy bridge)    hd2500        10.18.10.4653
ok    Intel (I5-2500-Sandy bridge)    hd2000        9.17.10.4229

not ok    Intel (I3-7100-Kaby lake)    hd630        22.20.16.4729 and .4771
not ok    Intel (G4400-Skylake)        hd510        22.20.16.4729
not ok    Intel (I5-4210U-Haswell)    hd4400        20.19.15.4703

So from Haswell on, all modern Intel platforms seem to be affected (We haven't tested Broadwell and Coffee-Lake!)
In case of desktops we advise the customer to use a discrete graphics adapter. This is however not so easy when notebooks are involved.

Any updates?

[Gavrilov__Kirill]

This issue affects more users - so the bug fix is expected!

Applications based on Open CASCADE Technology suffer from this bug while making 3D viewer screenshots of big size (e.g. for printing or other purposes) on Intel HD Graphics 530, HD Graphics 4000 and HD Graphics 4600:
https://tracker.dev.opencascade.org/view.php?id=29020

OpenGL info:
  GLvendor: Intel
  GLdevice: Intel(R) HD Graphics 530
  GLversion: 4.5.0 - Build 22.20.16.4729
  GLSLversion: 4.50 - Build 22.20.16.4729
  Max texture size: 16384

The image dump 5461x100 produces correct image, while the dumps of 5462x100 or greater width are completely black without any OpenGL errors or explanation.

pload VISUALIZATION MODELING
box b 1 1 1
vgldebug 1
vcaps -core
vclear
vinit View1
vglinfo
vtop
vdisplay -dispMode 1 b
vfit
vdump i5_1.bmp -width 5461 -height 100
vdump i5_2.bmp -width 5462 -height 100