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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.