On 11/11/24 08:25, Akihiko Odaki wrote:
>>
>> I feel like using "drm" is confusing in this context because drm exists
>> for the host and guest. What about "native-context" or even
>> "context=[opengl|vulkan|wayland|native]"?
>
> The terminology in the specification is "capset". Multiple capabilit
On 2024/10/31 19:26, Alex Bennée wrote:
Dmitry Osipenko writes:
Add support for DRM native contexts to VirtIO-GPU. DRM context is enabled
using a new virtio-gpu-gl device option "drm=on".
I feel like using "drm" is confusing in this context because drm exists
for the host and guest. What abo
On 11/1/24 20:13, Dmitry Osipenko wrote:
>> As an aside can mesa build the intel drivers on non-x86 systems as now I
>> could potentially pass my native intel context to my emulated aarch64
>> guests?
> In general it should work. Don't know for sure how well Intel Mesa
> driver works on ARM, suppos
On 10/31/24 13:26, Alex Bennée wrote:
> Dmitry Osipenko writes:
>
>> Add support for DRM native contexts to VirtIO-GPU. DRM context is enabled
>> using a new virtio-gpu-gl device option "drm=on".
>
> I feel like using "drm" is confusing in this context because drm exists
> for the host and guest
Dmitry Osipenko writes:
> Add support for DRM native contexts to VirtIO-GPU. DRM context is enabled
> using a new virtio-gpu-gl device option "drm=on".
I feel like using "drm" is confusing in this context because drm exists
for the host and guest. What about "native-context" or even
"context=[op
Add support for DRM native contexts to VirtIO-GPU. DRM context is enabled
using a new virtio-gpu-gl device option "drm=on".
Unlike Virgl and Venus contexts that operate on application API level,
DRM native contexts work on a kernel UAPI level. This lower level results
in a lightweight context impl
