On 9/8/07, Petter Urkedal <[EMAIL PROTECTED]> wrote: > On 2007-09-06, Timothy Normand Miller wrote: > > So, off the top of my head, here are some of the I/O ports we would employ: > > > > READ_REQUEST_ADDR (write these two to enqueue a read command) > > READ_REQUEST_COUNT > > READ_DATA (read this to dequeue) > > READ_DATA_COUNT (how many are in the return queue that can be pulled) > > WRITE_DATA (write these two to enqueue a single write) > > WRITE_ADDR > > I'm sure these are all from main memory.
Yes. > > WRITE_STREAM_ADDR (write these two to set up a streaming write) > > WRITE_STREAM_COUNT > > WRITE_STREAM_DATA (a write here enqueues data and advances addr) > > WRITE_QUEUE_FREE (how many free words in the write data queue) > > READ_COMMAND_FREE (how many free read command entries) > > WRITE_COMMAND_FREE (same for writes) > > Are these connected to the PCI master/target? No. Memory too, although the master controls would look almost identical. > > * Packet header that indicates we're going to draw a triangle. It > > indicates that the triangle is solid and that the vertex color is > > included. It also indicates that there are two triangles to be drawn. > > * Since the vertex color is flagged, that's inserted here. > > * Three vertexes > > * Three more vertexes > > * Next packet.... > > This is a simplification, right? Looking at new_model in the OGP repo, > I can see it uses fragment data which describes trapezoids with colour > gradients, in the form of a mixture of absolute and x/y-differential > data. It's definitely a simplification. The nanocontroller wouldn't have the processing power to compute all that from vertexes. -- 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)
