> The `waiting' as you put it is the precise problem, as it is a polling
> operation, maybe something like
>
> (while !(inw(gfx_base+status) & status_acceldone)
>
> Modern graphics cards will happily generate an interrupt upon the
> completion of an accelerated operation, or even a "queue empty" event when
> a queue of commands has been processed. The kernel has access to
> interrupts and interrupt handlers. Userspace doesn't, although maybe a
> kernel interrupt -> signal userspace gateway could be set up with minimal
> code.
did you ever estimate how long it takes until a small command fifo in a
fast grpahics chips runs empty (thus how low you'd have to wait if at all)
and how many cycles a plain interrupt will take?
while polling isn't a good think by default (esp. for slow devices, which
a graphics chip is _not_, for sure!) there are examples even in Linux kernel
where you cna find polling instead of using interrupts for various reasons;)
XFree86 4.x won't do too much polling (much less than 3.x) without using
any special kernel stuff and interrupts allowing concurrent operation
of CPU and graphics chip.
> The point is, there are certain performance enhancing operations on cards
> that X, as a user process, will _never_ have access to without kernel
> support.
but I've been told by a famous Linux kernel hacker (a hero to me;)
that even user level interrupts might be possible if needed.
and I've seen reports of user level DMA which showed that at least
for S3 ViRGE chips it's not worth the effort for X operations
(transfering large images).
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu