[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 12:00 PM, Jonatan Wallmander <jonatan@vovoid.com> wrote:
> On 05/27/2010 07:44 PM, Kenneth Russell wrote:
>>
>> On Thu, May 27, 2010 at 3:01 AM, Jonatan Wallmander<jonatan@vovoid.com>
>>  wrote:
>>>
>>> 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).
>>> (http://www.youtube.com/watch?v=cz9iI98WtK8)
>>>
>>> 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.
>>
>> 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:
>>
>> http://crbug.com/44226
>> http://crbug.com/44590
>>
>> -Ken
>
> Good to hear!
>
> I'm on ubuntu 10.04, Nvidia GTX 480 (fermi) with beta drivers (256.25).
> X server 1.8.1 (10801000). Using these drivers since there was bugs in the
> implementation (point sprite shader uv coords) in the regular drivers.
>
> But if I recall correctly this was how it ran with my 9800 GTX with 180.xx
> something drivers
> as well.
>
> Supplying some output from GDB, I braked 3 times.
> Not sure if it helps...
>
> #0  0x00110832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1  0x00f76ac9 in shmdt (shmaddr=0xb046f000) at
> ../sysdeps/unix/sysv/linux/shmdt.c:34
> #2  0x087a9024 in TransportDIB::~TransportDIB() ()
> #3  0x084c9b68 in void
> STLDeleteContainerPairSecondPointers<std::_Rb_tree_iterator<std::pair<int
> const, TransportDIB*> > >(std::_Rb_tree_iterator<std::pair<int const,
> TransportDIB*> >, std::_Rb_tree_iterator<std::pair<int const, TransportDIB*>
>>) ()
> #4  0x084c9ba9 in BrowserRenderProcessHost::ClearTransportDIBCache() ()
> #5  0x084cea52 in base::DelayTimer<BrowserRenderProcessHost>::Check() ()
> #6  0x087568f9 in MessageLoop::RunTask(Task*) ()
> #7  0x087569ca in
> MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) ()
> #8  0x08756b1c in MessageLoop::DoDelayedWork(base::Time*) ()
> #9  0x08779e4b in base::MessagePumpForUI::HandleDispatch() ()
> #10 0x08779e66 in (anonymous namespace)::WorkSourceDispatch(_GSource*, int
> (*)(void*), void*) ()
> #11 0x008645e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
> #12 0x008682d8 in ?? () from /lib/libglib-2.0.so.0
> #13 0x008684b8 in g_main_context_iteration () from /lib/libglib-2.0.so.0
> #14 0x0877a060 in
> base::MessagePumpForUI::RunWithDispatcher(base::MessagePump::Delegate*,
> base::MessagePumpForUI::Dispatcher*) ()
> #15 0x08779e06 in base::MessagePumpForUI::Run(base::MessagePump::Delegate*)
> ()
> #16 0x087555e1 in MessageLoop::RunInternal() ()
> #17 0x0875569a in MessageLoopForUI::Run(base::MessagePumpForUI::Dispatcher*)
> ()
> #18 0x08051a23 in BrowserMain(MainFunctionParams const&) ()
> #19 0x0804a968 in ChromeMain ()
> #20 0x0804ad02 in main ()
> (gdb) cont
> Continuing.
> ^C
> Program received signal SIGINT, Interrupt.
> 0x00110832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> (gdb) bt
> #0  0x00110832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1  0x00f66b86 in *__GI___poll (fds=0xffcff4, nfds=9, timeout=30) at
> ../sysdeps/unix/sysv/linux/poll.c:87
> #2  0x008754eb in g_poll () from /lib/libglib-2.0.so.0
> #3  0x008680ac in ?? () from /lib/libglib-2.0.so.0
> #4  0x008684b8 in g_main_context_iteration () from /lib/libglib-2.0.so.0
> #5  0x0877a060 in
> base::MessagePumpForUI::RunWithDispatcher(base::MessagePump::Delegate*,
> base::MessagePumpForUI::Dispatcher*) ()
> #6  0x08779e06 in base::MessagePumpForUI::Run(base::MessagePump::Delegate*)
> ()
> #7  0x087555e1 in MessageLoop::RunInternal() ()
> #8  0x0875569a in MessageLoopForUI::Run(base::MessagePumpForUI::Dispatcher*)
> ()
> #9  0x08051a23 in BrowserMain(MainFunctionParams const&) ()
> #10 0x0804a968 in ChromeMain ()
> #11 0x0804ad02 in main ()
> (gdb) cont
> Continuing.
> ^C
> Program received signal SIGINT, Interrupt.
> 0x00110832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> (gdb) bt
> #0  0x00110832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1  0x00f66b86 in *__GI___poll (fds=0xffcff4, nfds=9, timeout=30) at
> ../sysdeps/unix/sysv/linux/poll.c:87
> #2  0x008754eb in g_poll () from /lib/libglib-2.0.so.0
> #3  0x008680ac in ?? () from /lib/libglib-2.0.so.0
> #4  0x008684b8 in g_main_context_iteration () from /lib/libglib-2.0.so.0
> #5  0x0877a060 in
> base::MessagePumpForUI::RunWithDispatcher(base::MessagePump::Delegate*,
> base::MessagePumpForUI::Dispatcher*) ()
> #6  0x08779e06 in base::MessagePumpForUI::Run(base::MessagePump::Delegate*)
> ()
> #7  0x087555e1 in MessageLoop::RunInternal() ()
> #8  0x0875569a in MessageLoopForUI::Run(base::MessagePumpForUI::Dispatcher*)
> ()
> #9  0x08051a23 in BrowserMain(MainFunctionParams const&) ()
> #10 0x0804a968 in ChromeMain ()
> #11 0x0804ad02 in main ()

The above stack traces are coming from Chrome's main, "browser"
process. The web content is run in a subordinate "renderer" process,
and further, WebGL's OpenGL calls are issued from a third, "GPU",
process. You can see the various process IDs by running "ps -aux |
grep chrome" and look for the "--type=" command line arguments.
Typically when debugging Chrome you need to run with a command line
argument like --renderer-startup-dialog or --gpu-startup-dialog ; the
browser will then print out the PID of sub-processes and wait for you
to attach a gdb. (You may need to continue it with "signal SIGUSR1";
don't remember for sure.) If you have a chance to try to gather more
information about what's going wrong on your system, that would be
great; even if not, please file a bug regardless and assign it to me
(my username @chromium.org).

-Ken

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