[virglrenderer-devel] "containered" virgl

[Dave Airlie]

I've heard people saying that having virgl being used in a container
might be a good idea, but I don't really have the knowledge of what it
would look like architecturally.

Though I decided today to try and enhance vtest to avoid the software
readback for putimage path, which is the main overhead.

I've created two branches at [1],[2] below.

This adds fd passing abilities to the vtest socket and passes the fd
from DRI3 to the vtest server to use for running it's context on, and
it fills out the get handle path to pass an fd back that
can be passed to the X server for DRI3 operations.

I've got openarena up and running on this, the gbm/EGL scanout
allocation path is bit annoying, but otherwise the colors won't end up
right at all. On my HSW openarena anholt.cfg runs at 130fps vs 160fps
native, vs 50fps for the old vtest.

Once you set MESA_LOADER_DRIVER_OVERRIDE=virtio_gpu it should try and
open the vtest socket when it can't use the drm device node itself.

I'm assuming this could be useful for container applications, but I'd
really have to have someone from that world want this to be a solution
and champion it a lot.

I'm not sure how much more effort I can put into it without a decent use case.
Thanks,
Dave.

[1] https://gitlab.freedesktop.org/airlied/virglrenderer/tree/vtest-fd-pass
[2] https://cgit.freedesktop.org/~airlied/mesa/log/?h=vtest-fd-pass