[prev in list] [next in list] [prev in thread] [next in thread]
List: cairo
Subject: Re: [cairo] Using cairo with image surface backend results hangs system
From: "Carl D. Blake" <carl () boeckeler ! com>
Date: 2012-11-13 16:03:02
Message-ID: 1352822582.4088.1537.camel () vulcan
[Download RAW message or body]
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 <chris@chris-wilson.co.uk> wrote:
>
> > On Mon, 12 Nov 2012 14:31:26 -0700, "Carl D. Blake" <carl@boeckeler.com> 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
cairo@cairographics.org
http://lists.cairographics.org/mailman/listinfo/cairo
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic