[Open-graphics] Video interrupt enable/disable

[James Richard Tyrer]

Timothy Normand Miller wrote:
> On 4/19/07, James Richard Tyrer <tyrerj at acm.org> wrote:
> 
>> At first look, it appears to me that the service ISR could cause latency
>> problems with the sync interrupt if they share the same interrupt.  This
>> is the real issue that needs to be discussed.
> 
> You are right about that.  But I don't see how _we_ can fix it.  This
> is the domain of OS experts, like the people on LKML.

The only thing that we can do is use two interrupts.  Whether or not 
this helps will depend mostly on the hardware that it is plugged into, 
and the system software that is controlling it.

> Besides, I have a tendency to want to design things so that latency is
> not an issue.  For instance, we want to save on CPU overhead by
> putting a GPU-using process to sleep after it's queued up a bunch of
> requests.  We need to wake it up at some point to have it continue.
> The solution is to design it so that the interrupt comes when the GPU
> is still busy but nearing the end of being busy so that the producer
> of commands can start producing them again before the last batch is
> finished being processed.  This way, the GPU stays busy constantly,
> regardless of the latency on interrupts or, far far worse, the time
> required to wake the user process back up again.

Yes, that is the way to handle the service interrupt.  Doesn't fix the 
sync interrupt issue though.  The best fix for the sync interrupt is to 
figure out a way that it isn't needed, at least it doesn't need to be 
routed off of the board.  If you could set up the I/O processor so that 
it would wait for the interrupt, this might be usefully.  Or, if we are 
using double buffering, the sync interrupt could trigger the buffer switch.

> Hanging 50 IRS off of one interrupt line is bad.  But I think we're
> going to encounter other problems that make that pale in comparison.

I have an old system that only has the 15 AT interrupts and my disk 
controller (2 x IDE) only has one interrupt line.  Two system interrupts 
conflict and I think that the Kernel's interrupt sharing system is 
dealing with that.  But, I am having interrupt issues from time to time. 
  The older 2.6.x Kernel was getting mad and disabling one of them. 
Upgrading the Kernel did fix that annoyance, but the disk controller 
still doesn't work too well.

With VLSI chips now common and cheep, there is no excuse for hardware 
not supporting 4 hardware interrupts for each PCI slot!  Actually, just 
adding a second APIC to the southbridge chip should do it.

-- 
JRT