[Public WebGL] Resolve MSAA depth?

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


I'd be surprised if it'll work, but I'll give it a try, thanks.

On 19 January 2017 at 17:52, Florian Bösch <[email protected]> wrote:

> Can't you create a pixel pack buffer for your depth FBO attachment and
> then bindBuffer and texImage2D(data=null) it to a texture2D so you can read
> the subpixels?
>
> On Thu, Jan 19, 2017 at 3:38 PM, Mr F <[email protected]> wrote:
>
>> I know and I'm not doing deferred, but rather more simple depth-dependent
>> effects in forward, which work quite fine with blitFramebuffer depth
>> (except the current performance issue). If I can't write to R32F with MSAA
>> though, I can only write encoded RGBA8 values, and these got averaged, they
>> become useless.
>>
>> On 19 January 2017 at 17:34, Florian Bösch <[email protected]> wrote:
>>
>>> Note that averaged (MSAA'ed) colors at the borders and a single depth
>>> value for the pixel produces noticable artifacts when shading as a deferred
>>> step (using the depth for light calculations like area of influence of a
>>> deferred light).
>>>
>>> Most deferred renderers don't do MSAA rendering for that reason (and
>>> because of performance) and use alternative approaches to AA'ing that
>>> operates on the output once all lighting calculations are done.
>>>
>>> On Thu, Jan 19, 2017 at 3:28 PM, Mr F <[email protected]> wrote:
>>>
>>>> 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_te
>>>>>>>>>>>>>>>> sts/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/db4c7a1e/attachment.html>


More information about the public_webgl mailing list