Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sgi!msc@ramoth.SGI.COM
From: msc@ramoth.SGI.COM (Mark Callow)
Newsgroups: comp.sys.sgi
Subject: Re: lrectwrite & gsync?
Summary: dma setup
Message-ID: <27896@sgi.SGI.COM>
Date: 3 Mar 89 20:20:06 GMT
References: <8903030550.aa06677@SPARK.BRL.MIL>
Sender: daemon@sgi.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 24

In article <8903030550.aa06677@SPARK.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes:
> I have noticed that if I write the entire screen (on a GT) with
> a single call to lrectwrite(), it proceeds with blinding speed.
> If, however, I send the same amount of data using one call to
> lrectwrite() per scanline, it proceeds at the rate of about 1000
> scalines/second, which is very slow.
> 
> Running gr_osview during this time, I notice that total user time
> is about 3%, and system time averages 40-60% !!!  I am calling
> lrectwrite() in a loop, there are no (intentional) system calls
> being made.  What I suspect is that lrectwrite() may be doing
> something like a gsync() on every call, or perhaps notifying
> the window manager that this might be a good time for another process
> to have a chance to do some graphics, or some such.
The system time is most likely due to the dma setup.  The pixels are
transferred by dma.  On the GT lrectwrite chooses whether to use dma or
push the pixels into the pipe depending on the number of pixels being
transferred.  Pushing pixels is much slower than dma but obviously the
dma setup time is a concern.  I don't know the exact changeover point.

No messages are sent to the window manager.  No window or screen locks are
acquired or freed.
--
	-Mark