Incorrect values of disabled (const) attribute when drawing with drawArraysInstanced / drawArrays

• Component: WebGL
• Status: ASSIGNED ---

[Marcin]

Problem occurs on iOS 14.2, Safari 14, iPhone SE (2017)
It works perfectly on iMac(27" late 2013) Catalina 10.15.7, Safari 14.0

Using WebGL2 context, I have 3 attributes, 
2 are enabled and 1 is disabled in VAO.

#0 enabled  divisor = 1
#1 disabled divisor = 0
#2 enabled  divisor = 1

all other attributes are disabled and not used in shader program.


When drawing with drawArraysInstanced attribute #1 values, accessed in vertex shader, are invalid and vary. 
It should have a CONSTANT value set by ie: call to vertexAttrib4f().

Values of other two attributes (#0 and #2) are ok.

[Marcin]

More complete attributes description:

#0 size = 4, type UBYTE, stride = 6, offset = 0 (contains x1,y1,x2,y2 coordinates of rectangle)
#2 size = 2, type UBYTE, strand = 6, offset = 4 (contains texture coordinates of lower-left corner)

shader reconstructs vertex coordinates by testing gl_VertexID

actual draw call:

gl.drawArraysInstanced(gl.TRIANGLE_STRIP, 0, 4, number_of_rectangles_in_vbo);

[Alexey Proskuryakov]

Thank you for the report! Could you please attach a complete test case that demonstrates the problem?

Just to clarify, are you enabling WebGL 2.0 experimental feature in Safari for this work?

[Marcin]

It would be hard to prepare isolated reproducer for you from my current code, you know, engine, wasm, assets etc...

But if I find some spare time on weekend I'll try to code something in pure JS for you.

Yes, of course, in order to use WebGL2 I enabled it in experimental features.
And I'm patiently waiting for release with enabled WebGL2 by default. :)

[Kenneth Russell]

Several bugs have been fixed between the version of Safari you're testing and top-of-tree WebKit which probably affect these API calls. Please test on macOS with Safari Technology Preview 116, just released, which contains these bug fixes.

[Kenneth Russell]

Also, if you can provide any test case, perhaps dino or kkinnunen can confirm that it's working on top-of-tree on iOS.

[Marcin]

OK, looks like I have something.

https://asciicker.com/tests/test2.html

It should render color cycling squares.
On my iPhone all are simply white.

[Marcin]

Also, now I'm wondering what could cause such problem,
actual hardware, driver, ANGLE (I don't know if you use it) or the browser?

Are you aware of any method helping me to figure it out?

Thanks, 
Marcin.

[James Darpinian]

It works for me on the iOS simulator with WebKit built from source at HEAD. I don't have a way to test on real hardware, but I think it is likely to be something we already fixed since the Safari 14 branch.

[Marcin]

Yes, hopefully.
So if the test made in simulator using older branch is failing, that would confirm it is indeed solved, right?

Thanks

[James Darpinian]

Yes, I think that would confirm it. Thank you for testing early!

[Alexey Proskuryakov]

This still reproduces for me on device with a two week old WebKit (r269643). This could have been fixed since then, but probably worth another look.

[James Darpinian]

Hmm, perhaps it is hardware specific then. I just tried to do a MacCatalyst and/or iOS simulator build of WebKit on Apple Silicon but couldn't get it to work, likely due to not having access to internal SDKs. I think only Apple can test this right now, until WebKit's Apple Silicon builds are fixed to work without internal SDKs.

[Kenneth Russell]

Kimmo, could you help reproduce this on ToT WebKit on hardware? If there's a bug in ANGLE we'd love to resolve it as soon as possible. Thanks.

[Kimmo Kinnunen]

Thanks for the report!

The test case works in
ToT WebKit Mac
The test cas fails in
ToT WebKit iPhone 12 14.2
ToT WebKit iPhone 11 14.2
ToT WebKit iPhone 10 14.2

It's unclear if it worked on iOS 14.0/14.1

I can further try to reduce the test case.

It appears that when the value set by the vertexAttrib4f() is accessed in the fragment shader, the whole expression becomes 1.0.

[Marcin]

Thanks Kimmo!

I found some weird fix to the test case,
if you change attribute index (used by 'tex' attribute) from 4 to 2, (making no gaps in active attributes) everything starts to work!

lines: 10, 144,145,146

Hope that helps to narrow the thing.

[Kimmo Kinnunen]

> if you change attribute index (used by 'tex' attribute) from 4 to 2, (making no gaps in active attributes) everything starts to work!

Nice catch! This is especially surprising since 

Works:
        layout(location = 0) in vec4 rect;  // x1,y1,x2,y2
        layout(location = 1) in vec4 color; // r,g,b,a
        layout(location = 2) in vec4 tex;

Does not work:
        layout(location = 0) in vec4 rect;  // x1,y1,x2,y2
        layout(location = 2) in vec4 color; // r,g,b,a
        layout(location = 1) in vec4 tex;

E.g. no gaps, but if the constant attribute is the last one, it does not work.. or I made a typo

[Marcin]

Made same attrib index swizzling here (0,2,1), also fails! -- really strange.

[Kenneth Russell]

Great diagnosis Kimmo. Could you ask Apple's OpenGL ES on iOS team about this bug? It seems difficult or impossible to postulate a workaround in ANGLE for this driver bug. Reordering the declarations in the shader seems the only option, but it's unclear whether that would work, given the nature of this bug.

Raising to Major severity and blocking Bug 126404 on this one - an unknown number of WebGL 2.0 applications might be broken by this bug.

I wonder whether ANGLE's Metal backend already implicitly fixes this issue.

[Radar WebKit Bug Importer]

<rdar://problem/71747873>

[Marcin]

FYI, in effort to move away from instancedDraw calls (because of this issue and Issue 218949), I found out that same problem occurs with regular drawArrays as well. Changing attributes indexes (avoid gaps, keep last active attribute enabled) works around the problem so far, phew.

[Kenneth Russell]

Hopefully this will be automatically fixed with the new Metal backend for ANGLE - it should not be subject to this kind of OpenGL ES driver bug. Confirmation would be great, though.

[Marcin]

Confirmed - bug is fixed on iOS 15.3.1