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
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
