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 ------------------------------------------------------------------------- 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
