[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes
From: |
Benjamin Herrenschmidt |
Subject: |
Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes |
Date: |
Tue, 17 Jun 2014 21:15:21 +1000 |
On Tue, 2014-06-17 at 12:45 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > The core issue stems from the fact that graphic stacks including X and a
> > number of other components along the way are terminally broken if the
> > framebuffer endianness doesn't match the guest endianness. We can
> > discuss the historical reasons for that fact if you wish and we can
> > discuss why it is almost unfixable separately.
>
> "framebuffer" as in "linux framebuffer device" or as in "whatever memory
> area X11 renders into" ?
Linux fbdev has some ability to deal with foreign endian but at a
performance cost.
Xorg has much more serious issues, unless we start using something like
shadowfb and byteswap everything on the way out, but again, at a
significant performance cost.
> > This is an obvious problem for qemu on ppc64 since we now support having
> > either BE or LE guests.
> >
> > At the moment, we have a broken patch in offb that makes the guest
> > sort-of limp along with the reversed framebuffer but that patch is
> > broken in several ways so I've reverted it upstream and X wouldn't work
> > anyway.
>
> Side note: tried "CONFIG_DRM_BOCHS=m"?
>
> In theory it should just work. I've never actually tested it in
> practice on bigendian.
It should provided we have the right byte order in qemu for the guest
endian :-) But if it's the KMS driver I think it is yes, I did try an
earlier version, and it should work with the same problem that qemu
needs to change it's layout with the guest endian.
> Not sure it helps in any way with the byteorder issue though. Probably
> not. Could help with the "how do we flip the framebuffer byteorder"
> though, as we can simply define a new register and let the driver set
> it.
Right.
> > This is purely about discussing the changes to vga.c and vga-templates.h
> > to be able to handle the swapping in a runtime-decided way rather than
> > compile time.
>
> > What do you prefer ?
>
> Let pixman handle it? Well, except that pixman can't handle byteswapped
> 16bpp formats. Too bad :(
Right :) As I said, it's a trainwreck along the whole stack. I think my
second patch is reasonably non-invasive and shouldn't affect performance
of the existing path though.
> In any case cleaning up the whole mess is overdue and doing that
> beforehand should simplify the job alot. For quite some time qemu uses
> 32bpp internally no matter what, so the functions for converting the
> guest's framebuffer into anything but 32bpp should be dead code.
I'm happy for that to happen upstream though I think I might go with my
current hack for powerkvm so we have a more immediate solution for
ubuntu and possibly sles12.
> And as long as the guest uses 32bpp too there is nothing converted
> anyway, we just setup pixman image in the correct format, backed by the
> guests vga memory. So this ...
pixman byteswaps 32bpp ? Good, I'd rather leave the work to it since it
has vector accelerations and other similar niceties which would make it
a better place than qemu.
However we still need to deal with 15/16bpp guest side fb
> > @@ -1645,11 +1690,9 @@ static void vga_draw_graphic(VGACommonState *s, int
> > full_update)
> > uint8_t *d;
> > uint32_t v, addr1, addr;
> > vga_draw_line_func *vga_draw_line;
> > -#if defined(HOST_WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
> > - static const bool byteswap = false;
> > -#else
> > - static const bool byteswap = true;
> > -#endif
> > + bool byteswap;
> > +
> > + byteswap = vga_need_swap(s, vga_is_big_endian(s));
> >
> > full_update |= update_basic_params(s);
> >
> > @@ -1691,7 +1734,8 @@ static void vga_draw_graphic(VGACommonState *s, int
> > full_update)
> > if (s->line_offset != s->last_line_offset ||
> > disp_width != s->last_width ||
> > height != s->last_height ||
> > - s->last_depth != depth) {
> > + s->last_depth != depth ||
> > + s->last_bswap != byteswap) {
> > if (depth == 32 || (depth == 16 && !byteswap)) {
> > surface = qemu_create_displaysurface_from(disp_width,
> > height, depth, s->line_offset,
> > @@ -1707,6 +1751,7 @@ static void vga_draw_graphic(VGACommonState *s, int
> > full_update)
> > s->last_height = height;
> > s->last_line_offset = s->line_offset;
> > s->last_depth = depth;
> > + s->last_bswap = byteswap;
> > full_update = 1;
> > } else if (is_buffer_shared(surface) &&
> > (full_update || surface_data(surface) != s->vram_ptr
>
> ... is all you need to make things fly for the 32bpp case.
Provider we also give pixman the right pixel format for "reverse endian"
which we don't do today and I yet have to investigate it :-) The pixmap
stuff in qemu to be honest is news to me, last time I looked it was SDL
and hand made vnc. Is the vnc server going though pixman as well ?
Cheers,
Ben.
- Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes, (continued)
Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes, Gerd Hoffmann, 2014/06/17
Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes,
Benjamin Herrenschmidt <=
- Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes, Gerd Hoffmann, 2014/06/17
- Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes, Benjamin Herrenschmidt, 2014/06/17
- Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes, Peter Maydell, 2014/06/17
- Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes, Benjamin Herrenschmidt, 2014/06/17
- Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes, Alexander Graf, 2014/06/17
- Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes, Benjamin Herrenschmidt, 2014/06/17
Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes, Gerd Hoffmann, 2014/06/18
Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes, Benjamin Herrenschmidt, 2014/06/18
Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes, Gerd Hoffmann, 2014/06/19
Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes, Benjamin Herrenschmidt, 2014/06/21