Bug 58498 – WebGL should create a single-sample context if creating multisampled context fails

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: WebGL

[Zhenyao Mo]

For example, in Chrome, ATI's multisampling on Mac is blocked, so creating a multimsampled context will fail, however, we should try to create a single-sample context and set attributes.antialias to false.

[Naoki Takano]

I want to start looking into the bug. But sill I'm very new about WebGL area. So I have a question.

So does this mean anti-alias feature on GPU?

Could you tell me more how I can reproduce the problem?

For example, pseudo code would be very helpful.

Thanks,

[Zhenyao Mo]

One place you can look at is webcore/platform/graphics/opengl/GraphicsContext3DOpenGL.cpp, reshape function.

In that function, if m_attrs.antialias is true, then we try to create a multisampled FBO for rendering.

Currently that code path doesn't recover from error.  So what we need to do is

1) check if creation of multisampled FBO succeeds or not.
2) if it failed, set m_attrs.antialias = false, and try again.

One thing unclear to me is that it seems attributes.antialias might change in the lifetime of a context.  I am not sure if it's OK or not.

Hope this helps.

[Naoki Takano]

Thanks, Mo.

So can we reproduce on any Mac environment?
Do we need any specific hardware configuration, such as GPU type?

(In reply to comment #2)
> One place you can look at is webcore/platform/graphics/opengl/GraphicsContext3DOpenGL.cpp, reshape function.
> 
> In that function, if m_attrs.antialias is true, then we try to create a multisampled FBO for rendering.
> 
> Currently that code path doesn't recover from error.  So what we need to do is
> 
> 1) check if creation of multisampled FBO succeeds or not.
> 2) if it failed, set m_attrs.antialias = false, and try again.
> 
> One thing unclear to me is that it seems attributes.antialias might change in the lifetime of a context.  I am not sure if it's OK or not.
> 
> Hope this helps.

[Zhenyao Mo]

We don't exactly know on which hardware the multisampled FBO creation might fail.  You'll have to emulate failure in the multisampled path to test the recovering and fallback to non-multisampled path.

(In reply to comment #3)
> Thanks, Mo.
> 
> So can we reproduce on any Mac environment?
> Do we need any specific hardware configuration, such as GPU type?
> 
> (In reply to comment #2)
> > One place you can look at is webcore/platform/graphics/opengl/GraphicsContext3DOpenGL.cpp, reshape function.
> > 
> > In that function, if m_attrs.antialias is true, then we try to create a multisampled FBO for rendering.
> > 
> > Currently that code path doesn't recover from error.  So what we need to do is
> > 
> > 1) check if creation of multisampled FBO succeeds or not.
> > 2) if it failed, set m_attrs.antialias = false, and try again.
> > 
> > One thing unclear to me is that it seems attributes.antialias might change in the lifetime of a context.  I am not sure if it's OK or not.
> > 
> > Hope this helps.

[Naoki Takano]

Mo,

Sorry for bothering you.

But I want to make sure the source code you suggested.

Right now, I'm mainly working on Chromium source code base. And even after I change something in GraphicsContext3DOpenGL.cpp, I cannot see anything when I run 'make'. As you know, if we change anything for the source code, we should be able to see compile process when 'make'.

I checked on Linux and Mac. But I cannot see any compilation on both platforms.

Is this source cod used by Chromium port? Or do I need to set extra build setting to use this portion?

Thanks,

