<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><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 <span class="vcard"><a class="email" href="mailto:alexvillacislasso@hotmail.com" title="Alex Villacís Lasso <alexvillacislasso@hotmail.com>"> <span class="fn">Alex Villacís Lasso</span></a>
</span></b>
<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>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>