Re: Using cairo with image surface backend results hangs system
"Carl D. Blake" <[email protected]>
| Newsgroups | gmane.comp.lib.cairo |
|---|---|
| Message-ID | <1352822582.4088.1537.camel@vulcan> |
I got it to work by disabling the simd and neon optimizations in the pixman build, so it looks like Siarhei is correct and the neon instructions were causing a lockup in non-cached memory. From what Chris said it sounds like I should make a shadow framebuffer which is located in standard memory, perform all draws on that memory, determine a rectangle which encompasses the draws that have been done, and then do a final blit using that rectangle into the actual framebuffer using CAIRO_OPERATOR_SOURCE. Would this actually improve performance even though I will be duplicating memory writes for every operation? I can do these blits with memcpy, but I wondered if pixman would handle this better. Are there any examples available? Carl On Tue, 2012-11-13 at 14:24 +0200, Siarhei Siamashka wrote: > On Tue, 13 Nov 2012 09:57:57 +0000 > Chris Wilson <[email protected]> wrote: > > > On Mon, 12 Nov 2012 14:31:26 -0700, "Carl D. Blake" <[email protected]> wrote: > > > I'm trying to use cairo with a DM8168 based system. I want to be able > > > to use it with the framebuffer so I've set it up to use the image > > > surface backend. I've mmaped the framebuffer to a memory location and > > > passed that as the data pointer to cairo_image_surface_create_for_data. > > > It appears to work for a while, but it always hangs the system at some > > > point when any drawing is being done (cairo_show_text or cairo_stroke). > > > I realize that cairo is drawing directly to the framebuffer, but I > > > didn't think this would be a problem. Am I doing something wrong here? > > > > It should work, Cairo should not generate out-of-bounds write or reads. > > So I would suggest something is going wrong at the hardware/driver level > > if the machine stops responding. > > Based on the symptoms, looks like it could be "Advisory 1.1.38 NEON > Instructions Executed on a Non-Cached Memory-Mapped Address Result in > Lockup" described in > http://www.ti.com/lit/er/sprz329c/sprz329c.pdf > > > However, I can not recommend that you use an UC or WC mapping for a > > Cairo surface, except for the final blit. Many of the operators that > > Cairo performs involve a readback from memory, which from a scanout will > > be very slow and may give the appearance of the machine freezing. (The > > usual solution is to use a shadow framebuffer for the composition with a > > blit (CAIRO_OPERATOR_SOURCE) onto the scanout for display.) > -- cairo mailing list [email protected] http://lists.cairographics.org/mailman/listinfo/cairo