...
Minute takers according to this page
August 10
Gunnar introduced the AVPS goals a bit and mentioned that in some hardware areas (and almost surely for GPU), the AVPS specification can/should not reach the point where it requires only one way of doing things. It can still be useful to dig deeper into a few things, and then describe a few different choices through optional or conditional requirements. It is still much more useful to have that analysis done when a production project starts than to have a blank page.
Daniel: Requiring Vulkan would make sense but will not be supported everywhere so unfortunately it cannot be the only choice. GL API is stable.
Peter: [We need to discuss] technology roadmap for next generation GPUs (HW support for virtualization)
Daniel:
ARM, Renesas, Qualcomm, others would need to discuss this to get the information, but everything might not be shared.
...HV vendors implement this when the technology is ready (NDAs)
Every VM has it’s own virtualized GPU. Dedicated command queue per VM. Buffer handling can be challenging (sec/safety, etc.) It gives you a “direct access” to the hardware. Normal drivers and software can be used, because it looks like a GPU.
Peter: Can a standard model for GPU be defined which can help development (of specification and code/solutions)? Command queue is common for all.
Daniel: Concentrating on the API definition which can be generic, and over time hardware support could make the implementation of it easier. This is the VIRTIO queue API level.
Ozgur: What about the original VIRTIO-GPU 3D specification
Daniel: It is similar to VirGL but was not quite the same.
Discussion would be needed with the real graphics engineers (within ARM, Imagination, Qualcomm….) to see if they are open to discuss standard APIs in one level.
Ozgur: Vulkan path is yet another choice?
Daniel: Conceptually similar. Host/HV would still need to manage resources, track all the Vulkan objects, buffers, textures, targets. This is the same for virtualization of Vulkan and OpenGL.
Ozgur: SoC providers do not want to rewrite their implementation (e.g. to support VIRTIO queues [or other standard virtualization API] Basically they provide everything from user space APIs to the hardware…
...
Daniel: Yes, I agree. Hardware independent and hardware dependent APIs will likely be different APIs. We can (only) expect a few basic things about HW dependent (using channels/queues and buffer handling).
Ozgur: VIRTIO is only concerned with multi client rendering?
Daniel: Yes, it does not handle multi leases and other more complex situations.
Ozgur: Can we start thinking about things like nested compositors?
Daniel: DRM/KMS provides some capability for HW compositors but not the constraints you need (to match the (virtual) hardware capabilities).
Ozgur: Will it need kernel/driver changes?
Daniel: It’s primarily the API side for virtualization.
Daniel: Way forward. Split the problem.
1. Write how we think a fully hardware specific path will work. (a generic model for how w e think HW assisted virtualization is done)
2. The fully generic VirGL / vulkan path. We can start encoding more specific requirements.
Ozgur: What can be implemented to test this now?
Daniel: VirGL already works on top of any OpenGL (GLES) implementation. Mesa, and also others.
Way forward
Daniel: I’m happy to encode the requirements that we have already today in VirGL. Over time I can try to do the same for the Vulkan path. For the HW specific approach, can we reach out to the platform vendors? or HV implementing companies that are likely implementing some of these things now [with the latest hardwares].
Gunnar asks Dmitry to see if there is a way to have a (private) conversation with potentially ongoing commercial implementation projects, to draw the boundaries between what could drive the specification content (and what could not).
Peter: The model approach is very good because we would then be less dependent on the hardware vendor proprietary information while this is being built out.
Gunnar mentions that ongoing work should be complementary and can together improve the situation, from specification side, and from trying out implementations on AGL and other projects. The AVPS work provides the API specification, ensures multi-OS aspect is not lost, and aims to influence AUTOSAR and other industry initiatives to align on a common way forward [based on the open development of AVPS].
Daniel: It would be useful to get Panasonic’s input since they drive a lot of implementation in AGL for virtualization.
Gunnar: Yes. Both the implementation and AVPS is VIRTIO focused which should help compatibility.
July 20
Participants
- Dmitry
- Adam
- Oleksandr
- Kai
- Gunnar
...