From: Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: SVGA transfers. Speed?
Date: Sun, 17 May 1998 15:02:14 +0100
Organization: None
Message-ID: <3jc6SDAm3uX1EwQL@talula.demon.co.uk>
References: <355ed4d0 DOT 0 AT news DOT arrakis DOT es>
NNTP-Posting-Host: talula.demon.co.uk
MIME-Version: 1.0
Lines: 58
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Ramcor writes:
>I have made a SVGA dumper routine in DJGPP but I feel this may be slow.
>Does anybody know how to optimize svga transfers?

The best thing you can do is to get rid of all those real mode interrupt
calls. This means using version 2.0 of the VESA interface, so it will
only work on machines that have a VBE 2.0 driver installed. VBE 2.0 will
let you do the bank switching entirely in protected mode, and on most
hardware it will also give you access to linear framebuffer modes, that
don't need any bank switches at all. See the VESA spec for details, or
the DJGPP User's Guide on www.delorie.com.

While I'm here, there are a couple of things I'd like to point out about
your code...

It isn't recommended to just assume that 0x101 is the mode number for a
640x480 resolution. This number was specified by the original versions
of VESA, but more recent copies of the spec say that the mode numbers
are left up to the individual driver implementation. VESA says that it
is "highly recommended" for drivers to go on using the same standard
numbers, but you can't be certain that they will all do so. To make your
code really robust, and so it will be able to support other non-standard
resolutions, I suggest that you do this properly and query the VESA
driver in your init code to find out exactly what resolutions and mode
numbers it supports.

In your blit code, you are assuming a 64k bank size. This isn't always
true: many cards have a 4k or 16k alignment, and your code will not work
on these. You should check the bank granularity field in the VESA
information structure to find out what size the current card is using.

>I own a S3 trio64 video card. I know these cards have some sort of
>optimisations functions to do with 2D graphics. Anybody knows how ?

The VBE/AF interface allows programs to access these hardware features
in a portable manner. You can get VBE/AF drivers as part of the SciTech
Display Doctor package, or from the FreeBE/AF project 
(http://www.talula.demon.co.uk/freebe). FreeBE/AF doesn't have any S3
driver at the moment, but a volunteer to add it would be very welcome!

Unfortunately the VBE/AF spec isn't freely available (the VESA people
charge some stupid amount of money for it), but there is plenty of
source code available as part of the MGL and Allegro libraries and the
FreeBE/AF drivers, so you should be able to figure everything out from
those.

You will find, though, that hardware acceleration doesn't really help
with something as simple as blitting large images from system memory
onto the screen. These operations are limited mainly by bus bandwidth,
and there is very little that the graphics card can do to help with
that. The biggest gains of hardware acceleration are with operations
that lie entirely within the video memory, such as filling rectangles
and blitting from offscreen video memory onto the screen.


--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
"Miracles are nothing if you've got the wrong intentions" - Mike Keneally