On Fri, Nov 5, 2010 at 2:06 PM, Mark Marshall <[email protected]> wrote:
> Hi.
>
> I've had a go at adding a few BLIT operations to the HQ code. These are
> only really for experimenting with, and I've not changed any of the drivers
> to use them yet. To work well they will probably need an updated XP10 image
> so that the HQ data can be read back.
>
> There are 4 operations defined so far, and now the HQ program memory is
> full. I guess in the end we'll not want more of these in the same image as
> the VGA emualtion code (which is how I've done it now).
>
> I also don't know how well these will work in prcatice. There are all sorts
> of nasty problmes whereby we might end up with both PCI and HQ talking to
> the S3 - I've not stepped through all the possible cases, so it's quite
> likely that thi swill break.
"Break" would be an understatement. I don't recall what would happen
if you try to do a write at the same time a read is pending, but in
any case, the bridge is stateful, and multiple independent pending
transactions will crash like a ValuJet DC-9. Most likely, you'll lock
up the system.
A safer (and FASTER) solution would be to put an extra HQ into the S3
as an extra agent that has its own ports on the arbiter. Now, you can
have race conditions if you try to perform multiple accesses to the
same surfaces (PCI and HQ at the same time), but those will result in
nothing more than corrupted rendering. Obviously in that case, we
need a status register and/or interrupt signal to indicate when the
rendering op is finished, so we can either issue another one or do
some software rendering.
The way HQ is used for VGA, all PCI accesses are processed and
forwarded by HQ code. This introduces a huge performance hit that
fortunately doesn't matter in text mode. (In theory, we could move
VGA text mode into an HQ in S3, but that's undesirable for other
reasons... DMA and VGA graphics mode. Really, we don't want an HQ in
the S3, but rather a real blt engine, but we can have some fun putting
one in there.)
>
> The operations are block-copy, block-fill and colour-expand-{8bit,16bit}.
>
> The block-copy and block-fill are self explanitary (I hope). The
> expand-colour operations take a block of data that is in either 5,6,5 or 8
> bit mode and converts them to 8,8,8 data. The 8-bit mode uses the VGA
> palette, but this needs more work I thin kto become usable.
>
> Next week, if I have time, I'll try to get the framebuffer driver or the X
> driver to call these (And see if it looks faster).
>
> MM
>
> _______________________________________________
> Open-graphics mailing list
> [email protected]
> http://lists.duskglow.com/mailman/listinfo/open-graphics
> List service provided by Duskglow Consulting, LLC (www.duskglow.com)
>
--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
