From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 108487] Wayland compositors are unable to use hardware acceleration on i915 Date: Sat, 27 Apr 2019 23:33:53 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1152122190==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 5B0CD8922B for ; Sat, 27 Apr 2019 23:33:53 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1152122190== Content-Type: multipart/alternative; boundary="15564080331.C597E.8173" Content-Transfer-Encoding: 7bit --15564080331.C597E.8173 Date: Sat, 27 Apr 2019 23:33:53 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D108487 --- Comment #17 from Alex Villac=C3=ADs Lasso --- I see the exact same issue on my machine when trying weston. This bug is ve= ry similar to one I had a hand in working around in mutter: https://gitlab.gnome.org/GNOME/mutter/issues/127 . The mutter workaround essentially tries calling gbm_bo_get_handle_for_plane() on plane 0 of the b= o, 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 cau= ses 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 rep= ort: ----- 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 c= lear 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->fromPla= nar) { errno =3D 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. Howev= er, 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 Me= sa code, the fromPlanar member of __DRIimage should be available since __DRI_I= MAGE 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 ----- --=20 You are receiving this mail because: You are the assignee for the bug.= --15564080331.C597E.8173 Date: Sat, 27 Apr 2019 23:33:53 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Comme= nt # 17 on bug 10848= 7 from Alex Villac=C3=ADs= Lasso
I see the exact same issue on my machine when trying weston. T=
his bug is very
similar to one I had a hand in working around in mutter:
https://gitlab=
.gnome.org/GNOME/mutter/issues/127 . The mutter workaround
essentially tries calling gbm_bo_get_handle_for_plane() on plane 0 of the b=
o,
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 cau=
ses
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 rep=
ort:
----- 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 c=
lear
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 =3D 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. Howev=
er,
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 Me=
sa
code, the fromPlanar member of __DRIimage should be available since __DRI_I=
MAGE
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 -----


You are receiving this mail because:
  • You are the assignee for the bug.
= --15564080331.C597E.8173-- --===============1152122190== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============1152122190==--