qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global l


From: BALATON Zoltan
Subject: Re: [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution"
Date: Tue, 14 Mar 2017 14:56:03 +0100 (CET)
User-agent: Alpine 2.20 (BSF 67 2015-01-07)

On Tue, 14 Mar 2017, Mark Cave-Ayland wrote:
On 14/03/17 10:00, Alex Bennée wrote:
Mark Cave-Ayland <address@hidden> writes:

I've recently noticed some video artifacts appearing in the form of
horizontal lines whilst testing OpenBIOS boot on some qemu-system-ppc
images (see https://www.ilande.co.uk/tmp/qemu/macos9-stripe.png for an
example) which I've finally bisected down to this commit.

Interesting. Is the video hardware in this case a simple framebuffer or
is there some sort of GPU involved?

For the mac99 machine it's just the normal QEMU PCI std-vga card, so
nothing special. Having run tests across SPARC which uses its own
framebuffer, there have been no obvious artifacts that I've spotted
there to date.

The horizontal lines tend to appear at different positions with
different lengths, although it seems to be more common that a complete
scanline is affected. Reproducing the issue is fairly easy with a MacOS
9.2.1 ISO and the command line below:

./qemu-system-ppc -cdrom MacOS921.iso -boot d -m 512 -M mac99

Could it be that this patch is still missing a lock somewhere which
causes these artifacts to appear?

It depends. If the hardware is accessed via MMIO then the BQL is taken
automatically (unless the area is explicitly marked as doing its own
locking see: mr->global_locking).

Is the artefact temporary or permanent? Could it be a change in
synchronisation between the emulator updating the framebuffer and
whatever backend updating its display?

AFAICT they are temporary in that they appear randomly on the display,
but the next time that particular area of the display is updated by the
guest then they tend to either change/disappear.

I've also noticed artifacts when testing the SM501 changes with MorphOS on recent QEMU so it may not be related to just the std vga. It's shown as bands (larger number of adjacent scanlines) not updating when the client first wrote to the framebuffer but then they disappeared during the next refresh. I'm guessing it may be related to dirty checking of the framebuffer memory which is used to decide when a scan line needs update?

Regards,
BALATON Zoltan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]