[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 Thu, May 27, 2010 at 3:01 AM, Jonatan Wallmander <firstname.lastname@example.org> wrote:
> On 05/27/2010 05:27 AM, Steve Baker wrote:
>> Cedric Vivier wrote:
>>> On Thu, May 27, 2010 at 10:18, Steve Baker<email@example.com
>>> <mailto:firstname.lastname@example.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
>> Well - it certainly behaves as if it's not hardware accelerated,
>> 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
> 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
>>> 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.
What specific Linux version and graphics hardware are you running?
Chromium's WebGL port on Linux is working on the machines we have in
house to test on (generally Ubuntu 8.0x with fairly recent NVIDIA
hardware). There are a couple of reports of WebGL not running on
Linux, one of which was a bug in the X server:
> 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
> 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 email@example.com.
> To unsubscribe, send an email to firstname.lastname@example.org with
> the following command in the body of your email:
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: