Re: [PATCH v1 0/9] gfxstream + rutabaga_gfx

2023-07-25 Thread Gurchetan Singh
On Mon, Jul 24, 2023 at 2:56 AM Alyssa Ross  wrote:
>
> Gurchetan Singh  writes:
>
> > In terms of API stability/versioning/packaging, once this series is
> > reviewed, the plan is to cut a "gfxstream upstream release branch".  We
> > will have the same API guarantees as any other QEMU project then, i.e no
> > breaking API changes for 5 years.
>
> What about Rutabaga?

Yes, rutabaga + gfxstream will both be versioned and maintain API
backwards compatibility in line with QEMU guidelines.



Re: [PATCH v1 0/9] gfxstream + rutabaga_gfx

2023-07-24 Thread Alyssa Ross
Gurchetan Singh  writes:

> In terms of API stability/versioning/packaging, once this series is
> reviewed, the plan is to cut a "gfxstream upstream release branch".  We
> will have the same API guarantees as any other QEMU project then, i.e no
> breaking API changes for 5 years.

What about Rutabaga?


signature.asc
Description: PGP signature


[PATCH v1 0/9] gfxstream + rutabaga_gfx

2023-07-10 Thread Gurchetan Singh
From: Gurchetan Singh 

Latest iteration of rutabaga_gfx + gfxstream patches.  Previous version
and more background available here:

https://patchew.org/QEMU/20230421011223.718-1-gurchetansi...@chromium.org/

Changes since RFC:
- All important memory tests pass
- Went with separate virtio-gpu-rutabaga device as suggested by Bernard
  Berschow
- Incorporated review feedback, mostly from Akihiko Odaki
- gfxstream has new unified guest/host repo + build system improvements
- added documentation on virtio-gpu
- new instructions on how to build available in the tracking bug [a]

In terms of API stability/versioning/packaging, once this series is
reviewed, the plan is to cut a "gfxstream upstream release branch".  We
will have the same API guarantees as any other QEMU project then, i.e no
breaking API changes for 5 years.

The Android Emulator will build both gfxstream (to get bug fixes fast)
and QEMU8.0+ (due to regulatory requirements) from sources.  So we haven't
created a gfxstream Debian/Ubuntu package since we actually don't need it.
Though, we plan to upload our QEMU8.0+ gfxstream enabled builds somewhere
on AOSP when it's ready.

It's more important for us to be in-tree to reduce technical debt given
this.  Let us know if there are any strong opinions on packaging.

Otherwise, feedback + reviews welcome!

[a] https://gitlab.com/qemu-project/qemu/-/issues/1611

Antonio Caggiano (2):
  virtio-gpu: CONTEXT_INIT feature
  virtio-gpu: blob prep

Dr. David Alan Gilbert (1):
  virtio: Add shared memory capability

Gerd Hoffmann (1):
  virtio-gpu: hostmem

Gurchetan Singh (5):
  gfxstream + rutabaga prep: added need defintions, fields, and options
  gfxstream + rutabaga: add initial support for gfxstream
  gfxstream + rutabaga: meson support
  gfxstream + rutabaga: enable rutabaga
  docs/system: add basic virtio-gpu documentation

 docs/system/device-emulation.rst |1 +
 docs/system/devices/virtio-gpu.rst   |   80 ++
 hw/display/meson.build   |   22 +
 hw/display/virtio-gpu-base.c |6 +-
 hw/display/virtio-gpu-pci-rutabaga.c |   48 ++
 hw/display/virtio-gpu-pci.c  |   14 +
 hw/display/virtio-gpu-rutabaga.c | 1088 ++
 hw/display/virtio-gpu.c  |   17 +-
 hw/display/virtio-vga-rutabaga.c |   52 ++
 hw/display/virtio-vga.c  |   33 +-
 hw/virtio/virtio-pci.c   |   18 +
 include/hw/virtio/virtio-gpu-bswap.h |   18 +
 include/hw/virtio/virtio-gpu.h   |   34 +
 include/hw/virtio/virtio-pci.h   |4 +
 meson.build  |7 +
 meson_options.txt|2 +
 scripts/meson-buildoptions.sh|3 +
 softmmu/qdev-monitor.c   |3 +
 softmmu/vl.c |1 +
 19 files changed, 1431 insertions(+), 20 deletions(-)
 create mode 100644 docs/system/devices/virtio-gpu.rst
 create mode 100644 hw/display/virtio-gpu-pci-rutabaga.c
 create mode 100644 hw/display/virtio-gpu-rutabaga.c
 create mode 100644 hw/display/virtio-vga-rutabaga.c

-- 
2.41.0.255.g8b1d071c50-goog