All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: Antonino Daplas <adaplas@pol.net>
Cc: James Simmons <jsimmons@infradead.org>,
	Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: [PATCH] Tile Blitting
Date: 27 Feb 2003 19:25:03 +0100	[thread overview]
Message-ID: <1046370303.12970.27.camel@thor> (raw)
In-Reply-To: <1046355210.1206.42.camel@localhost.localdomain>

On Don, 2003-02-27 at 15:15, Antonino Daplas wrote: 
> On Thu, 2003-02-27 at 09:18, James Simmons wrote:
>  
> > > Thus, the restriction that the buffer must be completely copied by the
> > > driver before returning.  And because of this restriction, an extra copy
> > > which might be unnecessary cannot be avoided (this was noted by Petr).
> > > 
> > > Treating the buffer as a ringbuffer, we eliminate these restrictions.
> > 
> > I didn't realize that the below was a ringbuffer implementation. The name
> > threw me off. 
> 
> Well, it's not strictly a ringbuffer implementation.  This would require
> a head and tail pointer where fbcon will adjust the tail and the
> driver/hardware will adjust the head.  This will be very difficult to
> implement in a device independent manner.  So we just cheat by issuing
> an fb_sync() per loop to flush all pending commands.

That still seems suboptimal though. What the DRM often does is have the
chip write an age value to a scratch register when it's done processing
something. Maybe something like that could be used to avoid waiting for
the chip to go idle at all?


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

  reply	other threads:[~2003-02-27 18:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-23  4:42 [PATCH] Tile Blitting Antonino Daplas
2003-02-23  7:43 ` Antonino Daplas
2003-02-23 11:07   ` Antonino Daplas
2003-02-26 20:11     ` James Simmons
2003-02-27  0:35       ` Antonino Daplas
2003-02-27  1:18         ` James Simmons
2003-02-27 14:15           ` Antonino Daplas
2003-02-27 18:25             ` Michel Dänzer [this message]
2003-02-27 19:48               ` James Simmons
2003-03-02 12:14                 ` Geert Uytterhoeven
2003-03-03 21:32                   ` Antonino Daplas
2003-02-27 21:47               ` Antonino Daplas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1046370303.12970.27.camel@thor \
    --to=michel@daenzer.net \
    --cc=adaplas@pol.net \
    --cc=jsimmons@infradead.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.