On 12/4/05, Attila Kinali <[EMAIL PROTECTED]> wrote: > On Sat, 26 Nov 2005 13:14:31 -0500 > 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. > > Just a little note here: Please avoid such stuffings unless > there is really an advantage in using them. Because with > every different DMA command packet format you make the life > for a driver writer harder and it makes the code harder to > understand and thus harder to maintain.
I'll write the macros for them so they don't have to worry about it. :) Plus, they can add the more specialized ones as a later optimization, after they get the basic stuff working. > I know, hardware should here command what sofware should > do, but we should optimize over both sides. The objective is to identify where it is worthwhile to optimize and do it in a reasonable way. Besides, writing drivers is challenging anyhow. Doing something as mundane as making an alternative compacted form of a packet won't really be over the heads of the driver developers. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
