[Public WebGL] Resolve MSAA depth?

Mr F [email protected]
Tue Jan 17 13:23:23 PST 2017


I'm talking about multisampled blit though

On 17 January 2017 at 23:03, Jamie Madill <[email protected]> wrote:

> Non-multisample depth blit by itself should use a shader.. but we'd need a
> small repro case to verify. Let me know if you can pull one together and
> I'll look.
>
> On Tue, Jan 17, 2017 at 2:39 PM, Mr F <[email protected]> wrote:
>
>> I understand depth/stencil complications. Are you sure 32F depth blits
>> are never CPU-bound? There's a weird issue right now with it taking large
>> chunk of performance, although only in FF Nightly (Chrome is fine). I
>> wonder if some older versions of ANGLE did CPU copy for D32F?
>>
>> On 17 January 2017 at 22:28, Jamie Madill <[email protected]> wrote:
>>
>>> Blit is core in GLES 3, so we need to emulate some of the depth/stencil
>>> blits to support GLES 3 at all. Such is the nature of what ANGLE does.
>>>
>>> It's something that is predictable from ANGLE's point of view, but I
>>> understand it might be unclear from the app's point of view. Stencil bits
>>> in particular are difficult, and multisample depth/stencil. We're working
>>> on making this more visible - one thing is that it'll show up in Chrome's
>>> about:gpu page. Ideally it could show up in some debugging log visible to
>>> javascript.
>>>
>>> On Mon, Jan 16, 2017 at 11:37 AM, Mr F <[email protected]> wrote:
>>>
>>>> So it seems like ANGLE sometimes implements blit on CPU (!):
>>>> https://github.com/google/angle/blob/master/src/libANGL
>>>> E/renderer/d3d/d3d11/Blit11.cpp#L240
>>>>
>>>> Which gives huge slowdowns without really telling why and being able to
>>>> predict it. If on some platform some blit is not possible, maybe we should
>>>> just throw an error, disable it, make it an extension or something? CPU
>>>> blit is pure evil.
>>>>
>>>> On 1 December 2016 at 15:50, Mr F <[email protected]> wrote:
>>>>
>>>>> OK, sorry for bothering - must be my mistake somewhere. Made it work
>>>>> while preparing the test case :)
>>>>>
>>>>> On 30 November 2016 at 23:03, Jamie Madill <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Yes, a reproduction / test case would be awesome, thanks.
>>>>>>
>>>>>> On Tue, Nov 29, 2016 at 9:20 PM, Jeff Gilbert <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> FWIW, the spec says pretty explicitly that BlitFramebuffer should be
>>>>>>> functional for depth->depth blitting, as long as the formats match,
>>>>>>> etc etc.
>>>>>>>
>>>>>>> GLES 3.0.5 p198:
>>>>>>> If the
>>>>>>> source formats are depth values, sample values are resolved in an
>>>>>>> implementation-
>>>>>>> dependent manner where the result will be between the minimum and
>>>>>>> maximum
>>>>>>> depth values in the pixel.
>>>>>>>
>>>>>>> On Tue, Nov 29, 2016 at 8:16 PM, Kenneth Russell <[email protected]>
>>>>>>> wrote:
>>>>>>> > Could you make any test case available? Do you have any other
>>>>>>> platforms
>>>>>>> > (Mac, Linux) to test on? You could also try launching Chrome with
>>>>>>> the
>>>>>>> > command line argument --use-angle=gl to see the difference between
>>>>>>> ANGLE's
>>>>>>> > D3D11 and OpenGL backends.
>>>>>>> >
>>>>>>> >
>>>>>>> > On Tue, Nov 29, 2016 at 12:42 PM, Mr F <[email protected]>
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> >> I'll try to prepare a clean test case soon. I'm on the latest
>>>>>>> Chrome
>>>>>>> >> Canary/Win 7/GTX970. Both source and destination are 32F. What I
>>>>>>> mean by
>>>>>>> >> "blank" actually looks like a solid red color, which seems to be
>>>>>>> uniform
>>>>>>> >> 1,0,0, no matter how close/far I'm from any geometry.It's good to
>>>>>>> know that
>>>>>>> >> it is supposed to work - maybe just my mistake somewhere,
>>>>>>> although I tested
>>>>>>> >> it heavily. The source buffer is created and attached using
>>>>>>> >>
>>>>>>> >> renderbufferStorageMultisample(gl.RENDERBUFFER, 4,
>>>>>>> gl.DEPTH_COMPONENT32F,
>>>>>>> >> width, height)
>>>>>>> >> framebufferRenderbuffer(gl.FRAMEBUFFER, gl.DEPTH_ATTACHMENT,
>>>>>>> >> gl.RENDERBUFFER, msaaBuffer)
>>>>>>> >>
>>>>>>> >> and the destination created and attached to another framebufer
>>>>>>> with
>>>>>>> >>
>>>>>>> >> texImage2D(gl.TEXTURE_2D, 0, gl.DEPTH_COMPONENT32F, width,
>>>>>>> height, 0,
>>>>>>> >> gl.DEPTH_COMPONENT, gl.FLOAT, null)
>>>>>>> >> framebufferTexture2D(gl.FRAMEBUFFER, gl.DEPTH_ATTACHMENT,
>>>>>>> gl.TEXTURE_2D,
>>>>>>> >> tex, 0)
>>>>>>> >>
>>>>>>> >> The blit is performed like this:
>>>>>>> >> bindFramebuffer(gl.READ_FRAMEBUFFER, msaaFBO)
>>>>>>> >> bindFramebuffer(gl.DRAW_FRAMEBUFFER, resolveFBO)
>>>>>>> >> blitFramebuffer(0, 0, width, height, 0, 0, width, height,
>>>>>>> >> gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT, gl.NEAREST)
>>>>>>> >>
>>>>>>> >> On 29 November 2016 at 17:51, Jamie Madill <[email protected]>
>>>>>>> wrote:
>>>>>>> >>>
>>>>>>> >>> This generally should work. There are tests for this in dEQP's
>>>>>>> >>> dEQP-GLES3.functional.fbo.msaa and also in the WebGL 2-specific
>>>>>>> tests in
>>>>>>> >>> gles3/fbomultisample and I think also fboinvalidate/sub.
>>>>>>> >>>
>>>>>>> >>> Note some of these tests are marked as failing on Intel on
>>>>>>> pretty much
>>>>>>> >>> all platforms:
>>>>>>> >>>
>>>>>>> >>> https://cs.chromium.org/chromium/src/content/test/gpu/gpu_te
>>>>>>> sts/webgl2_conformance_expectations.py?q=webgl2_conform&sq=p
>>>>>>> ackage:chromium&l=118
>>>>>>> >>>
>>>>>>> >>> Mr F, what platform are you on, and which vendor?
>>>>>>> >>>
>>>>>>> >>> On Mon, Nov 28, 2016 at 10:34 PM, Kenneth Russell <
>>>>>>> [email protected]> wrote:
>>>>>>> >>>>
>>>>>>> >>>> I'm pretty sure this should either work, or generate an OpenGL
>>>>>>> error.
>>>>>>> >>>> OpenGL ES 3.0.5 section 4.3.3 "Copying Pixels" says
>>>>>>> BlitFramebuffer
>>>>>>> >>>> generates INVALID_OPERATION if the mask includes
>>>>>>> DEPTH_BUFFER_BIT or
>>>>>>> >>>> STENCIL_BUFFER_BIT, and the source and destination depth and
>>>>>>> stencil buffer
>>>>>>> >>>> formats don't match.
>>>>>>> >>>>
>>>>>>> >>>> It looks like there are extensive tests of resolving
>>>>>>> multisampled depth
>>>>>>> >>>> buffers to single-sampled ones, but I'm not sure about
>>>>>>> resolving to a depth
>>>>>>> >>>> texture. Do you have a test case? What platform are you on (can
>>>>>>> you provide
>>>>>>> >>>> about:gpu if you're running Chrome)?
>>>>>>> >>>>
>>>>>>> >>>> -Ken
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> On Sat, Nov 26, 2016 at 12:26 PM, Mr F <[email protected]>
>>>>>>> wrote:
>>>>>>> >>>>>
>>>>>>> >>>>> The docs are a bit unclear on that. Is it possible to use
>>>>>>> >>>>> blitFramebuffer to get current MSAA depth buffer into a
>>>>>>> non-MSAA depth
>>>>>>> >>>>> texture? The color buffer is resolved nicely, however the
>>>>>>> depth is just
>>>>>>> >>>>> blank, and no error is generated - wondering if it's the
>>>>>>> expected behaviour.
>>>>>>> >>>>> Depth format is DEPTH_COMPONENT32F.
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>
>>>>>>> >>
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170118/e8a20165/attachment.html>


More information about the public_webgl mailing list