(In reply to comment #4)
> We don't exactly know on which hardware the multisampled FBO creation might fail.  You'll have to emulate failure in the multisampled path to test the recovering and fallback to non-multisampled path.
> 
> (In reply to comment #3)
> > Thanks, Mo.
> > 
> > So can we reproduce on any Mac environment?
> > Do we need any specific hardware configuration, such as GPU type?
> > 
> > (In reply to comment #2)
> > > One place you can look at is webcore/platform/graphics/opengl/GraphicsContext3DOpenGL.cpp, reshape function.
> > > 
> > > In that function, if m_attrs.antialias is true, then we try to create a multisampled FBO for rendering.
> > > 
> > > Currently that code path doesn't recover from error.  So what we need to do is
> > > 
> > > 1) check if creation of multisampled FBO succeeds or not.
> > > 2) if it failed, set m_attrs.antialias = false, and try again.
> > > 
> > > One thing unclear to me is that it seems attributes.antialias might change in the lifetime of a context.  I am not sure if it's OK or not.
> > > 
> > > Hope this helps.

[Zhenyao Mo]

Ah sorry for confusing you.

GraphicsContext3DOpenGL.cpp is used by webkit Mac port (Safari).

For chromium, the in-process port is in chromium tree under src/webkit/gpu/webgraphicscontext3d_in_process_impl.cc:reshape();

the command buffer port is under the same folder, but you need to dig deeper into the command buffer code to add the behavior, and reshape function is the entry.



(In reply to comment #5)
> Mo,
> 
> Sorry for bothering you.
> 
> But I want to make sure the source code you suggested.
> 
> Right now, I'm mainly working on Chromium source code base. And even after I change something in GraphicsContext3DOpenGL.cpp, I cannot see anything when I run 'make'. As you know, if we change anything for the source code, we should be able to see compile process when 'make'.
> 
> I checked on Linux and Mac. But I cannot see any compilation on both platforms.
> 
> Is this source cod used by Chromium port? Or do I need to set extra build setting to use this portion?
> 
> Thanks,
> 
> (In reply to comment #4)
> > We don't exactly know on which hardware the multisampled FBO creation might fail.  You'll have to emulate failure in the multisampled path to test the recovering and fallback to non-multisampled path.
> > 
> > (In reply to comment #3)
> > > Thanks, Mo.
> > > 
> > > So can we reproduce on any Mac environment?
> > > Do we need any specific hardware configuration, such as GPU type?
> > > 
> > > (In reply to comment #2)
> > > > One place you can look at is webcore/platform/graphics/opengl/GraphicsContext3DOpenGL.cpp, reshape function.
> > > > 
> > > > In that function, if m_attrs.antialias is true, then we try to create a multisampled FBO for rendering.
> > > > 
> > > > Currently that code path doesn't recover from error.  So what we need to do is
> > > > 
> > > > 1) check if creation of multisampled FBO succeeds or not.
> > > > 2) if it failed, set m_attrs.antialias = false, and try again.
> > > > 
> > > > One thing unclear to me is that it seems attributes.antialias might change in the lifetime of a context.  I am not sure if it's OK or not.
> > > > 
> > > > Hope this helps.

[Naoki Takano]

I see, I'll look into it more.

BTW, this is a quite a bit different question. But do you know SKIA_GPU flag? Is the bug related to this flag? If so, how can I turn it on?

Thanks,

(In reply to comment #6)
> Ah sorry for confusing you.
> 
> GraphicsContext3DOpenGL.cpp is used by webkit Mac port (Safari).
> 
> For chromium, the in-process port is in chromium tree under src/webkit/gpu/webgraphicscontext3d_in_process_impl.cc:reshape();
> 
> the command buffer port is under the same folder, but you need to dig deeper into the command buffer code to add the behavior, and reshape function is the entry.
> 
> 
> 
> (In reply to comment #5)
> > Mo,
> > 
> > Sorry for bothering you.
> > 
> > But I want to make sure the source code you suggested.
> > 
> > Right now, I'm mainly working on Chromium source code base. And even after I change something in GraphicsContext3DOpenGL.cpp, I cannot see anything when I run 'make'. As you know, if we change anything for the source code, we should be able to see compile process when 'make'.
> > 
> > I checked on Linux and Mac. But I cannot see any compilation on both platforms.
> > 
> > Is this source cod used by Chromium port? Or do I need to set extra build setting to use this portion?
> > 
> > Thanks,
> > 
> > (In reply to comment #4)
> > > We don't exactly know on which hardware the multisampled FBO creation might fail.  You'll have to emulate failure in the multisampled path to test the recovering and fallback to non-multisampled path.
> > > 
> > > (In reply to comment #3)
> > > > Thanks, Mo.
> > > > 
> > > > So can we reproduce on any Mac environment?
> > > > Do we need any specific hardware configuration, such as GPU type?
> > > > 
> > > > (In reply to comment #2)
> > > > > One place you can look at is webcore/platform/graphics/opengl/GraphicsContext3DOpenGL.cpp, reshape function.
> > > > > 
> > > > > In that function, if m_attrs.antialias is true, then we try to create a multisampled FBO for rendering.
> > > > > 
> > > > > Currently that code path doesn't recover from error.  So what we need to do is
> > > > > 
> > > > > 1) check if creation of multisampled FBO succeeds or not.
> > > > > 2) if it failed, set m_attrs.antialias = false, and try again.
> > > > > 
> > > > > One thing unclear to me is that it seems attributes.antialias might change in the lifetime of a context.  I am not sure if it's OK or not.
> > > > > 
> > > > > Hope this helps.

[Zhenyao Mo]

(In reply to comment #7)
> I see, I'll look into it more.
> 
> BTW, this is a quite a bit different question. But do you know SKIA_GPU flag? Is the bug related to this flag? If so, how can I turn it on?

It's on by default on the trunk so if you sync and build your own chromium, you don't need to do anything.  Also, it has nothing to do with this bug.

> 
> Thanks,
> 
> (In reply to comment #6)
> > Ah sorry for confusing you.
> > 
> > GraphicsContext3DOpenGL.cpp is used by webkit Mac port (Safari).
> > 
> > For chromium, the in-process port is in chromium tree under src/webkit/gpu/webgraphicscontext3d_in_process_impl.cc:reshape();
> > 
> > the command buffer port is under the same folder, but you need to dig deeper into the command buffer code to add the behavior, and reshape function is the entry.
> > 
> > 
> > 
> > (In reply to comment #5)
> > > Mo,
> > > 
> > > Sorry for bothering you.
> > > 
> > > But I want to make sure the source code you suggested.
> > > 
> > > Right now, I'm mainly working on Chromium source code base. And even after I change something in GraphicsContext3DOpenGL.cpp, I cannot see anything when I run 'make'. As you know, if we change anything for the source code, we should be able to see compile process when 'make'.
> > > 
> > > I checked on Linux and Mac. But I cannot see any compilation on both platforms.
> > > 
> > > Is this source cod used by Chromium port? Or do I need to set extra build setting to use this portion?
> > > 
> > > Thanks,
> > > 
> > > (In reply to comment #4)
> > > > We don't exactly know on which hardware the multisampled FBO creation might fail.  You'll have to emulate failure in the multisampled path to test the recovering and fallback to non-multisampled path.
> > > > 
> > > > (In reply to comment #3)
> > > > > Thanks, Mo.
> > > > > 
> > > > > So can we reproduce on any Mac environment?
> > > > > Do we need any specific hardware configuration, such as GPU type?
> > > > > 
> > > > > (In reply to comment #2)
> > > > > > One place you can look at is webcore/platform/graphics/opengl/GraphicsContext3DOpenGL.cpp, reshape function.
> > > > > > 
> > > > > > In that function, if m_attrs.antialias is true, then we try to create a multisampled FBO for rendering.
> > > > > > 
> > > > > > Currently that code path doesn't recover from error.  So what we need to do is
> > > > > > 
> > > > > > 1) check if creation of multisampled FBO succeeds or not.
> > > > > > 2) if it failed, set m_attrs.antialias = false, and try again.
> > > > > > 
> > > > > > One thing unclear to me is that it seems attributes.antialias might change in the lifetime of a context.  I am not sure if it's OK or not.
> > > > > > 
> > > > > > Hope this helps.

[Naoki Takano]

Mo,

Still I suspect the source file you suggested was wrong.

The correct one is
content/renderer/gpu/webgraphicscontext3d_command_buffer_impl.cc
isn't it?


(In reply to comment #6)
> Ah sorry for confusing you.
> 
> GraphicsContext3DOpenGL.cpp is used by webkit Mac port (Safari).
> 
> For chromium, the in-process port is in chromium tree under src/webkit/gpu/webgraphicscontext3d_in_process_impl.cc:reshape();
> 
> the command buffer port is under the same folder, but you need to dig deeper into the command buffer code to add the behavior, and reshape function is the entry.
> 
> 
> 
> (In reply to comment #5)
> > Mo,
> > 
> > Sorry for bothering you.
> > 
> > But I want to make sure the source code you suggested.
> > 
> > Right now, I'm mainly working on Chromium source code base. And even after I change something in GraphicsContext3DOpenGL.cpp, I cannot see anything when I run 'make'. As you know, if we change anything for the source code, we should be able to see compile process when 'make'.
> > 
> > I checked on Linux and Mac. But I cannot see any compilation on both platforms.
> > 
> > Is this source cod used by Chromium port? Or do I need to set extra build setting to use this portion?
> > 
> > Thanks,
> > 
> > (In reply to comment #4)
> > > We don't exactly know on which hardware the multisampled FBO creation might fail.  You'll have to emulate failure in the multisampled path to test the recovering and fallback to non-multisampled path.
> > > 
> > > (In reply to comment #3)
> > > > Thanks, Mo.
> > > > 
> > > > So can we reproduce on any Mac environment?
> > > > Do we need any specific hardware configuration, such as GPU type?
> > > > 
> > > > (In reply to comment #2)
> > > > > One place you can look at is webcore/platform/graphics/opengl/GraphicsContext3DOpenGL.cpp, reshape function.
> > > > > 
> > > > > In that function, if m_attrs.antialias is true, then we try to create a multisampled FBO for rendering.
> > > > > 
> > > > > Currently that code path doesn't recover from error.  So what we need to do is
> > > > > 
> > > > > 1) check if creation of multisampled FBO succeeds or not.
> > > > > 2) if it failed, set m_attrs.antialias = false, and try again.
> > > > > 
> > > > > One thing unclear to me is that it seems attributes.antialias might change in the lifetime of a context.  I am not sure if it's OK or not.
> > > > > 
> > > > > Hope this helps.

[Zhenyao Mo]

OK, I must have looked at an out-of-sync code base.  Yeah there is only one such file, so that should be it.  Sorry about the wrong location.

[Zhenyao Mo]

I just realized I implemented this behavior in command buffer port while trying to implementing the feature that internal drawing buffer could be smaller size if we fail to create using the requested canvas size.

So if the original drawing buffer is multisampled, we first fallback to a non-multisampled drawing buffer with the same size, and if it fails again, we fallback to smaller size.

See codereview.chromium.org/7238008

[Zhenyao Mo]

(In reply to comment #11)
> I just realized I implemented this behavior in command buffer port while trying to implementing the feature that internal drawing buffer could be smaller size if we fail to create using the requested canvas size.
> 
> So if the original drawing buffer is multisampled, we first fallback to a non-multisampled drawing buffer with the same size, and if it fails again, we fallback to smaller size.
> 
> See codereview.chromium.org/7238008

This is an effort trying to pass webgl conformance test conformance/drawingbuffer-test.html and conformance/drawingbuffer-static-canvas-test.html

[Naoki Takano]

So do you mean I don't have to do anything for Chromium port?

(In reply to comment #12)
> (In reply to comment #11)
> > I just realized I implemented this behavior in command buffer port while trying to implementing the feature that internal drawing buffer could be smaller size if we fail to create using the requested canvas size.
> > 
> > So if the original drawing buffer is multisampled, we first fallback to a non-multisampled drawing buffer with the same size, and if it fails again, we fallback to smaller size.
> > 
> > See codereview.chromium.org/7238008
> 
> This is an effort trying to pass webgl conformance test conformance/drawingbuffer-test.html and conformance/drawingbuffer-static-canvas-test.html

[Zhenyao Mo]

(In reply to comment #13)
> So do you mean I don't have to do anything for Chromium port?

No need for the chromium command-buffer port, but the in-process-webgl and webkit/safari port still need to be implemented.

> 
> (In reply to comment #12)
> > (In reply to comment #11)
> > > I just realized I implemented this behavior in command buffer port while trying to implementing the feature that internal drawing buffer could be smaller size if we fail to create using the requested canvas size.
> > > 
> > > So if the original drawing buffer is multisampled, we first fallback to a non-multisampled drawing buffer with the same size, and if it fails again, we fallback to smaller size.
> > > 
> > > See codereview.chromium.org/7238008
> > 
> > This is an effort trying to pass webgl conformance test conformance/drawingbuffer-test.html and conformance/drawingbuffer-static-canvas-test.html

[Kimmo Kinnunen]

Likmly not relevant anymore. WebGL2 must respect the requested configuration. WebGL1 should probably not get the feature if it hasn't been implemented today.