On Fri, 7 Oct 2005 17:41:23 -0400
Timothy Miller <[EMAIL PROTECTED]> wrote:
> 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.
I do not see the usefullness of a packet wrap around. As
in software it is quite tedious to split packets at certain adresses.
It's a lot more convenient to just leave the rest of the space unused
and start from the beginning of the ringbuffer.
IMHO it wouldnt be a bad idea to have fixed size packets, as these
would not only make the hardware more easy, but also simplify
driver programming (given that we do not lose functionality by
restricting us to a fixed size).
If you choose not to use fixed size packets, then you definitly
have to restrict the sizes to be divisible by some value
(i'd say either 4 or 8 byte) and force the sizes to be divisible
by shifting them.
> 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.
s/kernel/driver/
The driver does not necessarily have to be in the kernel.
> 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.
where is the start adress ? on the card memory or host memory?
>
> 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.
I would use here from the beginning 64bit for the host adress.
It will make upgrade to 64bit systems simpler.
> 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.
Here again, 64bit for host address.
And where does the image end up?
Also i would change this command to allow multi plane formats,
as today most software systems deliver images not interleaved
but as three (or four) different planes. But you have to keep here in
mind that there are subsampled planes that use 4:2:2 and 4:2:0
(which are easy to deal with) and other more obscure (that are
not so easy to deal with) formats. I would say, for practical uses
limit subsampling to 4:2:2 and 4:2:0 and let the others convert
by software.
BTW maybe it would be an idea to have the conversion matrix for
YCrCb -> RBG configurable, as there are IIRC 3 (slightly) different
standards around. But this might add some additional logic as we
would lose the advantage of constant value multipliers.
> 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.
Can you give me an example when this would be more efficient?
Otherwise i think that a small memory region with the data
(which you need anyways as the data has to come from somewhere)
and a normal engine upload should as efficient.
> 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
> ...
I cannot say anything about these, as i have no experience
in rendering.
> 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.
What are these for ?
Also maybe it would be an idea, if we use non-uniform sized packets,
to have a specialized packet to upload mouse pointer pixmap/masks.
On the other hand these can be stored in the card memory
and used by switching the pointing registers.
What is definitly missing is a NOP packet. And i would
put this as type 0, so that 0 initialized memory would
make valid packets.
Attila Kinali
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
