mesa3d-dev

[Mesa3d-dev] MMIO/DMA ?

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

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.

Regards

Re: [Mesa3d-dev] MMIO/DMA ?

[Stephane M. <ste...@gm...>]

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

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
>

Re: [Mesa3d-dev] MMIO/DMA ?

[Stephane M. <ste...@gm...>]

On Tue, Feb 23, 2010 at 22:54, Westermann Fu <wes...@gm...> wrote:
> 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.
>

[with a proper reply all this time]

On all MMIO GPUs that I know which work like that, the CPU will block
and wait for as long as it takes. But usually you also have a reg you
can poke to know the current filling status of the fifo (full/some
free space), and you can use that to avoid sending too many triangles
and end up in a blocking situation.

Stephane