915446 - Implement failIfMajorPerformanceCaveat WebGL context creation flag

Status: RESOLVED DUPLICATE of bug 1164970

(Core :: Graphics: CanvasWebGL, defect)

Description

[James Darpinian]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.28 Safari/537.36

Steps to reproduce:

When accelerated layers aren't available, WebGL content is painted through a very slow path that does a readback of the WebGL framebuffer from the GPU into system memory every frame. This causes poor performance and even whole-system slowdowns where e.g. mouse pointer movement becomes laggy.

WebGL apps want a way to specify at context creation time that they do not want this slow readback path, preferring context creation to fail in cases where fast painting cannot be guaranteed.

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

This is a spec issue, so the right place for this is the public_webgl list.

But this is unlikely to gain much traction for the following reasons.

What you really want is to avoid slow WebGL, and readbacks are just one out of many ways that WebGL can be slow, and conversely, readbacks aren't even necessarily the main cause of slowness --- that depends on many factors, many of which are internal to the drivers.

'The compositor does readbacks to implement the compositing of the WebGL canvas' is a far more implementation-specific notion than anything we currently expose in the WebGL spec. We've been staying away from exposing this sort of details because exposing that kind of thing is a way to make non-future-proof specs.

And if we go down this route, there are many other things that you will need to know as well, like: is WebGL implemented using a software GL renderer? Are some WebGL features falling back to software rendering? (e.g. Intel 945 chipsets supporting Direct3D 9, but with software fallbacks for vertex shaders) or is WebGL otherwise letting you run into device-specific slow paths (like Geforce 7 cards hitting a slow path on vertex-shader texture fetches)...? The list of things that you will similarly need to know is fairly long.

Or, you could just take a different route that lets you solve the problem of slow WebGL without special cases and without waiting for browser vendors to agree on a spec change and implement it:

You could simply benchmark it in your application.

Here, you need to benchmark compositing performance, so make sure to measure the time interval between consecutive requestAnimationFrame callbacks.

Comment 2

[James Darpinian]

> And if we go down this route, there are many other things that you will need to know as well

Sorry, I think I haven't been clear. What you're saying is that Firefox can't answer the question "Will WebGL be too slow for my app?" You're absolutely right. Performance is dependent on many complex hardware-specific factors and ultimately can only be determined by benchmarking. WebGL apps should always benchmark and have a fallback for machines with poor performance. We are doing that.

The question I want Firefox to answer is different. Normally, WebGL provides near-native rendering performance. That is, if you wrote a native app that made the same GL calls, the performance would be similar. When readbacks are happening, that's no longer true. WebGL performance is always much worse than native. A trivial fullscreen WebGL app that does nothing but call glClear() gets <25 FPS when readbacks are happening. Even non-fullscreen apps that can still hit 60 FPS with readbacks will use *much* more CPU time and power/heat/battery to do so than a native app. That tradeoff may be acceptable for some apps, but it's definitely not acceptable for all.

So the question I want Firefox to answer is: "Will WebGL be much slower than the native hardware performance?" For the readback case, the answer is clearly yes. For the case of a device-specific slow path like software vertex processing, the answer is no, because WebGL can provide the same performance that a native app would get.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

I sort of agree that knowing whether there is a known major performance caveat in our WebGL pipeline, is useful to application developers, and that can be phrased in a portable enough way. "failIfMajorPerformanceCaveat" sounds more acceptable to me than "failIfReabackBasedCompositing" because the latter is a detail.

But what makes me still uncomfortable with this is that I still believe that you'll need to know many more things, because I still don't agree with that part:
 
> So the question I want Firefox to answer is: "Will WebGL be much slower than
> the native hardware performance?" For the readback case, the answer is
> clearly yes. For the case of a device-specific slow path like software
> vertex processing, the answer is no, because WebGL can provide the same
> performance that a native app would get.

I doubt that "Will WebGL be much slower than the native hardware performance?" is the question that you actually want to answer. Typically, you have a Web application that can choose between a WebGL path and a non-WebGL path, but it will remain a Web application anyway. You don't have the option of running as a "native" application. So, I don't see how it can be relevant to know if you could be as fast as "native". It rather seems like what you need to know is whether the WebGL path would perform decently compared to the non-WebGL, but still Web, path. That's where the long tail of other WebGL performance issues (shared with native GL apps) kicks in. Let's continue with the example of slow vertex shaders. Sure, WebGL and native GL apps would be equally affected by that. But your non-GL (say, Canvas 2D or non-Canvas) path will probably dodge that kind of issues altogether. So you could find yourself in a situation where both your WebGL path and a native GL path would run slow, but your non-GL path would run faster. In that case, a "failIfMajorPerformanceCaveat" context creation flag won't help. What's your take on that?

At this point, if the answer is "sure, but having failIfMajorPerformanceCaveat allows me to avoid the experience degradation at least for the majority of cases, and that's good enough for me", then I guess I don't have a strong objection, but I'd like to let Jeff and Vlad chime in.

Comment 4

[James Darpinian]

(In reply to Benoit Jacob [:bjacob] from comment #3)
> "failIfMajorPerformanceCaveat"
> sounds more acceptable to me than "failIfReabackBasedCompositing" because
> the latter is a detail.

Agreed.

> You don't have the option of running as a "native" application. So, I don't see how it can
> be relevant to know if you could be as fast as "native". It rather seems
> like what you need to know is whether the WebGL path would perform decently
> compared to the non-WebGL, but still Web, path.

You're right, but I think the latter question is unfortunately too application-dependent for Firefox to be able to answer it for us. The question of whether "native" performance is achievable is easier to answer and still helpful as input into our performance decisions.

> At this point, if the answer is "sure, but having
> failIfMajorPerformanceCaveat allows me to avoid the experience degradation
> at least for the majority of cases, and that's good enough for me", then I
> guess I don't have a strong objection, but I'd like to let Jeff and Vlad
> chime in.

Yes, that's about right. I'll put together a proposal for the public_webgl mailing list so we can get more input and hopefully consensus.

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

Sounds good, please do and let that conversation continue there.

Comment 6

[James Darpinian]

failIfMajorPerformanceCaveat was discussed on the public_webgl list and at WebGL F2F meetings, and is now in the draft spec.