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

Re: [Public WebGL] Context creation flag proposal: "failIfMajorPerformanceCaveat"



I am an outsider so don't give much weight to my ideas.

I am from the world of OpenGL/DirectX were things are explicit and
probably complex.  With WebGL I understand there was an attempt to
make everything more automagical and I guess this fits in that
pattern.

I guess I am just used to specifically asking for no software
rendering when creating contexts in DirectX and this seems to fall
into that case.  Couldn't that be an alternative that is based around
requiring specific capabilities such as (1) no software rendering or
(2) no software compositing or asking for (3) a pure hardware context
be clearer and easier to use and implement?  I can imagine just
starting with one or two of these three flags.  This proposed flag
seems like a way of capturing a specific capability query (what is
required to make Google Maps work well) into a single flag, but that
isn't a general approach even if it solves the Google Maps issue.
Different applications of WebGL will have different WebGL bottlenecks.

Best regards,
-ben

On Tue, Sep 17, 2013 at 7:23 AM, Ashley Gullen <ashley@scirra.com> wrote:
> Also in support of this. We develop a 2D HTML5 game engine and want to avoid
> software-rendered WebGL and instead fall back to canvas 2D (which can be
> faster even when also software rendered, but could also be GPU accelerated
> when WebGL isn't). We currently implement this by looking at the WebGL
> extensions of Chrome's software renderer. A better way to do this would be
> welcome.
>
> Ashley
>
>
>
> On 17 September 2013 12:15, Olli Etuaho <oetuaho@nvidia.com> wrote:
>>
>>
>> A flag like this would be very useful. I don't think that needing a CPU
>> readback is necessarily a sufficient condition to fail with the flag, that's
>> just a constant overhead per composited frame which might be small compared
>> to all the other things the WebGL app is doing, but running on software
>> emulation would definitely be a good reason to fail if the flag is set.
>> ________________________________________
>> From: owner-public_webgl@khronos.org [owner-public_webgl@khronos.org] On
>> Behalf Of James Darpinian [jdarpinian@google.com]
>> Sent: Tuesday, September 17, 2013 6:05 AM
>> To: ben@exocortex.com; jsremi@gmail.com
>> Cc: public webgl
>> Subject: Re: [Public WebGL] Context creation flag proposal:
>> "failIfMajorPerformanceCaveat"
>>
>> "Major" would, by necessity, be implementation defined. However I believe
>> the guideline "drastically slower than a native app making equivalent OpenGL
>> calls" can make the decision unambiguous in almost all cases.
>>
>> Unfortunately exposing more information about the user's GPU has been
>> proposed and shot down repeatedly due to complexity and user privacy
>> concerns. I don't believe there's a perfect solution to this problem which
>> is simple and respects user privacy while remaining completely
>> non-subjective. Some kind of compromise solution is necessary to get past
>> this impasse. By accepting some subjectivity in the definition of "major" we
>> can make progress, even if it's not the ideal solution for everyone.
>>
>>
>> On Mon, Sep 16, 2013 at 6:32 PM, Ben Houston
>> <ben@exocortex.com<mailto:ben@exocortex.com>> wrote:
>>
>> This is a subjective condition. What is major? Major may not mean the same
>> thing to different people and it depends on what webgl features one is using
>> and which are degraded. Instead one should just query for what is actually
>> being done, is there gpu read back for software composting or other such
>> things going on. This would be more specific and less ambiguous. Also
>> sometimes gpu read back is fast such as for integrated graphics. Thus even
>> this is not indicative of performance. I think this is generally problematic
>> and ambiguous.
>>
>> Sent from my phone.
>>
>> On Sep 16, 2013 7:49 PM, "James Darpinian"
>> <jdarpinian@google.com<mailto:jdarpinian@google.com>> wrote:
>> I'd like to propose a new context creation flag to help WebGL apps make
>> better decisions about performance tradeoffs:
>> "failIfMajorPerformanceCaveat".
>>
>> The problem:
>>
>> The problem we're facing is that WebGL sometimes offers drastically
>> reduced performance compared to what you would expect given the hardware
>> it's running on. For example, if a machine has a GPU that is blacklisted for
>> WebGL, the browser might use a software renderer that is much slower. Or, if
>> the browser is using a software compositor, it might have to readback the
>> WebGL framebuffer into system memory before drawing it to the screen.
>>
>> For apps that aren't full-screen or otherwise don't stress performance too
>> much, these reduced-performance modes can work fine, so we don't want to
>> simply disable WebGL in these cases. However, many apps don't work well in
>> these reduced-performance modes. Apps that have a fallback rendering path
>> (e.g. a 2D canvas mode) might prefer to use it instead of a
>> reduced-performance WebGL context, but right now there's no way for apps to
>> tell when WebGL is in a reduced-performance mode (vs. the user's machine
>> just generally being slow).
>>
>> The proposal:
>>
>> "failIfMajorPerformanceCaveat" would default to false. When
>> "failIfMajorPerformanceCaveat" is true, context creation would fail if WebGL
>> is known to be drastically slower than a native app making equivalent OpenGL
>> calls.
>>
>> This means, for example, that context creation would fail if the browser
>> has to readback the WebGL framebuffer into system memory before drawing it
>> to the screen. Context creation would also fail if the browser is using a
>> software renderer due to the user's GPU being blacklisted for WebGL. In
>> these cases apps could switch to a fallback rendering path, or try again
>> with "failIfMajorPerformanceCaveat:false" and the knowledge that they should
>> use a low-resolution mode.
>>
>> Thoughts? Alternate naming suggestions?
>>
>>
>> -----------------------------------------------------------
>> 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
>> -----------------------------------------------------------
>>
>



-- 
Best regards,
Ben Houston
Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom
http://Exocortex.com - Passionate CG Software Professionals.

-----------------------------------------------------------
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
-----------------------------------------------------------