[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Framebuffer Fetch



Hi,

 For me, even the non-coherent version emulated by TextureBarrier is a
big win for supporting a variety of blend modes. Hoping to get
TextureBarrier as a WebGL extension seems highly unlikely because it
is DOA for mobile parts, where as framebuffer-fetch for mobile is
almost always possible and framebuffer-fetch-non-coherent without MSAA
is always doable on desktop.

As a side note, Intel hardware support fraembuffer-fetch since Gen9
(Skylake). One can be quite heroic and use/abuse
fragment_shader_interlock to get it on NVIDIA too, but as far as know
AMD there is no viable path.

That is why I also would like to see the non-coherent one come as well.

-Kevin

On Thu, May 28, 2020 at 3:24 PM Ray Tran (ray.tran@snapchat.com)
<public_webgl@khronos.org> wrote:
>
> Hi Kevin,
>
> Thanks for supporting the proposal for EXT_shader_framebuffer_fetch extension in WebGL.
>
> The extension proposal actually was intended to take exactly the same extension done for the OpenGL ES applied to WebGL. The naming of the proposal shows this, as it is prefixed "EXT_" rather "WEBGL_" - but I'm certainly happy to amend the proposal to specify this - and remove anything that implies that it should only be available for WebGL 1.0.
>
> I imagine this should also make the implementation of the extension very simple where WebGL is implemented on top on OpenGL ES - and I guess in implementations where this isn't the case, the underlying GPU architecture often doesn't lend itself to the performance gains that can be afforded by this extension. Performance wins on mobile GPU architectures is my primary reason for proposing this extension - as this is critical for WebGL games and apps that PlayCanvas developers create to run on mobile and desktop web browsers.
>
> Cheers,
> Ray.
>
>
> On Thu, May 28, 2020 at 5:54 AM Kevin Rogovin (kevinrogovin@invisionapp.com) <public_webgl@khronos.org> wrote:
>>
>>
>> Hi all,
>>
>>  I noticed back in May there was a request and some motion to have
>> framebuffer_fetch for WebGL1. I very much want that too, especially
>> for mobile.
>>
>>  However, the current pull request is a cut down version that does not
>> address some of the subtleties related to framebuffer fetch, much less
>> WebGL2 support.
>>
>>  I would like to first have a little discussion of just wrapping
>> entirety of the GL/GLES extension at
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.khronos.org_registry_OpenGL_extensions_EXT_EXT-5Fshader-5Fframebuffer-5Ffetch.txt&d=DwIBaQ&c=ncDTmphkJTvjIDPh0hpF_w&r=EI2UIbJZQ-fAY-YXwdcUvZSolkKLeCNDVj-fBzgbh54&m=9EfHJ3T0Af5vqdthQefBb4rYy60_qIWpSxzxPHRHPTk&s=YWawrtT8MZeuJtFETajbRBV5UhBnqNQ5FktOHcPSYAU&e=
>> into a WebGL extension; it addresses the interaction with MSAA (namely
>> fetch + MSAA essentially becomes SSAA). In addition, it also gives the
>> non-coherent version, GL_EXT_shader_framebuffer_fetch_non_coherent,
>> which provides the function FramebufferFetchBarrierEXT which would
>> allow for desktop parts to be supported by a browser via the core
>> GL4.x functionality glTextureBarrier() for non-MSAA support.
>>
>> If I can get interest, i.e. progress to community approved status, I
>> might be able to convince my employer to contribute to ANGLE to have
>> this extension (on desktop GL directly if the underlying hardware has
>> it or atleast the non-coherent version mapping to texture barrier
>> work).
>>
>> Let the messages begin, I hope. I would like to start with that on
>> WebGL that supporting framebuffer-fetch would be first limited to just
>> non-MSAA render targets.
>>
>> Best Regards,
>> -Kevin
>>
>> -----------------------------------------------------------
>> You are currently subscribed to public_webgl@khronos.org.
>> To unsubscribe, send an email to majordomo@khronos.org with
>> the following command in the body of your email:
>> unsubscribe public_webgl
>> -----------------------------------------------------------
>>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------