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. > 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? > Now, while we may use a crossbar for data moves, the nanocontroller > would be directly involved in processing rendering commands. > Rendering commands would start with a 32-bit word that describes the > rest of the packet. For instance, there would be a packet type, a set > of flags to indicate what attribute values are included, and maybe a > number indicating how many of the particular rendering operation to > do. For instance: > > * 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. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
