Re: ZINK support to use libvulkan on Virtio-GPU

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 <
[email protected]> 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 <[email protected]> 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
>>
>>