Subject: Re: Blitting
To: Lutz Vieweg <>
From: Eduardo E. Horvath <>
List: amiga-x
Date: 03/27/1994 11:23:22
On Fri, 25 Mar 1994, Lutz Vieweg wrote:

> Hi Phil Mucci, on Mar 24 you wrote:
> > Why couldn't we write an interrupt driven queueing blitter
> > driver?

> Another point is, that the (often occuring) small blits would
> not benefit from the queueing, the time a context switch takes
> is often longer than the whole blit.
Good point.

> An interesting idea, but the queue would have to be managed
> from within the X-server, how could you synchronize CPU-accesses
> to the frame-buffer memory otherwise?

I don't see this as being much of a problem.  The only operations that 
should be CPU driven are single point rendering, for efficiency, and 
arcs.  Neither operation occurs very often, so a synchronization ioctl 
should not adversely affect performance. 

The main reason I see for having this functionality in the kernel is that 
getting the blitter done interrupt to the server is difficult and will 
require the same context switch that an ioctl needs.

What about the idea of having a device you can write a series of 
structures to to control blitting, like /dev/kbd in event mode, but in 
the opposite direction?  It would then be bossible to queue several dozen 
blit operations with one I/O operation, and use select() so synchronize.  
But to do this we would need another device, wouldn't we?  Or could we 
write() to the same /dev/view we mmaped()?  

A problem with this approach is detecting exactly whic operations are 
supported.  If you attempt an ioctl() and get ENOSUPP, you know what 
caused it, but if you write 6 different blits and line and pixmap 
operations, how do you identify which one(s) failed?

I'm also surprized there have been no complaints about my proposed 
ioctls.  It's hard to believe that everybody is happy with them.
Eduardo Horvath
	"Trust me, I am cognizant of what I am doing." - Hammeroid