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. 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
