vk-gl-interop: modifier usage broken

[zmike]

I haven't debugged this too deeply, but it looks to me like the wrong modifier is being selected either during vk image creation or gl import, which is why it happens to work on some drivers and fails on others.

I'd suggest referencing piglit dmabuf tests to ensure everything is being done to utilize a LINEAR modifier as the case here is expecting.

[yuq]

Some driver like radv/radeonsi pair will share buffer layout/format by underlying KMD metadata, for example radv create a image buffer and set its metadata with drm ioctl, then pass to xserver which is based on radeonsi, radeonsi import it and read the metadata from drm ioctl and know its layout/format. So radv/radeonsi don't need to rely on modifier.

If xserver is zink based, and client is radv, can this mechanism still work? Though zink don't know the imported image layout without modifier, but its underlying radv could, expect it doesn't do it for zink imported image?

[yuq]

I guess your words "think it needs xserver changes" for xserver on zink means xserver need to change to always use modifier?

[zmike]

I'm not trying to run an xserver on zink.

This app seems broken. Either you should be using gbm_bo_import_with_modifiers() with explicit LINEAR to ensure drivers can use the right modifier, or you should be using the actual EXT_external_objects extension for interop. There's no way that implicit modifier selection is going to work across APIs like this, even if it happens to work on other drivers.