Jerome Glisse wrote:
> Hi Thomas,
>
> As i am in the process of cleaning up and making radeon
> fence things bullet proof I am wondering what are the
> difference btw fence flags and fence types ? Well i guess
> the questions is more why fence flags are needed ?
>
> My understanding is that fence_flags (DRM_FENCE_FLAG_EMIT,
> DRM_FENCE_FLAG_SHAREABLE, DRM_FENCE_FLAG_WAIT_LAZY,
> DRM_FENCE_FLAG_WAIT_IGNORE_SIGNALS, DRM_FENCE_FLAG_NO_USER)
> are their to give clue to fence driver on the importance
> of the fence at least this is my understanding of
> DRM_FENCE_FLAG_WAIT_LAZY but i don't fully get the others
> flag supposed meaning would be nice if you can shed some
> light on them for me :)
>
> Corollary why has_irq callback take flag ? I would expect
> this to be based on fence type and not fence flag.
>
> Last question flush callback is their to ask that cmd before
> highest_received_sequence are all finished and that RW is
> done on all buffer referenced in all cmds preceding
> this sequence right ? Does this callback have to do the
> flush and spin until this true or can it emit what's
> necessary to flush and return and let poll update this
> once the flush ended ? Or dooes flush need to stop all
> current rendering (so stop gpu from doing its rendering)
> and do the flush ?
>
> On radeon hw i believe a reliable rw flush is to flush the
> whole pipeline ie flush vert pipeline, frag pipeline, cache
> doing all this is likely expensive and it would be better to
> avoid having too much of this kind of flush.
>
> As well i don't think i understand needed_flush.
>
> Thanks in advance for your help on this :o)
>
> Cheers,
> Jerome Glisse <[EMAIL PROTECTED]>
>
Hi, Jerome.
Some answers:
fence_flags are to tweak the behavior of calls into the fence manager.
* DRM_FENCE_FLAG_EMIT causes a fence to enter the command stream
instead of just being created.
* DRM_FENCE_FLAG_SHAREABLE makes sure the fence object is shareable
between processes.
* DRM_FENCE_FLAG_WAIT_LAZY hints that a polling wait should sleep
in-between polls.
* DRM_FENCE_FLAG_IGNORE_SIGNALS ignore signals while waiting.
* DRM_FENCE_FLAG_NO_USER don't return a user-space fence object on a
superioctl. Just have the fence live in the kernel.
fence_type is something completely different. It's there to expose GPU
states, or how far the GPU has proceeded with the command sequence
associated with the fence. This info is needed so that the buffer object
code knows when a buffer object is idle. A TTM object (buffer, regiser,
whatever) is considered idle if (object->fence_type &
object->fence->signaled_types == object->fence_type).
Let's take i915 as a typical example. Batch buffers should be idle and
can be reused as soon as the GPU command reader is done with the buffer.
At that point fence->sigaled_types will contain DRM_BO_FENCE_TYPE_EXE.
However, render targets and textures aren't idle until that has happend
AND and MI_FLUSH has executed, at which point fence->signaled_types will
also contain DRM_I915_FENCE_TYPE_RW.
In an ideal situation we would like to only issue an MI_FLUSH at the end
of a full scene, however, we might need a huge number of batch buffers
to build that scene, and we'd like to be able to reuse these as soon as
they've delivered their contents. We don't want them hanging around
useless until someone issues a MI_FLUSH at the end of the scene.
Other uses for fence_type are when different engines are fed through the
same command submission mechanism. A typical example would be the
Unichrome which has different ways to signal 2D done, 3D done, video
blit done, mpeg done etc. All these engines are fed through the same
command submission mechanism.
This is contrary to the fence_class which is intended for separate
command submission mechanisms and the TTM has ways to synchronize these
on a per-buffer level. Typical usage would be hardware with completely
separate 2D and 3D engines that operate in parallel with separate
command FIFOs.
The callback has_irq should take fence_type and not fence_flags. You're
right. I think this is just a bad naming of the parameter that has
survived cleanups.
The callback "needed_flush" is there to tell the fence manager whether
some kind of GPU flush is needed to signal any fence type in
fence->waiting_types.
In the intel example case above, If the DRM_I915_FENCE_TYPE_RW flag is
set in fence->waiting_types, a flush would be needed, but only if there
isn't already a flush pending that would make sure this flag signals.
Also, since the flushes that are currently implemented on intel are
asynchronous, a flush is not needed until the DRM_BO_FENCE_TYPE_EXE has
signaled. Otherwise we would flush a previous command sequence instead
of the intended one.
The callback "flush" should schedule a GPU flush for the
fc->pending_flush types, and clear fc->pending_flush when the flush has
been scheduled.
/ Thomas
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
