[PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.
Mike Lothian
mike at fireburn.co.uk
Wed Apr 25 00:23:56 UTC 2018
On Tue, 24 Apr 2018 at 09:17 Mario Kleiner <mario.kleiner.de at gmail.com>
wrote:
> Both xf86-video-intel and xf86-video-nouveau cause OpenGL
> clients to fail when used with DRI3 on server 1.20 with Mesa 18.1.
>
> Reason is that the servers DRI3 version is now unconditionally
> reported as DRI3 1.2 to 1.2 capable clients. This causes clients
> using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
> DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx
> do not support the needed hooks like info->pixmap_from_fds or
> info->get_formats, info->get_modifiers. Unfortunately we can't
> simply report the servers DRI3 version as 1.0 in this case, as
> the reported version can not be specific to a X-Screen, and
> different screens may have drivers with different capabilities.
>
> Luckily the server has fallbacks to ->pixmap_from_fd, ->fd_from_pixmap,
> and simply reporting an empty set of supported modifiers for the
> DRI3GetSupportedModifiers request if the ddx doesn't support
> DRI 3.2.
>
> Clients like Mesa 18.1's dri3 loader respond to the empty set
> of reported modifiers by falling back to a dri driver selected
> buffer format (image->createImageWithModifiers responds to a
> NULL modifier_list by acting like ->createImage()). This works,
> but Mesa 18.1 will still try to use the DRI3PixmapFromBuffers
> request to create the corresponding pixmap, just passing in
> a modifier that corresponds to whatever tiling the dri driver
> selected by default. To prevent this request - and thereby
> the client - from failing with a BadImplementation error,
> remove the check for modifier == DRM_MOD_FORMAT_INVALID in
> the pixmap_from_fd fallback path of dri3_pixmap_from_fds()
> and trust that if we hit the fallback path then the client
> will have passed a buffer with some driver specific default
> tiling that can be handled by pixmap_from_fd.
>
> Another approach would be for Mesa's dri3 loader to keep
> track how a buffer was created (with explicit modifiers or
> not), and then call DRI3PixmapFromBuffers or DRI3PixmapFromBuffer,
> but then any future DRI3 client implementation would need to be
> fixed, so the server side is probably the better place for this.
>
> Tested on Intel Ivybridge and NVidia Pascal.
>
> Fixes: 6e7c40f62db6 ("dri3: Add multi-planar/modifier buffer requests")
> Signed-off-by: Mario Kleiner <mario.kleiner.de at gmail.com>
> Cc: Daniel Stone <daniels at collabora.com>
> Cc: Louis-Francis Ratté-Boulianne <lfrb at collabora.com>
> ---
> dri3/dri3_screen.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
> index 23e33f4..243dab7 100644
> --- a/dri3/dri3_screen.c
> +++ b/dri3/dri3_screen.c
> @@ -66,8 +66,7 @@ dri3_pixmap_from_fds(PixmapPtr *ppixmap, ScreenPtr
> screen,
> if (info->version >= 2 && info->pixmap_from_fds != NULL) {
> pixmap = (*info->pixmap_from_fds) (screen, num_fds, fds, width,
> height,
> strides, offsets, depth, bpp,
> modifier);
> - } else if (info->pixmap_from_fd != NULL && num_fds == 1 &&
> - modifier == DRM_FORMAT_MOD_INVALID) {
> + } else if (info->pixmap_from_fd != NULL && num_fds == 1) {
> pixmap = (*info->pixmap_from_fd) (screen, fds[0], width, height,
> strides[0], depth, bpp);
> } else {
> --
> 2.7.4
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
Hi Mario
Thanks for fixing this, that's xserver 1.20 working with the Intel and
AMDGPU DDXs on my laptop with Kwin
The plasmashell & steam freezes aren't present with the Intel or AMDGPU
DDXs, only modesetting
I'm quite happy to mark https://bugs.freedesktop.org/show_bug.cgi?id=105851 as
resolved and look into the modesetting freezes seperately
Feel free to add my:
Tested-by: Mike Lothian <mike at fireburn.co.uk>
Cheers again
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180425/2566bde5/attachment.html>
More information about the xorg-devel
mailing list