> >>>>> "Andreas" == Andreas Kostyrka <andreas@rainbow.studorg.tuwien.ac.at> writes:
>
> Andreas> On 28 Mar 1998, Jes Degn Soerensen wrote:
> >> There is nothing the prevents you from pipelining the blit
> >> operations in user space as well and/or start doing other things
> >> while `waiting' for a blit operation to finish.
>
> Andreas> There is. I still have to poll. (Or do you want to
> Andreas> demonstrate a userlevel IRQ handler? *g*)
>
> I didn't say you don't have to poll, but if you arrange your code in a
> sensible manner you will not issue the blit operation and then start
> polling right after that if there are other pending operations.
That makes still for nonoptimal code. As Linux is multitasking, making
assumptions about the absolute time difference between A: and B: is not
really possible:
{
...
A: sendAccRequest()
...
B: while(waitAcc());
...
}
And as most often a there is nothing todo (just because the card is
blocked doing the work), the typical thing would be usleep or blocking on
a interrupt wait.
So let say, you have picked usleep(5) as the sensible time for this
request. Now you have still the problem that this time depends upon
load, other external IRQs, etc.
So either usleep(5) sleeps to long, which means that gfx speed is
suboptimal, or usleeop sleeps to short, which means that artificial
CPU load is generated -> the system ``speed'' is suboptimal.
Hmmm. I've always thought, that Linux was about doing it right, and don't
do some hack. I'll have to readjust my thinking :(
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu