[PATCH 3/3] exa/mixed: Exclude frontbuffer from deferred pixmap handling.

[Maarten Maathuis]

2011/1/19 Michel Dänzer <michel at daenzer.net>:
> On Mit, 2011-01-19 at 18:29 +0100, Maarten Maathuis wrote:
>> 2011/1/19 Michel Dänzer <michel at daenzer.net>:
>> > On Mit, 2011-01-19 at 10:09 +0100, Maarten Maathuis wrote:
>> >> This is it, 10 ms a short time and even with this value large amounts
>> >> of text are still not shown fluently (the impression that some pieces
>> >> are never drawn). This is on top of the previous 3 patches.
>> >>
>> >> diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
>> >> index 4f49905..c0c730d 100644
>> >> --- a/exa/exa_migration_mixed.c
>> >> +++ b/exa/exa_migration_mixed.c
>> >> @@ -150,12 +150,26 @@ exaDamageReport_mixed(DamagePtr pDamage,
>> >> RegionPtr pRegion, void *closure)
>> >>      if (!pExaPixmap->use_gpu_copy && exaPixmapHasGpuCopy(pPixmap)) {
>> >>       ExaScreenPriv(pPixmap->drawable.pScreen);
>> >>
>> >> -     /* Front buffer: Don't wait for the block handler to copy back the data.
>> >> -      * This avoids annoying latency if you encounter a lot of software rendering.
>> >> +     /* Front buffer: Don't wait for the block handler to copy back the
>> >> data, unless
>> >> +      * it has been moved back in the last 10 ms. This avoid annoying latency when
>> >> +      * troughput is low, but keeps troughput acceptable at higher levels.
>> >>        */
>> >> -     if (pPixmap == pScreen->GetScreenPixmap(pScreen))
>> >> -             exaMoveInPixmap_mixed(pPixmap);
>> >> -     else {
>> >> +     if (pPixmap == pScreen->GetScreenPixmap(pScreen)) {
>> >> +             CARD32 now = GetTimeInMillis();
>> >> +             if ((now - pExaScr->last_time_front_mixed_pixmap) > 10) {
>> >> +                     pExaScr->last_time_front_mixed_pixmap = now;
>> >> +                     exaMoveInPixmap_mixed(pPixmap);
>> >> +
>> >> +                     if (pExaScr->deferred_mixed_pixmap == pPixmap)
>> >> +                             pExaScr->deferred_mixed_pixmap = NULL;
>> >> +             } else {
>> >> +                     if (pExaScr->deferred_mixed_pixmap &&
>> >> +                         pExaScr->deferred_mixed_pixmap != pPixmap)
>> >> +                         exaMoveInPixmap_mixed(pExaScr->deferred_mixed_pixmap);
>> >> +
>> >> +                     pExaScr->deferred_mixed_pixmap = pPixmap;
>> >> +             }
>> >> +     } else {
>> >>               if (pExaScr->deferred_mixed_pixmap &&
>> >>                   pExaScr->deferred_mixed_pixmap != pPixmap)
>> >>                   exaMoveInPixmap_mixed(pExaScr->deferred_mixed_pixmap);
>> >
>> > I still can't help wondering if we aren't missing something about what
>> > makes the difference between the text being 'shown' or not[0], but this
>> > approach would be getting rather complicated already, and if there's no
>> > timeout period which gives a better tradeoff between latency and
>> > throughput, I guess erring on the side of the former is better for now.
>> > So, feel free to add my
>>
>> One experiment would be to do a exaMoveInPixmap_mixed when (let's say)
>> 10% of the screen becomes dirty, but this is even more complicated.
>> But I'm willing to try if you think it's a good idea.
>
> I don't think it is. If latency is really the issue, the timeout period
> approach seems most appropriate.

I just remembered that nouveau will do UTS by pushing data into the
command stream at small sizes and using gart to vram transfers
otherwise. Might have to look into that (not that you want to push
very large amounts of data into the command stream all the time).

>
>
> --
> Earthling Michel Dänzer           |                http://www.vmware.com
> Libre software enthusiast         |          Debian, X and DRI developer
>



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.