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