I'm starting on the DMA sequencer, and I have to define how packets look. This is a rough draft, and based on your comments, I'll refine it.
There are two data sources for DMA packets. One is a ring buffer. There is only one ring buffer (at a time). As its name suggests, it's circular, and packets can wrap around one end to the other. DMA from the ring buffer is initiated by enabling it and having head (read) and tail (write) pointers being different. The ring buffer has full privileges, meaning that commands in it it can be any kind of DMA transaction. The ring buffer would usually be managed by the kernel. The second source of commands is the indirect buffer. Indirect buffers are linear stretches of commands. They can be privileged or not, as specified by a flag in the ring buffer packet that initiated the indirect transaction. A packet starts with a 32-bit header. The upper 4 bits are the packet type, plus some other info about the packet. This is followed by data words. My format for describing bits in a word is [number of bits:meaning]. These are the packet types: 0: Indirect DMA commands This packet is allowed in the ring buffer but not an indirect buffer. The packet contains two words: [4:0][1:privileged][27:length] [32:starting address] When this packet is read from the ring buffer, the indirect sequencer starts reading words from this address and continues reading until length words have been read. If the privileged bit is not set, the particular indirect buffer is only allowed to contain rendering commands. 1: Memory download [4:1][28:length] [32:graphics address] [32:host address] This copies length 32-bit words from the graphics memory to the host memory. Format conversions will apply. 2: Memory upload [4:2][28:length] [32:graphics address] [32:host address] Copy length 32-bit words from host memory to graphics memory. Format conversions apply. 3: Engine upload indirect [4:3][28:length] [32:host address] This pushes length 32-bit pixels through the drawing engine's rectangular area upload mechanism. This is to make it easier to do putimages to windows. Format conversions apply. If you are uploading 8-bit pixels, you're sending 32-bit aligned data, so you will have to program the appropriate engine registers to trim the left and right edges. The data is treated largely like texture data. 4: Engine upload inline [4:4][28:length] length * [pixel words] This header is followed by length pixels, inline in the packet. This is much like type 3 but is good for small images where it's more efficient to push the data inline. 5: Engine render [4:5][28:register flags] [16:height][16:Ystart] N * [register data] This command initiates a rendering operation. 28 of the most commonly-used engine registers (mostly in the rasterizer) will be selectable by this command, and they'll follow in order from the right-most flag leftward. The number of them depends on the number of flag bits set. A 29's register is implicitly required, which is the register that contains the triangle height and starting Y coordinate. There are lots more engine registers, and they can be set by other packet types. These are likely to change somewhat, but here's the general idea... 6: Engine registers 1 [4:6][28:flags] N * [register data] Some selected subset of the registers. 7: Engine registers 2 ... 14: Engine 2D stipple [4:7][28:reserved] 32 * [stipple bits] The 2D block can overlay a 32x32 mono stipple pattern on whatever it draws. This packet uploads the stipple. This is also useful for mono text glyphs smaller than 32x32. 15: Engine 2D tile [4:7][28:reserved] 64 * [tile pixels] Similarly, there is an 8x8 color tile that can be merged with pixel data. This uploads that tile. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
