Jerome Glisse wrote: > On Wed, 27 Feb 2008 15:03:34 +0100 > 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 >> > > Thanks a lot Thomas for all this explications, i now have a lot better > understanding of this stuff :) Do you mind if i do some name cleanup > fence_flag->fence_type for has_irq and stuff like that ? > > No, on the contrary. Go ahead!!
/Thomas > Cheers, > Jerome Glisse <[EMAIL PROTECTED]> > ------------------------------------------------------------------------- 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
