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

Re: [Public WebGL] WebGL performance...seems like I have no hardware acceleration?!?

On 05/27/2010 05:27 AM, Steve Baker wrote:
Cedric Vivier wrote:
On Thu, May 27, 2010 at 10:18, Steve Baker<steve@sjbaker.org
<mailto:steve@sjbaker.org>>  wrote:

     So it looks like we're either not running with hardware acceleration -
     or there is some kind of software operation on the raster going on
     that's crippling the frame rate.

Your results are surprising, are you sure Firefox is using hardware acceleration on your setup ? (you should see a message about failure to create a pbuffer in the Javascript console if not)
Well - it certainly behaves as if it's not hardware accelerated,
performance-wise - but the JavaScript console says:

   Canvas 3D: creating PBuffer...
   Canvas 3D: ready

...and nothing else.  So I guess that's OK.  I actually tried turning
software rendering on via "webgl.software_render=true" in the
about:config page, when I do that, I don't get a valid context (probably
because I don't have Mesa installed).  So it's pretty much certain that
I do have hardware acceleration turned on...it's just spectacularly slow
for some weird reason.

But then, what could WebGL possibly be doing to make glclear take so
much per-pixel time if the hardware is doing the work?

Firefox (currently or used to) work like this which is probably what you're experiencing:

GPU Pbuffer -> RAM -> CPU software compositor -> RAM -> GPU
...which is why even a simple blit at high resolution is slow.

As a side effect this introduces vsync tearing issues when the
desktop lacks a compositor/isn't double-buffered/vsynced (win7 without aero, linux without compiz).

This will be fixed when/if the browsers move to a OpenGL compositor and that is the plan for firefox
(I lack information to draw any conclusions about chromium). Then the rendering would be done in an FBO,
and if the page lacks other elements to composit it will be 99.9% fast. Combined with the one-process-per-tab
architecture which firefox is also implementing (which chrome already has) there will be very little obstructing
the performance of a game (in theory).

Firefox devs are working on all this but I don't know status.

     I'm running the latest daily builds of
     FireFox "minefield" - and I've double-checked that I have software
     rendering disabled in the 'about:config' system.  I'm running Linux on
     one machine, WinXP on another and Windows-7 on a third - and getting
     pretty consistent results on all three machines.

There is an ongoing refactoring of the rendering code in Firefox, this might impact you if some of this has been pushed to Minefield daily builds (?) For instance, on Linux, _trunk_ cannot create a hardware-accelerated WebGL context anymore without applying work-in-progress patch from : https://bugzilla.mozilla.org/show_bug.cgi?id=565833 .

Maybe you should try running WebGL with latest Chromium to check if
you get same results or not.
Yeah - I guess I should try that.

Chromium-latest-linux32 is also broken (just tested it), it hangs whenever opening a page. Can't say what the windows/mac versions are like though.

Actually - I can live with poor frame rates for now - I just want to be
sure that they'll get back to something reasonable before I get to the
point of wanting to release my work in a few months time.   If there is
some fundamental reason why these kinds of performance figures are
"normal" - then I guess I'll drop the idea of porting games.

This is my current opinion as well. However I have every belief it'll turn out good in the end.

A dream scenario would be great to have some kind of dev platform in the meantime - some kind of
nightly build that is at least performing and working well even if it compromises
some design goals - for us end users to tinker with. It'd be worth a lot for webGL having
good content when the implementations are stable. Just a thought.

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: