[Open-graphics] Video interrupt enable/disable

[James Richard Tyrer]

Paul Brook wrote:
>>> On high-end systems you may have a 1:1 mapping from device output
>>>  to host input IRQ lines, so can determine an IRQ source without 
>>> having to poll the individual devices.  However as a device 
>>> designer/driver writer we can not assume this is the case.
>> We should not presume that the card will be plugged into low end 
>> hardware -- a cheep motherboard with AT style interrupt 
>> controllers.
> 
> Huh? So you're saying that we should produce a card that doesn't work
>  on most commodity PC hardware? Including the chipset you mention 
> below?

I don't see your point at all since this is a software question.  Your
have stated that the interrupts will all be shared and there is only one
available.  If the MB has APIC, this may not be the case.  Why should we
presume that the MB doesn't have APIC?

> 95% of drivers will be independent of the host IRQ routing. Se even 
> if you happen to have a dedicated IRQ line, the driver will query the
>  device interrupt state anyway.

"THE" driver, or the Kernel, will always query the device.  This is
needed to support shared interrupts unless there is some way to
determine that the interrupt isn't shared; I would do this anyway to
eliminate spurious interrupts being serviced.  I couldn't find sufficient
information about the current Linux Kernel to determine how this works.
  What is clear is that with a dedicated interrupt is that only one query
is needed.

> I expect the efficiency benefits from having multiple host IRQ come 
> because the OS only has to poll a small subset of devices.

The benefit of dedicated interrupts is that NO polling is needed!

> Saving a few extra bus cycles from the final poll in the case of a 
> dedicated IRQ line is probably going to be lost in the noise. I don't
>  believe that a single read and conditional branch to figure out 
> whether we're processing a sync or other service request is going to 
> have any measurable benefit.

If that is all that is needed, they perhaps.  But, is this all that is
needed?

>> My current entertainment is reading Intel: 31305602.pdf a 
>> southbridge chip.  So far, I find that it has *8* PCI interrupt 
>> inputs for 4 slots.
> 
> That's still sharing IRQ lines then. 4 slots give you a total of 16 
> PCI interrupt sources.

Read further.

>> I will probably read through this to get a better understanding of 
>> it, but it appears to me that we have no way of determining how 
>> many hardware vectored interrupts the card will have available. So,
>> I still suggest that we use 2 (or more) and the worst case is that
>> they will all wind up connected to the same vector, but it would
>> preform better if we could find more than 1.  This would also mean
>> that at the PCI interface level that we need to be able to disable
>> the interrupts individually for each IRQ output.
> 
> Single-function PCI cards may use a single IRQ pin. No more. This is 
> explicitly specified by the PCI standard.

Exactly where in the standard does it say this?  Could you quote it for
me as I don't have a copy.

> A graphics card is a single function device.

This has not been established.  What we do know is that AGP cards are
allowed two interrupts.  Does this apply to PCI as well?

> Except for SLI/Crossfire-like setups, which are just two devices in a
> single slot.
> 
> I guess we could expose the 3D and basic framebuffer components as 
> separate PCI devices, but this requires implementing a pair of PCI 
> interfaces on the card and complicates driver development for very 
> marginal gain.

You don't need two interfaces to have two sub-addresses.

> IIUC this thread started because someone wanted a vertical blank 
> interrupt. When all said, 100Hz isn't a particularly high-frequency 
> interrupt. Also, if something is sufficiently latency sensitive to 
> require a dedicated interrupt vector then a general purpose OS 
> (windows, linux, BSD) isn't going to be sufficient either. You're 
> going to need a specialised RTOS.

IIUC, Linux now does RT.  Would using RT speed up the graphics board?

>> Next question: does the Linux Kernel have support for APICs on 
>> Intel hardware?
> 
> Of course it does. This is a completely unrelated to the task of 
> designing a PCI add-on card though.

Then how can you state that using it, if available, will "produce a card 
that doesn't work on most commodity PC hardware"?  This is a software 
issue not a hardware.

-- 
JRT