> > 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? 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. I expect the efficiency benefits from having multiple host IRQ come because the OS only has to poll a small subset of devices. 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. > 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. > 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. A graphics card is a single function device. 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. 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. > 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. Paul _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
