New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 626431 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Aug 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Blocking:
issue 622958
issue 628954



Sign in to add a comment

contextProvider->grContext() is null in conformance2 test

Project Member Reported by xidac...@chromium.org, Jul 7 2016

Issue description

In the WebGLRenderingContextBase class's contructor, I inject the following printf:

if (contextProvider->grContext())
    fprintf(stderr, "this grContext is not null\n");
else
    fprintf(stderr, "this grContext is null\n");

What I found is that running WebGL1 conformance test, it says grContext is not null, but running WebGL2 conformance test, it says grContext is null.
 

Comment 1 by kbr@chromium.org, Jul 7 2016

Cc: junov@chromium.org bsalomon@chromium.org
Components: Internals>Skia
Perhaps Ganesh isn't initializing correctly when the context is OpenGL ES 3.0 rather than 2.0.

Blocking: 622958
Yes, this needs file will need to be updated: https://cs.chromium.org/chromium/src/gpu/skia_bindings/gl_bindings_skia_cmd_buffer.cc
Blocking: 628954

Comment 5 by zmo@chromium.org, Jul 18 2016

Labels: -Pri-3 Pri-1
Raise to 1 because this is blocking WebGL2 being fully conformant on any platforms, and we are planning to push to at least conformant on Linux NVidia before Siggraph (this weekend).  Brian, can you take a shot at this?

Comment 6 by bsalo...@google.com, Jul 18 2016

Owner: bsalomon@chromium.org
Status: Started (was: Untriaged)
Yep, looking at it.

Comment 7 by bsalo...@google.com, Jul 18 2016

We've got a bit of a problem here. GLES2Interface is reporting a version of ES 3.0 but it doesn't actually have ES 3.0 support. It is missing at least the following APIs:

glVertexAttribDivisor
glFlushMappedBufferRange
glDrawArraysInstanced
glDrawElementesInstanced

Comment 8 by zmo@chromium.org, Jul 18 2016

They must have the extension version, glVertexAttribDivisorANGLE, glDrawArraysInstancedANGLE, glDrawElementesInstancedANGLE.

For glFlushMappedBufferRange(), I actually forgot to put it in.  Doing it right now.

Comment 9 by bsalo...@google.com, Jul 18 2016

I think there are two paths forward here.

1) Finish the ES3 implementation in GLES2Interface and then update the bindings to Skia like this:
https://codereview.chromium.org/2157063002

2) Limit Skia to a ES 2.0 functionality (plus whatever extensions are available), like this:
https://codereview.chromium.org/2154373002

Mo, saw your note after writing comment #9. I'll update https://codereview.chromium.org/2157063002 to use the ANGLE entries and wait on FlushMappedBufferRange.

Comment 11 by kbr@chromium.org, Jul 18 2016

For this week it would be safer to restrict Skia to ES 2.0 in Chromium.

After we are passing the WebGL 2.0 conformance tests, let's try to turn on the ES 3.0 code path. Skia's use of this has surely not been tested in Chromium.

gles2_c_lib_autogen.h probably needs aliases for some of its function pointers.

That does indeed sound safer. When GLES2Inteface is in ES 3.0 mode does it still advertise extensions that have become core during the transition from 2.0 to 3.0? I assume so but just want to check that we won't regress something by losing access to 2.0 extension functionality.

Comment 13 by zmo@chromium.org, Jul 18 2016

Thanks for digging into this.  I agree let's not test the ES3 path at this moment. Let's do path 2.  As for extensions in ES3, I don't think we bypass the extension collection code in feature_info.cc in ES3, so you should still have them.
Status: Fixed (was: Started)
Marking this bug fixed as https://codereview.chromium.org/2154373002 has landed.

Sign in to add a comment