On 9/7/2026 9:12 PM, Dmitry Osipenko wrote:
On 8/20/26 13:49, Huang, Honglei wrote:
...
These are great news. I suggest updating the MR description then so
that potential reviewers can see the progress.
Will update the virtio userptr and virglrenderer PR in future. But
unclear how compute will eventually evolve on virtio. The virgl version
may only support old ROCm version.
And a single control queue is the design of the virtio GPU, and it is
indeed a bottleneck, modifying it is difficult. However, some other
virtio devices have multi queues for different usages.
And actually such as NPUs, TPUs, or custom ASICs, no display compute
card all go to the virglrenderer seem like not a natural long term
abstraction.
It's not clear to me if you're still wanting to have current virtio-gpu
ROCm context version landed upstream, or you now looking for a better
alternative?
Virtio-gpu multi-queue support was in discussions over past years,
primary driven by ChromeOS+crosvm needs. Yes, it's not a trivial task to
support multi-queue, no progress was made on it AFAIK.
Yes, we are still aiming to land the upstream ROCm native context on
virtio-gpu.
And please take the large buffer mapping into design consider for multi
queue support, we have a performance bottleneck here.
Regards,
Honglei
