From ash...@ Mon Aug 20 15:56:12 2018 From: ash...@ (Ashley Gullen) Date: Mon, 20 Aug 2018 23:56:12 +0100 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: Message-ID: We've been finding lately that rendering advanced blending effects with a shader via an intermediate texture has a high performance overhead, especially when rendering many sprites. Given that WebGL 2 is out, and according to gpuinfo.org desktop support is ~46% and mobile support ~31%, would it be worth revisiting this? Only supporting it when backed by the driver would be fine. On 27 May 2015 at 01:24, Kenneth Russell wrote: > The majority of the work in exposing this extension would be writing > conformance tests. It looks like the drawElements test suite has some > tests of this extension: > https://android.googlesource.com/platform/external/deqp/+/ > master/modules/gles31/functional/es31fAdvancedBlendTests.cpp > . They'd need to be ported to JavaScript and WebGL. > > Given that device support for the extension is pretty low, though, > it'd be more profitable to write a JavaScript library that would > either provide similar functionality to this extension, or polyfill it > altogether. Assuming there's no support for it in the OpenGL driver, > implementing this extension in the browser won't make it run > significantly faster than a JavaScript implementation. The same > technique of ping-ponging the source and destination textures and > implementing the blending equations in a shader can be implemented > with basically the same speed in JavaScript as it can in the WebGL > implementation -- and if that's not the case, then that's something > that needs to be fixed in the browser to make all WebGL apps run > faster. > > Fixing bugs and passing the WebGL 2.0 conformance suite is at the top > of our priority list right now -- so I'd agree with Vlad's assessment > that this particular extension shouldn't delay that work. > > -Ken > > > > On Tue, May 26, 2015 at 3:34 PM, Ashley Gullen wrote: > > I'm not sure how to mark up a proposal or how the whole pull request > thing > > is supposed to be done, so I drafted a proposal and I'm just attaching > it as > > a .txt file. Someone can do something more official with this if they > like! > > > > On 26 May 2015 at 20:42, Vladimir Vukicevic > wrote: > >> > >> XOR got supported on Canvas 2D due to an artifact of it being a mapping > of > >> Apple's canvas/CoreGraphics APIs. It's at best poorly supported today, > at > >> least with any reasonable performance. > >> > >> I don't see any downside to proposing this extension, but I suspect that > >> all the WebGL implementors are currently busy working on their WebGL 2 > >> implementations, and even beyond that I'd suggest that GL ES > 3.1-equivalent > >> functionality would take precedence. Then again, it would not be a > >> difficult extension to implement, especially if it was only exposed if > the > >> underlying graphics API had support. > >> > >> - Vlad > >> > >> > >> On Tue, May 26, 2015 at 1:48 PM, Ashley Gullen > wrote: > >>> > >>> TBH I don't care much for the xor effect, I don't think it's terribly > >>> useful - it was a weird choice to support it in canvas2d - and if it's > not > >>> possible to support then that's fine by me. I'm more interested in the > >>> photoshop style blends like screen and multiply. I'll do a little > research > >>> in to the D3D11 side of things and write a draft definition. > >>> > >>> Ashley > >>> > >>> > >>> On 26 May 2015 at 17:09, Jukka Jyl?nki wrote: > >>>> > >>>> Direct3D 11.1 adds support for logic ops via blend states: > >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ > hh404562%28v=vs.85%29.aspx#use_logical_operations_in_a_render_target > >>>> , which is present on Windows 8 and Windows Phone 8. I am not sure if > this > >>>> is one of the "partial D3D11.1 support on Windows 7" features, could > not > >>>> find that page at a quick glance. In D3D11.1 one creates an immutable > blend > >>>> state that has the desired logic operation on a render target: > >>>> > >>>> ID3D11Device1::CreateBlendState1: > >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ > hh404577(v=vs.85).aspx > >>>> -> D3D11_BLEND_DESC1: > >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ > hh404435(v=vs.85).aspx > >>>> -> D3D11_RENDER_TARGET_BLEND_DESC1: > >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ > hh404492(v=vs.85).aspx > >>>> -> D3D11_LOGIC_OP: > >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ > hh404484(v=vs.85).aspx > >>>> > >>>> > >>>> 2015-05-26 18:54 GMT+03:00 Florian B?sch : > >>>>> > >>>>> A few remarks: > >>>>> > >>>>> glLogicOp interacts with the rest of the blending machinery, so > >>>>> supporting blend equation advanced via that function might be > tricky. Also > >>>>> it'd be quite difficult to ensure non-coherent undefinedness using > this > >>>>> route. Fortunately the blend equation advanced extensions also exist > for > >>>>> desktop GL. However they're some of the very latest extensions in ARB > >>>>> status, and so support might come in different (non ARB) flavours or > not at > >>>>> all. > >>>>> > >>>>> The blend barrier function should be no problem to support on the > >>>>> extension object provided the extension is provided by the underlying > >>>>> extension rather than emulated via other functionality. > >>>>> > >>>>> Support is difficult to gauge, but it's probably not great. This > >>>>> capability index tracks it on desktop GL at 2% > >>>>> http://feedback.wildfiregames.com/report/opengl/ > >>>>> > >>>>> I would guesstimate support on mobiles would be similarly low for the > >>>>> time being. > >>>>> > >>>>> An open question would be how you get that behavior into Direct3D of > >>>>> course. Can somebody elaborate on that point? > >>>>> > >>>>> Regardless of that, I'd encourage you to propose an extension > >>>>> definition (via git pull request) for this functionality, this will > help > >>>>> direct the discussion away from idle speculation on a ML and into > something > >>>>> with real consequences for stakeholders (it's not real until you > spec it). > >>>>> > >>>>> On Tue, May 26, 2015 at 5:40 PM, Jukka Jyl?nki > >>>>> wrote: > >>>>>> > >>>>>> Currently neither GLES2 core or WebGL1 supports exclusive-or > blending. > >>>>>> Desktop OpenGL since something like 1.4 has had this and more via > glLogicOp > >>>>>> functionality: https://www.opengl.org/sdk/ > docs/man/html/glLogicOp.xhtml and > >>>>>> GLES1.1 had it as well, but for some reason, GLES2 removed > glLogicOp (I > >>>>>> think GLES3 didn't add it back either, but my GL spec lawyer > stamina is too > >>>>>> low to actually check the pdf). Don't know the reason why since > OpenGL > >>>>>> decision making is not open in the public, but if I had to guess, > some > >>>>>> vendor x with chip y on OS z was not able to support it efficiently > and > >>>>>> wanted it gone, probably basing the argument on it not being a very > common > >>>>>> functionality, and/or that the renderable texture format family > that was > >>>>>> chosen to GLES2 core didn't feel appropriate enough. > >>>>>> > >>>>>> Not sure if glLogicOp support should be a prerequisite for > >>>>>> WEBGL_blend_equation_advanced, though the other blend modes than > xor sound > >>>>>> like they don't need bitwise ops being supported. > >>>>>> > >>>>>> 2015-05-26 18:12 GMT+03:00 Ashley Gullen : > >>>>>>> > >>>>>>> KHR_blend_equation_advanced adds some interesting new color blend > >>>>>>> modes such as multiply, screen, overlay and more. I think these > warrant > >>>>>>> particular attention on the web platform because they correspond > to some of > >>>>>>> the 2D context's more recent composite modes. Consider the mapping > of > >>>>>>> globalCompositeMode to OpenGL blend modes: > >>>>>>> > >>>>>>> "source-over", "source-in", "source-out", "source-atop", > >>>>>>> "destination-over", "destination-in", "destination-out", > "destination-atop", > >>>>>>> "lighter", "copy": all possible with existing blend modes > >>>>>>> "xor": don't know? > >>>>>>> "multiply": MULTIPLY_KHR > >>>>>>> "screen": SCREEN_KHR > >>>>>>> "overlay": OVERLAY_KHR > >>>>>>> "darken": DARKEN_KHR > >>>>>>> "lighten": LIGHTEN_KHR > >>>>>>> "color-dodge": COLORDODGE_KHR > >>>>>>> "color-burn": COLORBURN_KHR > >>>>>>> "hard-light": HARDLIGHT_KHR > >>>>>>> "soft-light": SOFTLIGHT_KHR > >>>>>>> "difference": DIFFERENCE_KHR > >>>>>>> "exclusion": EXCLUSION_KHR > >>>>>>> "hue": HSL_HUE_KHR > >>>>>>> "saturation": HSL_SATURATION_KHR > >>>>>>> "color": HSL_COLOR_KHR > >>>>>>> "luminosity": HSL_LUMINOSITY_KHR > >>>>>>> > >>>>>>> The mapping is pretty much perfect. I don't know if there's a blend > >>>>>>> mode that covers "xor", but if there is (and I'd be interested to > know!) > >>>>>>> then the mapping is perfect. > >>>>>>> > >>>>>>> This extension has a few use cases: > >>>>>>> - Improve consistency across the web platform, by bringing the > WebGL > >>>>>>> and 2D context's capabilities closer together. This makes it > easier to build > >>>>>>> 2D WebGL applications that are equivalent to their canvas2d > counterparts. > >>>>>>> - make it easier to polyfill/extend/implement canvas2d via WebGL > >>>>>>> (browser vendors may be interested in a JS implementation of > >>>>>>> CanvasRenderingContext2D for performance reasons) > >>>>>>> - provide useful blending modes without making authors resort to > >>>>>>> writing their own shaders and having to know all the formulae > involved > >>>>>>> - provide a performance guarantee, since the blending uses > >>>>>>> hardware/driver-authored implementations and minimises the > necessary draw > >>>>>>> calls/state changes to use these blend modes, avoiding inefficient > >>>>>>> implementations by developers (or possibly even exceeding what > they can > >>>>>>> achieve even in the best case depending on if the driver uses any > special > >>>>>>> optimisations) > >>>>>>> > >>>>>>> It also appears to be a relatively small API surface, mainly > >>>>>>> introducing new enums for blendEquation. > >>>>>>> > >>>>>>> Some questions/risks: > >>>>>>> - I don't know what the GPU support for this is like in the wild > >>>>>>> across desktop and mobile, although I've read it's part of the > Android > >>>>>>> Extension Pack which suggests some mobile support > >>>>>>> - I don't know enough about this area to comment on the suitability > >>>>>>> of the "coherent" version or the "blendBarrier" function's > suitability in a > >>>>>>> WebGL context > >>>>>>> - if GPU support is not broad, developers may feel that a fallback > is > >>>>>>> still necessary so developers will need to write their own shaders > for these > >>>>>>> blend modes anyway, eliminating some of the benefits > >>>>>>> > >>>>>>> Still, these blend modes were deemed suitable for the 2D context > so I > >>>>>>> feel it would be useful to have them in WebGL too. In our > particular case as > >>>>>>> developers of a 2D HTML5 game engine, this would simplify our code > and > >>>>>>> improve consistency with the 2D context fallback. > >>>>>>> > >>>>>>> Ashley Gullen > >>>>>>> Scirra.com > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Aug 21 04:54:21 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 21 Aug 2018 13:54:21 +0200 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: Message-ID: I'd suggest you just make a pull request for the extension proposal to spec repo. On Tue, Aug 21, 2018 at 12:56 AM Ashley Gullen wrote: > We've been finding lately that rendering advanced blending effects with a > shader via an intermediate texture has a high performance overhead, > especially when rendering many sprites. Given that WebGL 2 is out, and > according to gpuinfo.org desktop support is ~46% and mobile support ~31%, > would it be worth revisiting this? Only supporting it when backed by the > driver would be fine. > > > On 27 May 2015 at 01:24, Kenneth Russell wrote: > >> The majority of the work in exposing this extension would be writing >> conformance tests. It looks like the drawElements test suite has some >> tests of this extension: >> >> https://android.googlesource.com/platform/external/deqp/+/master/modules/gles31/functional/es31fAdvancedBlendTests.cpp >> . They'd need to be ported to JavaScript and WebGL. >> >> Given that device support for the extension is pretty low, though, >> it'd be more profitable to write a JavaScript library that would >> either provide similar functionality to this extension, or polyfill it >> altogether. Assuming there's no support for it in the OpenGL driver, >> implementing this extension in the browser won't make it run >> significantly faster than a JavaScript implementation. The same >> technique of ping-ponging the source and destination textures and >> implementing the blending equations in a shader can be implemented >> with basically the same speed in JavaScript as it can in the WebGL >> implementation -- and if that's not the case, then that's something >> that needs to be fixed in the browser to make all WebGL apps run >> faster. >> >> Fixing bugs and passing the WebGL 2.0 conformance suite is at the top >> of our priority list right now -- so I'd agree with Vlad's assessment >> that this particular extension shouldn't delay that work. >> >> -Ken >> >> >> >> On Tue, May 26, 2015 at 3:34 PM, Ashley Gullen wrote: >> > I'm not sure how to mark up a proposal or how the whole pull request >> thing >> > is supposed to be done, so I drafted a proposal and I'm just attaching >> it as >> > a .txt file. Someone can do something more official with this if they >> like! >> > >> > On 26 May 2015 at 20:42, Vladimir Vukicevic >> wrote: >> >> >> >> XOR got supported on Canvas 2D due to an artifact of it being a >> mapping of >> >> Apple's canvas/CoreGraphics APIs. It's at best poorly supported >> today, at >> >> least with any reasonable performance. >> >> >> >> I don't see any downside to proposing this extension, but I suspect >> that >> >> all the WebGL implementors are currently busy working on their WebGL 2 >> >> implementations, and even beyond that I'd suggest that GL ES >> 3.1-equivalent >> >> functionality would take precedence. Then again, it would not be a >> >> difficult extension to implement, especially if it was only exposed if >> the >> >> underlying graphics API had support. >> >> >> >> - Vlad >> >> >> >> >> >> On Tue, May 26, 2015 at 1:48 PM, Ashley Gullen >> wrote: >> >>> >> >>> TBH I don't care much for the xor effect, I don't think it's terribly >> >>> useful - it was a weird choice to support it in canvas2d - and if >> it's not >> >>> possible to support then that's fine by me. I'm more interested in the >> >>> photoshop style blends like screen and multiply. I'll do a little >> research >> >>> in to the D3D11 side of things and write a draft definition. >> >>> >> >>> Ashley >> >>> >> >>> >> >>> On 26 May 2015 at 17:09, Jukka Jyl?nki wrote: >> >>>> >> >>>> Direct3D 11.1 adds support for logic ops via blend states: >> >>>> >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404562%28v=vs.85%29.aspx#use_logical_operations_in_a_render_target >> >>>> , which is present on Windows 8 and Windows Phone 8. I am not sure >> if this >> >>>> is one of the "partial D3D11.1 support on Windows 7" features, could >> not >> >>>> find that page at a quick glance. In D3D11.1 one creates an >> immutable blend >> >>>> state that has the desired logic operation on a render target: >> >>>> >> >>>> ID3D11Device1::CreateBlendState1: >> >>>> >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404577(v=vs.85).aspx >> >>>> -> D3D11_BLEND_DESC1: >> >>>> >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404435(v=vs.85).aspx >> >>>> -> D3D11_RENDER_TARGET_BLEND_DESC1: >> >>>> >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404492(v=vs.85).aspx >> >>>> -> D3D11_LOGIC_OP: >> >>>> >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404484(v=vs.85).aspx >> >>>> >> >>>> >> >>>> 2015-05-26 18:54 GMT+03:00 Florian B?sch : >> >>>>> >> >>>>> A few remarks: >> >>>>> >> >>>>> glLogicOp interacts with the rest of the blending machinery, so >> >>>>> supporting blend equation advanced via that function might be >> tricky. Also >> >>>>> it'd be quite difficult to ensure non-coherent undefinedness using >> this >> >>>>> route. Fortunately the blend equation advanced extensions also >> exist for >> >>>>> desktop GL. However they're some of the very latest extensions in >> ARB >> >>>>> status, and so support might come in different (non ARB) flavours >> or not at >> >>>>> all. >> >>>>> >> >>>>> The blend barrier function should be no problem to support on the >> >>>>> extension object provided the extension is provided by the >> underlying >> >>>>> extension rather than emulated via other functionality. >> >>>>> >> >>>>> Support is difficult to gauge, but it's probably not great. This >> >>>>> capability index tracks it on desktop GL at 2% >> >>>>> http://feedback.wildfiregames.com/report/opengl/ >> >>>>> >> >>>>> I would guesstimate support on mobiles would be similarly low for >> the >> >>>>> time being. >> >>>>> >> >>>>> An open question would be how you get that behavior into Direct3D of >> >>>>> course. Can somebody elaborate on that point? >> >>>>> >> >>>>> Regardless of that, I'd encourage you to propose an extension >> >>>>> definition (via git pull request) for this functionality, this will >> help >> >>>>> direct the discussion away from idle speculation on a ML and into >> something >> >>>>> with real consequences for stakeholders (it's not real until you >> spec it). >> >>>>> >> >>>>> On Tue, May 26, 2015 at 5:40 PM, Jukka Jyl?nki >> >>>>> wrote: >> >>>>>> >> >>>>>> Currently neither GLES2 core or WebGL1 supports exclusive-or >> blending. >> >>>>>> Desktop OpenGL since something like 1.4 has had this and more via >> glLogicOp >> >>>>>> functionality: >> https://www.opengl.org/sdk/docs/man/html/glLogicOp.xhtml and >> >>>>>> GLES1.1 had it as well, but for some reason, GLES2 removed >> glLogicOp (I >> >>>>>> think GLES3 didn't add it back either, but my GL spec lawyer >> stamina is too >> >>>>>> low to actually check the pdf). Don't know the reason why since >> OpenGL >> >>>>>> decision making is not open in the public, but if I had to guess, >> some >> >>>>>> vendor x with chip y on OS z was not able to support it >> efficiently and >> >>>>>> wanted it gone, probably basing the argument on it not being a >> very common >> >>>>>> functionality, and/or that the renderable texture format family >> that was >> >>>>>> chosen to GLES2 core didn't feel appropriate enough. >> >>>>>> >> >>>>>> Not sure if glLogicOp support should be a prerequisite for >> >>>>>> WEBGL_blend_equation_advanced, though the other blend modes than >> xor sound >> >>>>>> like they don't need bitwise ops being supported. >> >>>>>> >> >>>>>> 2015-05-26 18:12 GMT+03:00 Ashley Gullen : >> >>>>>>> >> >>>>>>> KHR_blend_equation_advanced adds some interesting new color blend >> >>>>>>> modes such as multiply, screen, overlay and more. I think these >> warrant >> >>>>>>> particular attention on the web platform because they correspond >> to some of >> >>>>>>> the 2D context's more recent composite modes. Consider the >> mapping of >> >>>>>>> globalCompositeMode to OpenGL blend modes: >> >>>>>>> >> >>>>>>> "source-over", "source-in", "source-out", "source-atop", >> >>>>>>> "destination-over", "destination-in", "destination-out", >> "destination-atop", >> >>>>>>> "lighter", "copy": all possible with existing blend modes >> >>>>>>> "xor": don't know? >> >>>>>>> "multiply": MULTIPLY_KHR >> >>>>>>> "screen": SCREEN_KHR >> >>>>>>> "overlay": OVERLAY_KHR >> >>>>>>> "darken": DARKEN_KHR >> >>>>>>> "lighten": LIGHTEN_KHR >> >>>>>>> "color-dodge": COLORDODGE_KHR >> >>>>>>> "color-burn": COLORBURN_KHR >> >>>>>>> "hard-light": HARDLIGHT_KHR >> >>>>>>> "soft-light": SOFTLIGHT_KHR >> >>>>>>> "difference": DIFFERENCE_KHR >> >>>>>>> "exclusion": EXCLUSION_KHR >> >>>>>>> "hue": HSL_HUE_KHR >> >>>>>>> "saturation": HSL_SATURATION_KHR >> >>>>>>> "color": HSL_COLOR_KHR >> >>>>>>> "luminosity": HSL_LUMINOSITY_KHR >> >>>>>>> >> >>>>>>> The mapping is pretty much perfect. I don't know if there's a >> blend >> >>>>>>> mode that covers "xor", but if there is (and I'd be interested to >> know!) >> >>>>>>> then the mapping is perfect. >> >>>>>>> >> >>>>>>> This extension has a few use cases: >> >>>>>>> - Improve consistency across the web platform, by bringing the >> WebGL >> >>>>>>> and 2D context's capabilities closer together. This makes it >> easier to build >> >>>>>>> 2D WebGL applications that are equivalent to their canvas2d >> counterparts. >> >>>>>>> - make it easier to polyfill/extend/implement canvas2d via WebGL >> >>>>>>> (browser vendors may be interested in a JS implementation of >> >>>>>>> CanvasRenderingContext2D for performance reasons) >> >>>>>>> - provide useful blending modes without making authors resort to >> >>>>>>> writing their own shaders and having to know all the formulae >> involved >> >>>>>>> - provide a performance guarantee, since the blending uses >> >>>>>>> hardware/driver-authored implementations and minimises the >> necessary draw >> >>>>>>> calls/state changes to use these blend modes, avoiding inefficient >> >>>>>>> implementations by developers (or possibly even exceeding what >> they can >> >>>>>>> achieve even in the best case depending on if the driver uses any >> special >> >>>>>>> optimisations) >> >>>>>>> >> >>>>>>> It also appears to be a relatively small API surface, mainly >> >>>>>>> introducing new enums for blendEquation. >> >>>>>>> >> >>>>>>> Some questions/risks: >> >>>>>>> - I don't know what the GPU support for this is like in the wild >> >>>>>>> across desktop and mobile, although I've read it's part of the >> Android >> >>>>>>> Extension Pack which suggests some mobile support >> >>>>>>> - I don't know enough about this area to comment on the >> suitability >> >>>>>>> of the "coherent" version or the "blendBarrier" function's >> suitability in a >> >>>>>>> WebGL context >> >>>>>>> - if GPU support is not broad, developers may feel that a >> fallback is >> >>>>>>> still necessary so developers will need to write their own >> shaders for these >> >>>>>>> blend modes anyway, eliminating some of the benefits >> >>>>>>> >> >>>>>>> Still, these blend modes were deemed suitable for the 2D context >> so I >> >>>>>>> feel it would be useful to have them in WebGL too. In our >> particular case as >> >>>>>>> developers of a 2D HTML5 game engine, this would simplify our >> code and >> >>>>>>> improve consistency with the 2D context fallback. >> >>>>>>> >> >>>>>>> Ashley Gullen >> >>>>>>> Scirra.com >> >>>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Tue Aug 21 05:56:16 2018 From: ash...@ (Ashley Gullen) Date: Tue, 21 Aug 2018 13:56:16 +0100 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: Message-ID: OK, PR created: https://github.com/KhronosGroup/WebGL/pull/2697 On 21 August 2018 at 12:54, Florian B?sch wrote: > I'd suggest you just make a pull request for the extension proposal to > spec repo. > > On Tue, Aug 21, 2018 at 12:56 AM Ashley Gullen wrote: > >> We've been finding lately that rendering advanced blending effects with a >> shader via an intermediate texture has a high performance overhead, >> especially when rendering many sprites. Given that WebGL 2 is out, and >> according to gpuinfo.org desktop support is ~46% and mobile support >> ~31%, would it be worth revisiting this? Only supporting it when backed by >> the driver would be fine. >> >> >> On 27 May 2015 at 01:24, Kenneth Russell wrote: >> >>> The majority of the work in exposing this extension would be writing >>> conformance tests. It looks like the drawElements test suite has some >>> tests of this extension: >>> https://android.googlesource.com/platform/external/deqp/+/ >>> master/modules/gles31/functional/es31fAdvancedBlendTests.cpp >>> . They'd need to be ported to JavaScript and WebGL. >>> >>> Given that device support for the extension is pretty low, though, >>> it'd be more profitable to write a JavaScript library that would >>> either provide similar functionality to this extension, or polyfill it >>> altogether. Assuming there's no support for it in the OpenGL driver, >>> implementing this extension in the browser won't make it run >>> significantly faster than a JavaScript implementation. The same >>> technique of ping-ponging the source and destination textures and >>> implementing the blending equations in a shader can be implemented >>> with basically the same speed in JavaScript as it can in the WebGL >>> implementation -- and if that's not the case, then that's something >>> that needs to be fixed in the browser to make all WebGL apps run >>> faster. >>> >>> Fixing bugs and passing the WebGL 2.0 conformance suite is at the top >>> of our priority list right now -- so I'd agree with Vlad's assessment >>> that this particular extension shouldn't delay that work. >>> >>> -Ken >>> >>> >>> >>> On Tue, May 26, 2015 at 3:34 PM, Ashley Gullen >>> wrote: >>> > I'm not sure how to mark up a proposal or how the whole pull request >>> thing >>> > is supposed to be done, so I drafted a proposal and I'm just attaching >>> it as >>> > a .txt file. Someone can do something more official with this if they >>> like! >>> > >>> > On 26 May 2015 at 20:42, Vladimir Vukicevic >>> wrote: >>> >> >>> >> XOR got supported on Canvas 2D due to an artifact of it being a >>> mapping of >>> >> Apple's canvas/CoreGraphics APIs. It's at best poorly supported >>> today, at >>> >> least with any reasonable performance. >>> >> >>> >> I don't see any downside to proposing this extension, but I suspect >>> that >>> >> all the WebGL implementors are currently busy working on their WebGL 2 >>> >> implementations, and even beyond that I'd suggest that GL ES >>> 3.1-equivalent >>> >> functionality would take precedence. Then again, it would not be a >>> >> difficult extension to implement, especially if it was only exposed >>> if the >>> >> underlying graphics API had support. >>> >> >>> >> - Vlad >>> >> >>> >> >>> >> On Tue, May 26, 2015 at 1:48 PM, Ashley Gullen >>> wrote: >>> >>> >>> >>> TBH I don't care much for the xor effect, I don't think it's terribly >>> >>> useful - it was a weird choice to support it in canvas2d - and if >>> it's not >>> >>> possible to support then that's fine by me. I'm more interested in >>> the >>> >>> photoshop style blends like screen and multiply. I'll do a little >>> research >>> >>> in to the D3D11 side of things and write a draft definition. >>> >>> >>> >>> Ashley >>> >>> >>> >>> >>> >>> On 26 May 2015 at 17:09, Jukka Jyl?nki wrote: >>> >>>> >>> >>>> Direct3D 11.1 adds support for logic ops via blend states: >>> >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ >>> hh404562%28v=vs.85%29.aspx#use_logical_operations_in_a_render_target >>> >>>> , which is present on Windows 8 and Windows Phone 8. I am not sure >>> if this >>> >>>> is one of the "partial D3D11.1 support on Windows 7" features, >>> could not >>> >>>> find that page at a quick glance. In D3D11.1 one creates an >>> immutable blend >>> >>>> state that has the desired logic operation on a render target: >>> >>>> >>> >>>> ID3D11Device1::CreateBlendState1: >>> >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ >>> hh404577(v=vs.85).aspx >>> >>>> -> D3D11_BLEND_DESC1: >>> >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ >>> hh404435(v=vs.85).aspx >>> >>>> -> D3D11_RENDER_TARGET_BLEND_DESC1: >>> >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ >>> hh404492(v=vs.85).aspx >>> >>>> -> D3D11_LOGIC_OP: >>> >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ >>> hh404484(v=vs.85).aspx >>> >>>> >>> >>>> >>> >>>> 2015-05-26 18:54 GMT+03:00 Florian B?sch : >>> >>>>> >>> >>>>> A few remarks: >>> >>>>> >>> >>>>> glLogicOp interacts with the rest of the blending machinery, so >>> >>>>> supporting blend equation advanced via that function might be >>> tricky. Also >>> >>>>> it'd be quite difficult to ensure non-coherent undefinedness using >>> this >>> >>>>> route. Fortunately the blend equation advanced extensions also >>> exist for >>> >>>>> desktop GL. However they're some of the very latest extensions in >>> ARB >>> >>>>> status, and so support might come in different (non ARB) flavours >>> or not at >>> >>>>> all. >>> >>>>> >>> >>>>> The blend barrier function should be no problem to support on the >>> >>>>> extension object provided the extension is provided by the >>> underlying >>> >>>>> extension rather than emulated via other functionality. >>> >>>>> >>> >>>>> Support is difficult to gauge, but it's probably not great. This >>> >>>>> capability index tracks it on desktop GL at 2% >>> >>>>> http://feedback.wildfiregames.com/report/opengl/ >>> >>>>> >>> >>>>> I would guesstimate support on mobiles would be similarly low for >>> the >>> >>>>> time being. >>> >>>>> >>> >>>>> An open question would be how you get that behavior into Direct3D >>> of >>> >>>>> course. Can somebody elaborate on that point? >>> >>>>> >>> >>>>> Regardless of that, I'd encourage you to propose an extension >>> >>>>> definition (via git pull request) for this functionality, this >>> will help >>> >>>>> direct the discussion away from idle speculation on a ML and into >>> something >>> >>>>> with real consequences for stakeholders (it's not real until you >>> spec it). >>> >>>>> >>> >>>>> On Tue, May 26, 2015 at 5:40 PM, Jukka Jyl?nki >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> Currently neither GLES2 core or WebGL1 supports exclusive-or >>> blending. >>> >>>>>> Desktop OpenGL since something like 1.4 has had this and more via >>> glLogicOp >>> >>>>>> functionality: https://www.opengl.org/sdk/ >>> docs/man/html/glLogicOp.xhtml and >>> >>>>>> GLES1.1 had it as well, but for some reason, GLES2 removed >>> glLogicOp (I >>> >>>>>> think GLES3 didn't add it back either, but my GL spec lawyer >>> stamina is too >>> >>>>>> low to actually check the pdf). Don't know the reason why since >>> OpenGL >>> >>>>>> decision making is not open in the public, but if I had to guess, >>> some >>> >>>>>> vendor x with chip y on OS z was not able to support it >>> efficiently and >>> >>>>>> wanted it gone, probably basing the argument on it not being a >>> very common >>> >>>>>> functionality, and/or that the renderable texture format family >>> that was >>> >>>>>> chosen to GLES2 core didn't feel appropriate enough. >>> >>>>>> >>> >>>>>> Not sure if glLogicOp support should be a prerequisite for >>> >>>>>> WEBGL_blend_equation_advanced, though the other blend modes than >>> xor sound >>> >>>>>> like they don't need bitwise ops being supported. >>> >>>>>> >>> >>>>>> 2015-05-26 18:12 GMT+03:00 Ashley Gullen : >>> >>>>>>> >>> >>>>>>> KHR_blend_equation_advanced adds some interesting new color blend >>> >>>>>>> modes such as multiply, screen, overlay and more. I think these >>> warrant >>> >>>>>>> particular attention on the web platform because they correspond >>> to some of >>> >>>>>>> the 2D context's more recent composite modes. Consider the >>> mapping of >>> >>>>>>> globalCompositeMode to OpenGL blend modes: >>> >>>>>>> >>> >>>>>>> "source-over", "source-in", "source-out", "source-atop", >>> >>>>>>> "destination-over", "destination-in", "destination-out", >>> "destination-atop", >>> >>>>>>> "lighter", "copy": all possible with existing blend modes >>> >>>>>>> "xor": don't know? >>> >>>>>>> "multiply": MULTIPLY_KHR >>> >>>>>>> "screen": SCREEN_KHR >>> >>>>>>> "overlay": OVERLAY_KHR >>> >>>>>>> "darken": DARKEN_KHR >>> >>>>>>> "lighten": LIGHTEN_KHR >>> >>>>>>> "color-dodge": COLORDODGE_KHR >>> >>>>>>> "color-burn": COLORBURN_KHR >>> >>>>>>> "hard-light": HARDLIGHT_KHR >>> >>>>>>> "soft-light": SOFTLIGHT_KHR >>> >>>>>>> "difference": DIFFERENCE_KHR >>> >>>>>>> "exclusion": EXCLUSION_KHR >>> >>>>>>> "hue": HSL_HUE_KHR >>> >>>>>>> "saturation": HSL_SATURATION_KHR >>> >>>>>>> "color": HSL_COLOR_KHR >>> >>>>>>> "luminosity": HSL_LUMINOSITY_KHR >>> >>>>>>> >>> >>>>>>> The mapping is pretty much perfect. I don't know if there's a >>> blend >>> >>>>>>> mode that covers "xor", but if there is (and I'd be interested >>> to know!) >>> >>>>>>> then the mapping is perfect. >>> >>>>>>> >>> >>>>>>> This extension has a few use cases: >>> >>>>>>> - Improve consistency across the web platform, by bringing the >>> WebGL >>> >>>>>>> and 2D context's capabilities closer together. This makes it >>> easier to build >>> >>>>>>> 2D WebGL applications that are equivalent to their canvas2d >>> counterparts. >>> >>>>>>> - make it easier to polyfill/extend/implement canvas2d via WebGL >>> >>>>>>> (browser vendors may be interested in a JS implementation of >>> >>>>>>> CanvasRenderingContext2D for performance reasons) >>> >>>>>>> - provide useful blending modes without making authors resort to >>> >>>>>>> writing their own shaders and having to know all the formulae >>> involved >>> >>>>>>> - provide a performance guarantee, since the blending uses >>> >>>>>>> hardware/driver-authored implementations and minimises the >>> necessary draw >>> >>>>>>> calls/state changes to use these blend modes, avoiding >>> inefficient >>> >>>>>>> implementations by developers (or possibly even exceeding what >>> they can >>> >>>>>>> achieve even in the best case depending on if the driver uses >>> any special >>> >>>>>>> optimisations) >>> >>>>>>> >>> >>>>>>> It also appears to be a relatively small API surface, mainly >>> >>>>>>> introducing new enums for blendEquation. >>> >>>>>>> >>> >>>>>>> Some questions/risks: >>> >>>>>>> - I don't know what the GPU support for this is like in the wild >>> >>>>>>> across desktop and mobile, although I've read it's part of the >>> Android >>> >>>>>>> Extension Pack which suggests some mobile support >>> >>>>>>> - I don't know enough about this area to comment on the >>> suitability >>> >>>>>>> of the "coherent" version or the "blendBarrier" function's >>> suitability in a >>> >>>>>>> WebGL context >>> >>>>>>> - if GPU support is not broad, developers may feel that a >>> fallback is >>> >>>>>>> still necessary so developers will need to write their own >>> shaders for these >>> >>>>>>> blend modes anyway, eliminating some of the benefits >>> >>>>>>> >>> >>>>>>> Still, these blend modes were deemed suitable for the 2D context >>> so I >>> >>>>>>> feel it would be useful to have them in WebGL too. In our >>> particular case as >>> >>>>>>> developers of a 2D HTML5 game engine, this would simplify our >>> code and >>> >>>>>>> improve consistency with the 2D context fallback. >>> >>>>>>> >>> >>>>>>> Ashley Gullen >>> >>>>>>> Scirra.com >>> >>>>>>> >>> >>>>>> >>> >>>>> >>> >>>> >>> >>> >>> >> >>> > >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: