[Public WebGL] Resolve MSAA depth?

Mr F [email protected]
Mon Jan 16 08:37:29 PST 2017


So it seems like ANGLE sometimes implements blit on CPU (!):
https://github.com/google/angle/blob/master/src/libANGLE/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=
>>> 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/20170116/a91a64fa/attachment.html>


More information about the public_webgl mailing list