<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Wayland compositors are unable to use hardware acceleration on i915" href="https://bugs.freedesktop.org/show_bug.cgi?id=108487#c17">Comment # 17</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Wayland compositors are unable to use hardware acceleration on i915" href="https://bugs.freedesktop.org/show_bug.cgi?id=108487">bug 108487</a> from <a class="email" href="mailto:alexvillacislasso@hotmail.com" title="Alex Villacís Lasso <alexvillacislasso@hotmail.com>"> Alex Villacís Lasso</a> <pre>I see the exact same issue on my machine when trying weston. This bug is very similar to one I had a hand in working around in mutter: <a href="https://gitlab.gnome.org/GNOME/mutter/issues/127">https://gitlab.gnome.org/GNOME/mutter/issues/127</a> . The mutter workaround essentially tries calling gbm_bo_get_handle_for_plane() on plane 0 of the bo, sees if the call succeeded, and if not, falls back on calling gbm_bo_get_handle() while storing DRM_FORMAT_MOD_INVALID, which in turn causes the subsequent code to call drmModeAddFB[2]() instead of the unsupported drmModeAddFB2WithModifiers(). This should really be fixed in mesa. Quoting myself from the mutter bug report: ----- BEGIN QUOTE ----- @daniels I think I found the cause why mesa code fails the gbm_bo_get_handle_for_plane call with the i915 driver. However, it is not clear to me whether it is an actual bug, or just the code "working" as designed. The gbm_bo_get_handle_for_plane implementation was introduced by commit f9567ab435217a72cbae628336ead84dc0b2a803 (gbm: Export a getter for per plane handles). This implementation contains the following check, which remains to this day: if (!dri->image || dri->image->base.version < 13 || !dri->image->fromPlanar) { errno = ENOSYS; return ret; } One of the conditions for the call is that the base.version member is 13 or above. This member (dri->image) is a __DRIimageExtension *, according to src/gbm/backends/dri/gbm_driint.h in the Mesa code. There are several DRI drivers that define a static __DRIimageExtension with type __DRI_IMAGE, along with an API version. In the case of i965 (src/mesa/drivers/dri/i965/intel_screen.c), the api is at version 16. However, in the case of i915 (src/mesa/drivers/dri/i915/intel_screen.c) the api is at version 7. At first sight, it looks as though the version check in the initial commit is too restrictive. According to include/GL/internal/dri_interface.h in the Mesa code, the fromPlanar member of __DRIimage should be available since __DRI_IMAGE API version 5. However, the commit does not include comments on why version 13 is the minimum required for fetching the plane handle. Again, according to include/GL/internal/dri_interface.h, the one property that requires 13 as a minimum is __DRI_IMAGE_ATTRIB_OFFSET. So maybe the code assumes that whoever calls gbm_bo_get_handle_for_plane will also fetch the offset. ----- END QUOTE -----</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>