Bug 219204 - Incorrect values of disabled (const) attribute when drawing with drawArraysInstanced
Summary: Incorrect values of disabled (const) attribute when drawing with drawArraysIn...
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebGL (show other bugs)
Version: Safari 14
Hardware: iPhone / iPad iOS 13
: P2 Major
Assignee: Kimmo Kinnunen
Keywords: InRadar
Depends on:
Blocks: 126404
  Show dependency treegraph
Reported: 2020-11-20 07:29 PST by Marcin
Modified: 2020-11-26 03:29 PST (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Marcin 2020-11-20 07:29:48 PST
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.
Comment 1 Marcin 2020-11-20 07:43:11 PST
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);
Comment 2 Alexey Proskuryakov 2020-11-20 09:37:11 PST
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?
Comment 3 Marcin 2020-11-20 09:53:07 PST
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. :)
Comment 4 Kenneth Russell 2020-11-20 15:49:50 PST
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.
Comment 5 Kenneth Russell 2020-11-20 15:54:08 PST
Also, if you can provide any test case, perhaps dino or kkinnunen can confirm that it's working on top-of-tree on iOS.
Comment 6 Marcin 2020-11-23 00:56:49 PST
OK, looks like I have something.


It should render color cycling squares.
On my iPhone all are simply white.
Comment 7 Marcin 2020-11-23 02:05:15 PST
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?

Comment 8 James Darpinian 2020-11-23 09:54:00 PST
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.
Comment 9 Marcin 2020-11-23 10:04:26 PST
Yes, hopefully.
So if the test made in simulator using older branch is failing, that would confirm it is indeed solved, right?

Comment 10 James Darpinian 2020-11-23 10:05:37 PST
Yes, I think that would confirm it. Thank you for testing early!
Comment 11 Alexey Proskuryakov 2020-11-23 11:26:25 PST
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.
Comment 12 James Darpinian 2020-11-23 12:31:19 PST
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.
Comment 13 Kenneth Russell 2020-11-23 16:52:10 PST
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.
Comment 14 Kimmo Kinnunen 2020-11-24 05:02:59 PST
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.
Comment 15 Marcin 2020-11-24 05:24:23 PST
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.
Comment 16 Kimmo Kinnunen 2020-11-24 05:37:21 PST
> 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 

        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
Comment 17 Marcin 2020-11-24 05:47:46 PST
Made same attrib index swizzling here (0,2,1), also fails! -- really strange.
Comment 18 Kenneth Russell 2020-11-24 12:28:39 PST
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.
Comment 19 Radar WebKit Bug Importer 2020-11-26 03:29:23 PST