Thanks for all the comments! @Mike Blumenkrantz, when I built mesa with -Dgallium-drivers=radeonsi,virgl,zink, How should I instruct the mesa to use GBM/ZINK during run time? When I use "MESA_LOADER_DRIVER_OVERRIDE=zink", the test fails by "MESA: error: ZINK: failed to choose pdev".
On Mon, 22 Jul 2024 at 10:52, Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > Hi, > > If you aren't hitting the kopper init paths (e.g., kopper_init_screen), > you're doing something wrong. > > I'm not sure exactly what's going on there with gfxstream, but for > gbm+zink you should be getting a backtrace like this on init: > > #0 kopper_init_screen (screen=0x25e010, driver_name_is_inferred=false) at > ../src/gallium/frontends/dri/kopper.c:117 > #1 0x00007ffff486dc77 in driCreateNewScreen3 (scrn=0, fd=7, > loader_extensions=0x7ffff7e6c2e0 <gbm_dri_screen_extensions>, > driver_extensions=0x7ffff72ff760 <galliumvk_driver_extensions>, > driver_configs=0x25df98, driver_name_is_inferred=false, data=0x25de50) at > ../src/gallium/frontends/dri/dri_util.c:140 > #2 0x00007ffff7e5cdf8 in dri_screen_create_for_driver (dri=0x25de50, > driver_name=0x25dc10 "zink", driver_name_is_inferred=false) at > ../src/gbm/backends/dri/gbm_dri.c:300 > #3 0x00007ffff7e5cf0d in dri_screen_create (dri=0x25de50, > driver_name_is_inferred=false) at ../src/gbm/backends/dri/gbm_dri.c:337 > #4 0x00007ffff7e5f0f1 in dri_device_create (fd=7, gbm_backend_version=1) > at ../src/gbm/backends/dri/gbm_dri.c:1268 > #5 0x00007ffff7e5b76f in backend_create_device (bd=0x7ffff7e6b310 > <builtin_backends>, fd=7) at ../src/gbm/main/backend.c:105 > #6 0x00007ffff7e5b8d2 in find_backend (name=0x0, fd=7) at > ../src/gbm/main/backend.c:163 > #7 0x00007ffff7e5ba72 in _gbm_create_device (fd=7) at > ../src/gbm/main/backend.c:229 > #8 0x00007ffff7e5bbd2 in gbm_create_device (fd=7) at > ../src/gbm/main/gbm.c:138 > > > Regards, > Mike > > On Mon, Jul 22, 2024 at 10:40 AM Lei Zhou <lei.z...@linaro.org> wrote: > >> Dear mesa/experts, >> >> Need your support to help us better understand how we can go about this >> behavior. >> >> Here is what we have: >> 1. We are running QEMU based Debian guest with -device >> virtio-gpu-rutabaga,gfxstream-vulkan=on,cross-domain=on. Expect to run >> vulkan application eg.vkcube-wayland from guest via wayland proxy over >> gfxstream and wayland protocol. Please check this link ( >> https://www.qemu.org/docs/master/system/devices/virtio-gpu.html) for >> what is rutabaga/gfxstream GPU mode. In theory, it should be >> sufficient to render vkcube graphics over vulkan/gfxstream/virtio-gpu via >> host wayland compositor with a physical GPU driver. >> 2. On guest side mesa, we compile with these options >> -Dgallium-drivers=radeonsi,virgl,zink -Dvulkan-drivers=virtio,amd. >> 3. When running $vkcube-wayland with wayland proxy, >> gbm_create_device(...) will be invoked to acquire drm device resource, >> which will invoke driCreateNewScreen2 -> dri2_init_screen() etc. >> >> *within mesa/src/gallium/frontends/dri/dri2.c, what was the >> intention to indicate that "no zink" will be used?* >> =========================================== >> #ifdef HAVE_LIBDRM >> if (pipe_loader_drm_probe_fd(&screen->dev, screen->fd, *false*)) <<=== *ZINK >> usage* >> pscreen = pipe_loader_create_screen(screen->dev, >> driver_name_is_inferred); >> #endif >> ============================================= >> >> 4. In current behavior, virtio_gpu_driver_descriptor will be discovered >> and used. Which will depend on "-device virtio-gpu-gl-pci" the capsets >> of virgl and virgl2, which is not what we are using. >> >> >> Any clarification will be highly appreciated! >> >> Lei Zhou >> >>
