Re: [Mesa3d-dev] MMIO/DMA ?

[Westermann Fu <wes...@gm...>]

Thanks very much

As the example when FIFO is full, maybe the 17th or 33th vertex will wait
for there is room again, so the block happens, I agree. But for correctness,
need software special handling? I mean after each time a triangle is feeding
to GPU, then, should software wait for some status register to indicate the
FIFO is safe? or the 'MOV' instruction itself (or whatever others, here I
mean no any sync code needed) can promise the correctness automaticly?
Otherwise I think there is a FIFO overriding risk.

Regards


On Wed, Feb 24, 2010 at 1:39 PM, Stephane Marchesin <
ste...@gm...> wrote:

> On Tue, Feb 23, 2010 at 21:06, Westermann Fu <wes...@gm...>
> wrote:
> > Hi, friends:
> >
> > Sorry for my junior level question first, but I don't know where I can
> get
> > it been answered. I have post it to dri-devel list but nobody seems
> > interested, so I hope anyone here can help me.
> >
> > As I know, DMA/CommandParser can provide asynchronous execuation of
> graphics
> > commands with CPU execution, and the direct I/O of course is synchronous
> > with instructions executed on CPU, but what is here 'synchronous' means?
> I
> > take an example of direct I/O triangle setting for 3D engine to render
> > triangle (3 vertexes) as the below piece of code:
> >
> > /*
> >  ** set graphics contexts
> >  */
> >
> > /*
> > ** using direct I/O to write 3 vertex data to 3D engine         **
> register
> > for rendering a triangle, assume the vertex data
> > ** only contain position (x,y,z,w)
> >  */
> > movl vtx.pos.1,  VP_register
> > movl vtx.pos.2,  VP_register
> > movl vtx.pos.3,  VP_register
> >
> > does 'synchronous' mean CPU won't finish the last one 'MOV' instruction
> > until the 3D engine finish rendering this triangle (finishing all TnL,
> > rasterization and pixel processing to framebuffer)? Or my understanding
> is
> > wrong? Thanks very much.
>
> Usually, if you have such an MMIO interface (where writing vertex data
> into MMIO registers directly get things drawn) what is synchronous is
> the hardware write, i.e. the write of the triangle vetex position. Now
> usually what happens after that is the triangle is still drawn
> asychronously.
>
> But wait, that's only with a single triangle. The trick is when you
> start drawing multiple triangles in a row, then maybe the 2nd one is
> blocking until the first one is drawn. Or if the hardware has an
> internal command queue for MMIO submission (which is also very common)
> maybe the 17th or the 33rd triangle will block until there is room in
> the queue.
>
> Stephane
>