[Public WebGL] Resolve MSAA depth?

Mr F [email protected]
Thu Jan 19 06:28:52 PST 2017


Furthermore, rendering depth to a separate RT (using drawBuffers) doesn't
make much sense, because the samples are averaged (only needs 1st sample,
and that's what blit was supposed to do).

On 19 January 2017 at 16:46, Mr F <[email protected]> wrote:

> Hmm seems like ANGLE is not able to render MSAA R32F color as well? So
> I'll have to use RGBA8 encoded depth WebGL1-style again.
>
> On 19 January 2017 at 00:02, Mr F <[email protected]> wrote:
>
>> I've just posted a possible solution to this issue there.
>>
>> On 18 January 2017 at 01:08, Jamie Madill <[email protected]> wrote:
>>
>>> Aha yes.
>>>
>>> Long story short, I couldn't get multisampled resolve (aka blit from
>>> multisample to single-sampled textures) working with a shader. I spent a
>>> fair bit of time on this. Sorry about this, but for now it's a slow path.
>>> Feel free to comment on the issue I just opened: anglebug.com/1710. I
>>> tried this a few different ways but always ended up with a blank texture
>>> and nothing being written.
>>>
>>> Not sure what to suggest other than trying to use a non-depth texture
>>> for the same effect if possible.
>>>
>>> On Tue, Jan 17, 2017 at 4:27 PM, Mr F <[email protected]> wrote:
>>>
>>>> Here's a tiny example: http://geom.io/testResolveDepth/index.html
>>>> It blits MSAA R11G11B10 + 32F depth into 2 non-multisampled textures.
>>>>
>>>>
>>>> On 18 January 2017 at 00:23, Mr F <[email protected]> wrote:
>>>>
>>>>> 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/chromi
>>>>>>>>>>>> um/src/content/test/gpu/gpu_tests/webgl2_conformance_expecta
>>>>>>>>>>>> tions.py?q=webgl2_conform&sq=package: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/20170119/0278c2d6/attachment.html>


More information about the public_webgl mailing list