No 1 contributor of kernel regressions!
Who wrote 2.6.37?
-
« Home
Pages
-
Categories
- Categories
-
Archives
Category Archives: Uncategorized
Here are the slides at least. They are of course missing the fullscreen demos.
batchbuffer at 0x08ac0000:
0x08ac0000: HEAD 0xff808698: UNKNOWN
0x08ac0004: 0xff808698: UNKNOWN
0x08ac0008: 0xff808698: UNKNOWN
0x08ac000c: 0xff808698: UNKNOWN
0x08ac0010: 0xff808698: UNKNOWN
0x08ac0014: 0xff808698: UNKNOWN
0x08ac0018: 0xff808698: UNKNOWN
0x08ac001c: 0xff808698: UNKNOWN
0x08ac0020: 0xff808698: UNKNOWN
0x08ac0024: 0xff808698: UNKNOWN
0x08ac0028: 0x00484c58: MI_NOOP
Last instruction on ringbuffer:
0x007da9f8: 0x18800080: MI_BATCH_BUFFER_START
0x007da9fc: 0x08ac0001: dword 1
0x007daa00: 0x02000004: MI_FLUSH
0x007daa04: 0x00000000: MI_NOOP
We tried to execute an image surface? How did that happen? Time to go shopping.
gstreamer + cairo == awesome
For the last few days, I’ve been listening to the gstreamer devs get excited about cairo, simply because it is awesome! Well actually because over the last couple of years the drivers have developed sufficiently that the abstraction offered by cairo solves several of the problems that the gstreamer developers have had to previously hacked around. This means that they get to dump all of their multi-threaded decoding and rendering problems on us, which makes them very happy.
In return for the extra work, we promise to make it fast as well. At the base we will be [eventually] including a jit into pixman, so that we can generate optimised code at runtime for the more obscure colorspace conversions without bloating the library by compiling thousands upon thousands of pre-computed, even hand-rolled, fast paths. But pixman is not the interface we want to present to applications, so we have an abstraction layer over that which allows applications to target GPUs, DSPs or the CPU with nary a care in the word – this is cairo. From the discussions we had, it emerged that to resolve many of the locking issues and general thread-safety concerns within gstreamer, required exposing some of the support cairo uses internally to reach its own thread-safety guarantees. However, not all backends are created equal and we will also need to fixes to the underlying libraries. For X11, this means we need to switch to xcb and for GL we need a new GLX extension to permit more efficient multi-threading.
Beyond that Benjamin is pressing for an aggressive timeline, cairo-1.10 in January so that we can make the next round of stable distributions. As my current development branch has over 40k lines of changes, with much more work required, this is quite a challenging schedule. Compared to that adding the extra interfaces and fixing the inevitable bugs is a tiny amount of work!
As nobody appreciated the relative factors as a performance metric, here are the absolute times for tiny.
image xlib xvfb gl drm evolution 69.9 74.8 186.4 146.3 103.6 firefox-planet-gnome 217.5 170.8 295.1 359.9 100.1 firefox-talos-gfx 342.1 193.5 305.1 645.3 48.9 firefox-talos-svg 375.3 684.8 621.1 709.7 876.1 gnome-system-monitor 39.6 149.6 64.5 348.8 19.3 gvim 167.8 90.5 295.9 262.0 148.9 poppler 41.5 69.8 50.4 138.9 14.4 swfdec-giant-steps 20.7 25.2 28.1 54.7 13.3 swfdec-youtube 41.3 39.5 52.4 46.0 11.8 vim 97.5 115.6 93.9 160.3 20.8 Times are in seconds.
[image] 1.9.2-564-g1b24626.image.tiny
[xlib] 1.9.2-564-g1b24626.xlib.tiny
[xvfb] 1.9.2-564-g1b24626.xvfb.tiny
[gl] 1.9.2-564-g1b24626.gl.tiny
[drm] 1.9.2-564-g1b24626.drm.tiny
So it’s been a while. It seems I’m not a natural blogger — especially when other people describe my work far better than I do myself, thanks Carl!
After seeing Vlad’s pretty pictures for firefox’s fragmentation, I wanted some of that bling for myself. Hence the development of a prototypical GUI for memfault, a valgrind memory profiler ala massif.
Git repository: git clone git://annarchy.freedesktop.org/~ickle/odin
cairo_show_text (“Hello World”);
cairo-ickle 