[Public WebGL] Resolve MSAA depth?

Mr F [email protected]
Thu Jan 19 05:46:45 PST 2017


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/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/20170119/c2a1e243/attachment.html>


More information about the public_webgl mailing list