All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: jan.kiszka@siemens.com,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	qemu-devel <qemu-devel@nongnu.org>,
	cota@braap.org, "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	bobby.prani@gmail.com, rth@twiddle.net,
	"Alex Bennée" <alex.bennee@linaro.org>,
	fred.konrad@greensocs.com
Subject: Re: [Qemu-devel] [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution"
Date: Thu, 16 Mar 2017 18:00:19 +0100	[thread overview]
Message-ID: <4fa44363-76fe-d33c-249c-b1af88f09f9f@redhat.com> (raw)
In-Reply-To: <1489678462.15659.112.camel@redhat.com>



On 16/03/2017 16:34, Gerd Hoffmann wrote:
> Well, not *that* simple.  vga checks the dirty bitmap with scanline
> granularity, like that:
> 
>   foreach (scanline) {
>      if (get_dirty(scanline))
>         update_scanline()
>   }
>   reset_dirty(framebuffer)
> 
> I suspect simply transforming that to
> 
>   foreach (scanline) {
>      if (test_and_clear_dirty(scanline))
>        update_scanline()
>   }
> 
> is not going to fly due to page tracking working with page granularity.
> With two subsequent scanlines within one page the second scanline will
> never be updated because updating first clears the dirty bit of the
> page ...
> 
> Looping twice over all scanlines, with the first loop just figuring
> which scanlines are modified, then clear dirty bits, then update in a
> second loop should work I think.  It'll duplicate a bunch of code
> though, because in reality the loop isn't just three lines because of
> doublescan, interlave and other funky stuff coming from CGA
> compatibility.
> 
> Given that probably pretty much every display adapter is affected I'd
> tend to take Alex patch for 2.9, then sort the mess in the 2.10 devel
> cycle and revert the patch when done.

You're right; an alternative is to copy the dirty bitmap to a local one
and clear the global one (the dirty bitmap for an 8 MB full HD frame
buffer is just 256 bytes).  With the right API to abstract the job, it
should be relatively easy to fix all adapters.

Paolo

  reply	other threads:[~2017-03-16 17:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <36e41adf-b0b3-3efa-51c4-f1a70cd05b98@ilande.co.uk>
2017-03-13 21:28 ` [Qemu-devel] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution" Mark Cave-Ayland
     [not found] ` <87wpbsp49a.fsf@linaro.org>
2017-03-14 11:12   ` Mark Cave-Ayland
2017-03-14 13:56     ` [Qemu-devel] [Qemu-ppc] " BALATON Zoltan
2017-03-14 15:02       ` luigi burdo
2017-03-14 15:41       ` Alex Bennée
2017-03-14 15:52         ` Mark Cave-Ayland
2017-03-14 16:48           ` Alex Bennée
2017-03-14 17:34             ` BALATON Zoltan
2017-03-14 17:53               ` luigi burdo
2017-03-15 11:14               ` Alex Bennée
2017-03-15 13:26                 ` Mark Cave-Ayland
2017-03-15 14:19                   ` Alex Bennée
2017-03-16  6:39               ` Paolo Bonzini
2017-03-16  7:51                 ` Alex Bennée
2017-03-16  8:34                   ` Paolo Bonzini
2017-03-16 15:34                     ` Gerd Hoffmann
2017-03-16 17:00                       ` Paolo Bonzini [this message]
2017-03-28 13:40                         ` Gerd Hoffmann
2017-03-28 14:13                           ` Paolo Bonzini
2017-03-15 14:16           ` Alex Bennée
2017-03-15 15:25             ` Gerd Hoffmann
2017-03-15 16:20               ` Alex Bennée
2017-03-16  7:35                 ` Gerd Hoffmann
2017-03-16  7:56                   ` Alex Bennée
2017-03-16 14:22                   ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4fa44363-76fe-d33c-249c-b1af88f09f9f@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=bobby.prani@gmail.com \
    --cc=cota@braap.org \
    --cc=fred.konrad@greensocs.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kraxel@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.