Date:	Thu, 10 Apr 1997 11:30:13 -0400 (EDT)
From:	Peter Berdeklis <peter AT atmosp DOT physics DOT utoronto DOT ca>
To:	Chris Croughton <crough45 AT amc DOT de>
cc:	djgpp AT delorie DOT com
Subject:	Re: Interrupts (Hardware)
In-Reply-To:	<97Apr10.104800gmt+0100.21890@internet01.amc.de>
Message-ID:	<Pine.SGI.3.91.970410105811.17169A-100000@atmosp.physics.utoronto.ca>
MIME-Version:	1.0

On Thu, 10 Apr 1997, Chris Croughton wrote:
> Peter Berdeklis wrote:
> 
> >The graphics won't affect interrupt latency at all.  The graphics code is 
> >just interrupted.  In fact, most graphics code is slow not because of the 
> >CPU time it uses but because the bus is slow (ray tracing is an obvious 
> >exception).
> 
> If the bus is slow won't that affect the interrupt latency?  Surely an
> instruction can't finish until it's accessed the bus (as far as I know
> the cache doesn't do video memory - at least on my machine it seems that
> video accesses are the same speed with and without cache).

By slow I mean that the bus is much slower than the CPU and cache, so
unoptimized graphics code may spend a lot of time waiting for images to be
transferred over the bus to the video card.  That's why having a _quick_
interrupt between slow bus transfers probably wont affect the execution
time too much, because the duration of the interrupt is small compared to 
that of the code being interrupted.

If your interrupt code uses the bus a lot, then yes a slow bus will 
obviously affect interrupt latency.  However, many interrupts only need 
to perform a few actions like downloading a few bytes from a card, 
updating some counters, etc.  In this case the time required for a mode 
switch can be of the same order of magnitude, or greater, than the time 
required to service the interrupt.  This is when interrupt latency 
becomes a concern.  There's nothing you can do about a slow bus, except 
maybe to push the TURBO BUTTON! (TM). :)


> And why is ray tracing different?  Is it because of the difference 
> between slow video RAM and the faster RAM used by the ray tracing
> algorithms?

Ray tracing is different because the calculations performed in generating 
the rays far outweigh the time required to send the image to screen.  
Ray tracing is very computationally expensive (which is why it's not used 
in games - although everyone would love to) and so there isn't much 
waiting around for the bus.  When you ray trace you've got the CPU 
working on the calculations >90% of the time, and any interruption can 
drop that CPU usage significantly.  Mode switching then becomes very 
expensive.

> (I'm not a graphics programmer, I'm interested in learning about
> these things.)

Me neither. :)

---------------
Peter Berdeklis
Dept. of Physics, Univ. of Toronto

- Raw text -