Alex Deucher wrote: > 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 > Thanks. Added Jerome's flush-bit-in-sequence-blit suggestion and a section about the command_stream_barrier() callback, which might be handy also for Radeons.
/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
