Re: kcmp implementation for mesa

Rozhuk Ivan <rozhuk.im@gmail.com> writes:

>  * The 2 fds can be different, even in systems with a single GPU, eg: if
>  * radv is initialized before radeonsi.
>  *
>  * This fd tracking is useful for buffer sharing because KMS/GEM handles are
>  * specific to a DRM file description, i.e. the same handle value may refer
>  * to different underlying BOs in different DRM file descriptions.
>  * As an example, if an app wants to use drmModeAddFB it'll need a KMS handle
>  * valid for its fd (== amdgpu_screen_winsys::fd).
>  * If both fds are identical, there's nothing to do: bo->u.real.kms_handle
>  * can be used directly (see amdgpu_bo_get_handle).
>  * If they're different, the BO has to be exported from the device fd as
>  * a dma-buf, then imported from the app fd as a KMS handle.

Just FYI, some types of export/import dma-bufs may not work on FreeBSD due to
https://github.com/freebsd/drm-kmod/issues/278

export/import ioctls are mainly used in Vulkan WSI while kcmp() is used in
OpenGL drivers (iris, radeonsi, etc), so it's probobably only necessary
between a Vulkan-based compositor (wlroots for Wayland, chamfer for X11)
and an OpenGL client (web browsers, old or open source games, etc). How
much of that requires emulating kcmp() is unclear to me.