Actually, the slowdown is caused not just by the overhead of the
read/write methods, but also due to the extra work padding and aligning
the bitmaps according to requirements of the hardware. This was because
James wanted support for buffers located not just in system memory but
also graphics/dma memory.
The result is that unaccelerated imageblit will slow down while properly
written accelerated imageblit will experience some speed up (not much,
probably around 5%).
We can:
1. partially reverse the code so it behaves similarly to 2.5.63.
Support for writing to graphics/dma memory will go away.
2. split the code path: one will go to the '2.5.63' path, the other
will go to the '2.5.66' path, depending on the setting of info->pixmap.
3. keep the code as is
Personally, I prefer #1, but it's up to James/Geert.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/