Timothy Miller <[EMAIL PROTECTED]> wrote:
The first thing we can do is carefull tune the DMA command packet set.
There are, of course, limitations on this, because we need to keep
the hardware simple, but there are likely many things we can do to
squeeze out a little more performance. For instance, X and Y
coordinates are usually 16 bits, but sometimes, we don't need numbers
that big. In those cases, we can use the extra bits to squeeze in
some other parameter(s). The same is true for absolute addresses.
I doubt this is going to be useful. Graphics libraries, whether
2D like X Windows or 3D like OpenGL, try to create batch arrays
of coordinate values even when the application itself thinks it
is making individual calls. The driver just stores the incoming
arguments into an array and only sends them off to the card
when it has built up a sufficiently large chunk or there is a
state change.
So how does the driver use a packed format? It can make a pass
over the array before sending, and if all the values are inside
the packed range then make a packed copy. Or it could check the
incoming values as they arrive and set/clear a 'packable' flag,
but it's still got to make a copy before sending. Or it could
be optimistic and pack values until one that's out of range
arrives, but then it has to either send what it has in smaller
less efficient chunks, or 'realloc' the packed into unpacked.
Will the extra memory copying be less than the DMA traffic?
I also wonder whether it would make a noticeable difference
even if implemented. My opinion is that the volume of bitmap/
image data from fonts in 2D GUIs or texture maps in 3D apps
will be much greater than the coordinate/vertex data.
--
Hugh Fisher
DCS, ANU
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
