On 24/10/2010 19:34, Timothy Normand Miller wrote:
On Sun, Oct 24, 2010 at 12:21 AM, Patrick McNamara<[email protected]> wrote:
I guess, in a way, this is what HQ does for VGA text. The blit of the font
glyph is handled on card. We should be able to load an HQ program as part
of the fb driver to do "acceleration" of fill and copy_area, at least. The
copy_area call would still be best handled entirely in the S3 as using HQ to
do it would involve moving a lot of data over the XP10<->S3 bridge.
If all you want is a simple blt/fill engine, we can code one up pretty
quick. Dedicated hardware would be way faster than using an HQ.
BTW, I'm going to the SBAC-PAD conference in Brazil, so you'll have to
wait a while on me to do it.
I had a play with fill and copy area routines in HQ. The code is
checked in, but not enabled. I suspect that it would be best to have a
second HQ image and to load that up when we needed it (you then need to
be able to but the text mode image back when you want to do text mode).
I agree with the other comments here though. A video-mem to video-mem
copy should be done in the S3, as should block fills. If we are copying
video-mem to system-mem then I think we really need to bus master to get
this "fast". The trick (I guess) will be to free up the PCI bus and the
host CPU while we are reading from RAM to S3 and then from S3 to XP10.
Only when the data is in the XP10 do we want to use the PCI bus, and
then we still don't want to bother the CPU.
I'd really like for someone to be working on PCI bus master, as I think
that's the one feature that's really going to make things faster.
MM
PS.
As I remeber I use the block-fill code to clear the frame buffer at HQ
start?
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
