On Friday 25 August 2006 20:09, Timothy Miller wrote: > On 8/25/06, Jon Smirl <[EMAIL PROTECTED]> wrote: > > On 8/25/06, Timothy Miller <[EMAIL PROTECTED]> wrote: > > > I've done all this before, and I can assure you that MANY commands > > > take less time to submit than they do to execute, especially if PCI is > > > the bus. With 3D, we'll get lots of tiny triangles that are also > > > faster than the bus. Packing is vital for throughput. > > > > Your experience should be better. From the outside it is hard to tell > > how long the GPU takes to execute an instruction. That suggests a > > feature, an on-board timer that tracks how long the command stream > > runs and reflects pipelining. Then you could run various combinations > > of op codes and see which one is the fastest. Other overhead getting > > in the way makes this hard to measure. > > Here's the approach I have in mind (which I think I may be copying > from somewhere): > > Each packet has a 32-bit header. Some bits are reserved for the > packet type, some are reserved for the packet length (not everything > submitted--just this one command), and the rest depend on the packet > type. For a drawing command packet, those remaining bits will usually > be used as flags to indicate which of the many possible attributes are > also contained in subsequent words of the packet header. >
Why bother with making complex optional attributes. WOuld it be easier to just make the attribute setup in separate commands & then make drawing a triangle use already setup values. H
pgpVqDRRpbWXY.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
