On Wed, Feb 27, 2008 at 1:06 PM, Thomas Hellström <[EMAIL PROTECTED]> wrote: > > Alex Deucher wrote: > > On Wed, Feb 27, 2008 at 9:03 AM, Thomas Hellström > > <[EMAIL PROTECTED]> wrote: > > > >> 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 was really helpful, any objections to me putting it on > > the dri wiki? > > > > Alex > > > Not at all. Need to change > > > (object->fence_type & object->fence->signaled_types == object->fence_type). > > to > > ((object->fence_type & object->fence->signaled_types) == object->fence_type), > > though.
Thanks. Added as: http://dri.freedesktop.org/wiki/TTMFencing Alex ------------------------------------------------------------------------- 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
