On Sun, 26 Nov 2000, Erwin Rol wrote:
>
> One big quiestion remains , what is so different in XFree 4.0.1
> compared to XFree 3.3.6 ?! the s3virge driver in 3.3.6 isn't (much)
> slower
> than in 4.0.1 , but the latency is gone. The mga driver is slower but
> here
> also the latency is gone when using 3.3.6. The structure of XFree 4.0.1
> gives us the posibility to patch the drivers when needed and only
> distribute
> those, that way there could be made lowlatency version of the drivers
> without the
> need for ppl to download multi mega byte tar/rpm files. (just like is
> done
> with the patches for the linux kernel )
At least for the Matrox cards, the 3.3.6 driver *relied* on
retries. It didn't even check the fifo when sending color expansion
data across the bus. 4.0 and 4.0.1 were much better in the sense
that there were only a few cases where it relied on it. For 4.0.1a
I rewrote the MGA's color expansion routines so that retries would
never occur, at least not related to any hardware acceleration.
This was because retries seemed to cause some problems on the
(aparently broken) bus of the PPC. This change caused a
measurable performance loss in the MGA driver (oh well).
The two biggest differences between 3.3 and 4.0 are in the areas
of concurrency and write-combining. 3.3.6 (yes, this will sound
stupid) waited for each operation to finish after it commited it
to the hardware! It would program an operation and wait for the
engine to go idle before returning. It did this because there
wasn't a good mechanism for hardware/software rendering synchronization
in the old XAA, so acceleration had to me more-or-less atomic.
Now, it fills up the fifo and returns to the client with the
fifo usually still filled and the engine chewing on the new primitives.
This is one of the big reasons why 4.0 is alot faster than 3.3.
So now you have the engine going and the fifo potentially full while
other processes have the CPU, while before, you were pretty much
assured that wouldn't happen except when the server had it's slice
interrupted.
Also, write combining allowed us to transfer alot more data to
the framebuffer - something like 2.5 times as much in practice.
The MGA docs claim retries can happen when the memory fifo gets
full.
You can disable retries on the MGA (bit 29 in the OPTION register
in the PCI configuration space). But Matrox warns that when doing
so "PCI latency rules may be violated". I have disabled it in
the past and have noticed that it caused direct framebuffer writes
to be corrupted in some cases. I'm told that you're supposed
to leave it on but prevent them from happenning. A task which
I'm not sure is possible.
Mark.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
