That's distressing. Thanks for tracking this down. Olli, is there any chance you could help report this bug?

I reproduced this on Ubuntu 14.04 with 352.63 drivers. I'll need to take a closer look and pass this issue on to the driver team.

It would really help in these kinds of cases if we had some tooling to help converting WebGL call sequences to a native OpenGL test. Also, in cases which are not WebGL-specific it would be great if tests would be contributed to dEQP when we find holes in dEQP testing.

+1 for some assistance in making WebGL cases standalone.. I've had the same issue with ANGLE related bugs.

Filed https://github.com/KhronosGroup/WebGL/issues/1557 about this. I've personally hand-ported some WebGL tests into the dEQP and while it's not that difficult, completely automating the process will be hard. Best to do the key test cases by hand.

Ah we had the same issue with PACK_ROW_LENGTH with ReadPixels.

Interestingly I don't have this issue on my Linux NVIDIA (Quadro 600, 340.93 driver), that's why I didn't put in the workaround for UNPACK_ROW_LENGTH.

We should be able to work around this by breaking the tex calls into multiple TexSubImage calls, and the last one is only for the last row, where we could set the row length to width before the TexSubImage call and set it back after the call.

I ever did a workaround for texImage2D using TexSubImage call as zmo@ mentioned. It works well. We need several texSubImage calls for one texImage. It's a bit more complicated especially for texImage3D. Each depth should do workaround for 3D call. 

Per comment 7: why per slice for the 3D textures?  I thought only the last row of the last slice is affected.  All other slices are not affected.

qiankun: can you try and see if https://codereview.chromium.org/1838923002/ fixes the issue?  Unfortunately I can't reproduce it on my Linux NVIDIA.

zmo@, for 2D texture not only the last row of texture is affected, but also last 2nd row, last 3rd row and etc may be affected. How many rows are affected is calculated by trunc(width / UNPACK_ROW_LENGTH).  (width - UNPACK_ROW_LENGTH ) pixels are missing for the last row of a texture, (width - 2*UNPACK_ROW_LENGTH) pixels are missing for the last 2nd row, and etc. 

For 3D texture each slice is affected the same as a 2D texture. I attached logs with and without your patch. You can see clearly what the bug is.

Deleted: without-patch.txt 133 KB

without-patch.txt 133 KB View Download

Deleted: with-patch.txt 134 KB

with-patch.txt 134 KB View Download

You are right.  I see the pattern now.

I think we should put in a workaround for when (row_length > 0 && row_length < width).  Basically we just use a bunch of TexSubImage calls to fill the missing pixels.

qiankun: can you get a CL? I can't trigger it on my side, so it's less efficient for me to do it and ask you to test it.

I will be OOO next few days due holiday in China. Olli, do you have bandwidth to take a look at this bug? Since you also can reproduce it and you should be more familiar with nVidia graphics card and suitable to do it. 

I've started looking at this issue more and prototyping workarounds. The only workaround I've gotten working reliably so far without any crashing or missing pixels on a recent driver is splitting the texture upload from PBO row by row. However, since the workaround needs to be applied only when row_length < width, which is not a practical use case, slow performance with the workaround might be acceptable.

Agree that it'd be OK for the workaround to upload the texture line-by-line. The performance can be tuned later.

CC'ing ANGLE folks, since this will be an important driver bug workaround to pick up for ANGLE's OpenGL backend. Is there yet a mechanism for communicating driver bug workarounds into ANGLE from the outside? That could be used first, before the driver bug handling is moved entirely into ANGLE.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0a55756ea0c674213d6d137d26f5998a89c300ee

commit 0a55756ea0c674213d6d137d26f5998a89c300ee
Author: oetuaho <oetuaho@nvidia.com>
Date: Tue May 10 11:36:44 2016

Fix unpacking overlapping unpack buffer rows on NVIDIA GL

When unpack parameters are set so that the rows being read overlap in
the unpack buffer stored in GPU memory, NVIDIA GL driver may not
upload the last pixels of the last one or more rows of a texture. The
driver may also crash when the amount of overlap is high.

This issue affects both TexImage* and TexSubImage* calls.

Work around the issue by uploading textures row by row when the rows
being read overlap in the unpack buffer. The workaround could possibly
be optimized by uploading several of the first rows with a single call
in some cases where the amount of overlap is low, but this is expected
to be a rarely used corner case, so the added complexity that the
optimization would create seems like a bad tradeoff.

The issue does not seem to be triggered when the layers (images) of a
3D texture overlap, as long as rows inside the images don't.

BUG= 596774 
TEST=WebGL 2 conformance tests
     conformance2/textures/misc/tex-unpack-params.html
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/1963683002
Cr-Commit-Position: refs/heads/master@{#392581}

[modify] https://crrev.com/0a55756ea0c674213d6d137d26f5998a89c300ee/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py
[modify] https://crrev.com/0a55756ea0c674213d6d137d26f5998a89c300ee/gpu/command_buffer/service/texture_manager.cc
[modify] https://crrev.com/0a55756ea0c674213d6d137d26f5998a89c300ee/gpu/command_buffer/service/texture_manager.h
[modify] https://crrev.com/0a55756ea0c674213d6d137d26f5998a89c300ee/gpu/config/gpu_driver_bug_list_json.cc
[modify] https://crrev.com/0a55756ea0c674213d6d137d26f5998a89c300ee/gpu/config/gpu_driver_bug_workaround_type.h

Given that the workarounds is for all NVIDIA drivers, detection is trivial in ANGLE too and we don't need to do any message passing for that.

I did also file a driver bug, so eventually this may be made conditional based on driver version, but I agree that it's still simplest to just check the condition for the workaround inside ANGLE.

Great. Thanks Olli for the workaround and for filing the bug. Is it correct to mark this fixed?

Ah, I see from https://codereview.chromium.org/1963683002/ that the test is still failing on some platforms. Marking Started for the moment.

I think I did fix the bug that the original bug description was about, the remaining issues are not caused by the NVIDIA GL driver. But I should still do at least the fix inside ANGLE.

OK. Thanks Olli. Let's close this then. Could you file a follow-on bug against the ANGLE project for adding the workaround there?

Filed https://bugs.chromium.org/p/angleproject/issues/detail?id=1376 to track this in ANGLE.