On Sun, 7 Sep 2008 12:40:00 +0200 Jerome Glisse <[EMAIL PROTECTED]> wrote:
> Hi, > > During XDS their was a long discussion on the DRI2 and vblank blit. > For hw which support multiple queue and queue preempting the solution > is pretty straightforward. On the opposite hw like radeon (at least > from r100 up to r500) it's not as easy. We can stick blit command > into the stream with wait for vsync but this would stall cp and so > all others rendering command stream. Keith suggested that we emulate > multiple queue in software. So following this idea here is what i > have been thinking of for radeon. > > With each cs kernel get the userspace tell if it wants to wait for > vblank and if so on which crtc. Then in the kernel we have 3 queue : > > 1 - cmd which have to happen at vblank > 2 - cmd which can be executed any time > 3 - cmd which rely on a previous cmd not yet executed > > For cmd synchronized with vblank we put then in the vblank queue > and mark each written object with a fence for pending write. The > fence i am talking about is not the fence which we get once > cmd is executed and data flushed but a fence which expire once > the cmd is in the ring as we know that there is flush after each > cmd we can safely queue request in the ring. > > For others cmd we go through the buffer object referenced and we > check that there is no pending write fence associated with any of > the buffer ie all previous cmd which write to any of these buffers > have already been scheduled in the cmd stream. If there is no > such BO we put the cmd into the queue 2. > > If there is one BO which used as a read source in the cmd stream > and which have a pending fence for write then the cs is put into > the queue 3. > > Queue 3 exist to enforce data coherency assuming that X server > or others client space application serialize their drawing cs > ioctl call. > > > Here are issues we have to cope with (i might have not > thought to all of them) : > > When do we push cmd from queue 2 or 3 into the ring ? > > I believe we should have a function in charge of this. And we > would call this function at end of the cs ioctl and end of the > vblank irq tasklet handler so that all of the queue can be > scheduled. I believe we should not have any kind of tasklet we > wakeup from times to times to schedule cmd from queue into the > ring, this would be bad for powersaving. Also cmd from queue 3 > should be scheduled before cmd from queue 2. > > > How to avoid filling up the ring ? > > We don't want to much cmd into the ring as the idea is that > when vblank happen the insertion of the cmd into the ring > should be executed during vblank time ie the cp will process > these cmd really soon after their insertion into the ring. > In order to achieve this i believe each time we have somethings > into the queue 1 we should predict the time at which next > vblank will happen, then in the function which schedule queue > 2 and 3 we should not append any cmd into the ring if we are > near the next vblank time (some kind of heuristic would be > needed here). > > > When do we validate ? > > I think we should valide just before putting the cmd into the > ring as other cmd stream might move referenced buffer around. > > > Dave i believe no new ioctl for radeon should be push upstream > until this DRI2 vblank is sorted out and we had some times to > make sure it works. > > The solution proposed here is definitly a bit clompex but if > we want to avoid stalling the cp at each vblank sync blit i > don't see any simpler way to achieve it. Also this solution > doesn't garanty vblank sync blit, it just try to make such > kind of blit to likely happen at vblank time. > > Also this doesn't change the other fencing & flushing cmd > subimission which have been previously discussed. Side note : Anothers idea would be to sync for vblank only for compiz. We can hack compiz to always use swapbuffer and then use pageflip. But i think others might want to avoid using swapbuffer all times for compiz. Cheers, Jerome Glisse <[EMAIL PROTECTED]> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
