Comments for cairo-ickle

Comment on You want threads, why not Zoidberg? by ickle

ickle — Sun, 27 Jan 2013 10:47:02 +0000

What type of comparison are you looking for? At the end there I tried to show that if throw more cpu cores at the problem (in order to try and saturate memory bandwidth) performance of the CPU backend is a match for the integrated GPUs – at least on this machine with a beastly CPU and weak GPU.

Comment on You want threads, why not Zoidberg? by liam

liam — Sun, 27 Jan 2013 00:28:40 +0000

Hi ickle,

Could you throw up an xlib comparison?

Comment on You want threads, why not Zoidberg? by ssvb

ssvb — Sat, 26 Jan 2013 08:09:59 +0000

Thanks for the nice charts! This for most parts confirms the results of my older test with using multiple threads to speed up pixman:

http://comments.gmane.org/gmane.comp.graphics.pixman/2008

At that time I came to a conclusion that it’s better to still keep multi-threaded rendering as a trump card and concentrate on single-threaded performance for now, especially considering that SSE2 backend still has a lot of room for improvement. Spawning multiple rendering threads can starve the application thread, which is not very nice and may result in worse overall experience for the users (the cairo-perf-trace, while being a great benchmarking tool, does not simulate this aspect adequately). IMHO it is better to be “green” and still provide reasonably good overall performance than hogging all the CPU cores. LLVMPipe is particularly badly behaved in this respect.

Still there is also “offloading” factor. When we are doing client side rendering (image backend), the client calls to the pixman library relayed from cairo are blocked until the operation is complete. It might make sense to try non-blocking asynchronous rendering with one (or more) worker thread doing all the heavy-lifting job with the pixel data. This is about the only real performance advantage (when the IPC overhead does not outweight it) currently offered by doing rendering in a separate X server process with the DDX drivers having purely software backend such as xf86-video-fbdev and xf86-video-modesetting.

Comment on Any old Ion? by Anon

Anon — Wed, 23 Jan 2013 17:34:28 +0000

Old iron, old iron!

Comment on Any old Ion? by Nouveau Can Beat NVIDIA With Cairo In Select Cases | The Linux Site

Nouveau Can Beat NVIDIA With Cairo In Select Cases | The Linux Site — Wed, 23 Jan 2013 16:11:10 +0000

[...] publicly shared his test results from Nouveau and the NVIDIA 304.64 and NVIDIA 313.18 drivers in this blog post. “The Nvidia ion GPU was released a few years back to cater for the low power netbook market [...]

Comment on VideoHackfest by ickle

ickle — Tue, 22 Jan 2013 13:55:57 +0000

No, cairo-gl is a different backend that you can use instead of the regular image or X backends. That is, with a GtkDrawingArea you might choose to use cairo-xlib to render directly into the surface created for you by Gtk. Or you may choose to use that as a basis for a GL drawing area (with gtkglext perhaps) and then mix cairo-gl rendering into the GL drawable you create and perform your own rendering to.

Comment on glamor-0.5 by ickle

ickle — Tue, 22 Jan 2013 13:53:27 +0000

The charts are just generated using the results of cairo-perf-trace over several runs fed through cairo-perf-chart. Both tools developed within cairo in order to perform this style of benchmarking.

Comment on A Tale of 3 Processors by ION

ION — Sun, 20 Jan 2013 09:43:10 +0000

Please benchmark Nvidia Ion with the latest Cairo 1.12.10 release and Nvidia 313.18 drivers.

Comment on Sandybridge acceleration by ickle

ickle — Fri, 11 Jan 2013 15:33:48 +0000

From a pragmatic point of view, you are correct. Ideally we should have pushed much harder for better drivers long ago, and by accepting the status quo nothing will ever improve.

I have a set of demos in http://cgit.freedesktop.org/~ickle/cairo-demos which can compare rendering client-side and pushing to the display versus rendering in the server. Excuse the formatting:

They are much simpler than a cairo-trace, aiming to isolate a small number of features that are easy to accelerate in a single test. (Akin to the performance demos at http://ie.microsoft.com/testdrive/Default.html)

Anyway even accounting for the transport overhead of pushing the image from the client to the screen (via SHM) in all but a few cases client-side rendering is a win for EXA-class drivers. Of course, this means backporting more recent versions of Cairo to 12.04 and choosing not to backport stable driver updates.

Perhaps, one way to experiment with your system is to set the CAIRO_DEBUG=xrender-version=-1 environment variable in your session. (Hmm in theory at least.)

Comment on Sandybridge acceleration by cosinusoidally

cosinusoidally — Fri, 11 Jan 2013 13:12:35 +0000

I still think it is a bit weird that Cairo uses 2d acceleration by default, when the CPU can currently do a better job. Didn’t you say that using the GPU (I mean on UXA) currently uses more power than using the CPU? As you say yourself “All bar one of the acceleration methods is worse (performance, power, latency, by any metric) than simply using the CPU and rendering directly within the client.” Is there some config option I can set to drop everything back to the image backend? Something like gfx.xrender.enabled=false in Firefox.

Even on mobile browsers it has been common practice to disable GPU rendering until it is actually beneficial. Same with Google Chome on both desktop (Linux desktop at least) and ChromeOS.

I understand that SNA will eventually be a win, but all us Ubuntu 12.04 Intel GPU users are stuck with UXA. Is SNA likely to come to Ubuntu 12.04?