[Mesa-dev] [PATCH] vulkan/wsi: Improve the DRI3 error message

Jason Ekstrand jason at jlekstrand.net
Sat Feb 18 16:59:48 UTC 2017


On Feb 18, 2017 1:59 AM, "Kai Wasserbäch" <kai at dev.carbon-project.org>
wrote:

Hey Jacob,
Jacob Lifshay wrote on 18.02.2017 10:40:
> This commit improves the message by telling them that they could probably
> enable DRI3 and giving a url to a Ask Ubuntu question showing how to do
> that.

wouldn't it be better to add a page to the mesa user topics section (ie.
add a
file to docs and then add the link in docs/contents.html)? That way nobody
is
dependant on whether AskUbuntu works, nobody gets thrown off, if they don't
use
Ubuntu and might think the link won't work for them and lastly it would
allow
for easy referencing of the relevant driver man pages with more details on
the
DRI option, including information if/when this might be the default for a
driver.


I agree.  Honestly, I don't think a link is really needed.  Of the user has
the Intel or amdgpu DDX and they don't have DRI3, then they almost
certainly disabled it themselves.  If they figured out how to do that, one
would think they could figure out how to undo it.  At the very least, they
could Google this warning message and that will probably get them to the
right ask Ubuntu page or whatever.

> More importantly, it includes a little heuristic to check to see
> if we're running on AMD or NVIDIA's proprietary X11 drivers and, if we
> are, doesn't emit the warning.  This way, users with both a discrete
> card and Intel graphics don't get the warning when they're just running
> on the discrete card.

Wouldn't it be better to check for the driver name? Right now, you would
have to
check for "amdgpu" and "intel" (maybe modesetting as well?). That way you
don't
need to rely on the open drivers never implementing one of the proprietary
extensions (even though it seems unlikely they'd do that). Or am I missing
something here.



Possibly?  Of there's an easy way to get the driver name, that would work
just as well.  That said, I don't think we should get too tied up in knots
over it.  This is a heuristic for determining whether or not to print a
warning message.

Before too much longer (maybe another year or two?), we can probably drop
the warning message all together because hopefully the DRI3 fear well have
subsided and few people will even have thous problem.

Cheers,
Kai


> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99715
> Co-authored-by: Jason Ekstrand <jason.ekstrand at intel.com>
> ---
>  src/vulkan/wsi/wsi_common_x11.c | 55 ++++++++++++++++++++++++++++++
+++--------
>  1 file changed, 45 insertions(+), 10 deletions(-)
>
> diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_
x11.c
> index 64ba921..ac7a972 100644
> --- a/src/vulkan/wsi/wsi_common_x11.c
> +++ b/src/vulkan/wsi/wsi_common_x11.c
> @@ -48,7 +48,9 @@
>
>  struct wsi_x11_connection {
>     bool has_dri3;
> +   bool has_dri2;
>     bool has_present;
> +   bool is_proprietary_x11;
>  };
>
>  struct wsi_x11 {
> @@ -63,8 +65,8 @@ static struct wsi_x11_connection *
>  wsi_x11_connection_create(const VkAllocationCallbacks *alloc,
>                            xcb_connection_t *conn)
>  {
> -   xcb_query_extension_cookie_t dri3_cookie, pres_cookie;
> -   xcb_query_extension_reply_t *dri3_reply, *pres_reply;
> +   xcb_query_extension_cookie_t dri3_cookie, dri2_cookie, pres_cookie,
amd_cookie, nv_cookie;
> +   xcb_query_extension_reply_t *dri3_reply, *dri2_reply, *pres_reply,
*amd_reply, *nv_reply;
>
>     struct wsi_x11_connection *wsi_conn =
>        vk_alloc(alloc, sizeof(*wsi_conn), 8,
> @@ -73,22 +75,46 @@ wsi_x11_connection_create(const VkAllocationCallbacks
*alloc,
>        return NULL;
>
>     dri3_cookie = xcb_query_extension(conn, 4, "DRI3");
> +   dri2_cookie = xcb_query_extension(conn, 4, "DRI2");
>     pres_cookie = xcb_query_extension(conn, 7, "PRESENT");
>
> +   /* We try to be nice to users and emit a warning if they try to use a
> +    * Vulkan application on a system without DRI3 enabled.  However,
this ends
> +    * up spewing the warning when a user has, for example, both Intel
> +    * integrated graphics and a discrete card with proprietary driers
and are
> +    * running on the discrete card with the proprietary DDX.  In this
case, we
> +    * really don't want to print the warning because it just confuses
users.
> +    * As a heuristic to detect this case, we check for a couple of
proprietary
> +    * X11 extensions.
> +    */
> +   amd_cookie = xcb_query_extension(conn, 11, "ATIFGLRXDRI");
> +   nv_cookie = xcb_query_extension(conn, 10, "NV-CONTROL");
> +
>     dri3_reply = xcb_query_extension_reply(conn, dri3_cookie, NULL);
> +   dri2_reply = xcb_query_extension_reply(conn, dri2_cookie, NULL);
>     pres_reply = xcb_query_extension_reply(conn, pres_cookie, NULL);
> -   if (dri3_reply == NULL || pres_reply == NULL) {
> +   amd_reply = xcb_query_extension_reply(conn, amd_cookie, NULL);
> +   nv_reply = xcb_query_extension_reply(conn, nv_cookie, NULL);
> +   if (!dri3_reply || !dri2_reply || !pres_reply || !amd_reply ||
!nv_reply) {
>        free(dri3_reply);
> +      free(dri2_reply);
>        free(pres_reply);
> +      free(amd_reply);
> +      free(nv_reply);
>        vk_free(alloc, wsi_conn);
>        return NULL;
>     }
>
>     wsi_conn->has_dri3 = dri3_reply->present != 0;
> +   wsi_conn->has_dri2 = dri2_reply->present != 0;
>     wsi_conn->has_present = pres_reply->present != 0;
> +   wsi_conn->is_proprietary_x11 = amd_reply->present ||
nv_reply->present;
>
>     free(dri3_reply);
> +   free(dri2_reply);
>     free(pres_reply);
> +   free(amd_reply);
> +   free(nv_reply);
>
>     return wsi_conn;
>  }
> @@ -100,6 +126,20 @@ wsi_x11_connection_destroy(const
VkAllocationCallbacks *alloc,
>     vk_free(alloc, conn);
>  }
>
> +static bool
> +wsi_x11_check_for_dri3(struct wsi_x11_connection *wsi_conn)
> +{
> +  if (wsi_conn->has_dri3)
> +    return true;
> +  if (!wsi_conn->is_proprietary_x11) {
> +    fprintf(stderr, "vulkan: No DRI3 support detected - required for
presentation\n");
> +    if (wsi_conn->has_dri2)


I really don't see what checking for DRI2 is gaining us here.  Even the
proprietary X drivers advertise it so out will basically always be true.
It seems to just make the code more complicated.  Also, if they happen to
be running on a software-only X driver, they probably still want the
warning message.

> +      fprintf(stderr, "Note: DRI2 support detected, you can probably
enable DRI3 in your Xorg config;\n"
> +                      "      see http://askubuntu.com/
questions/817226/how-to-enable-dri3-on-ubuntu-16-04\n");
> +  }
> +  return false;
> +}
> +
>  static struct wsi_x11_connection *
>  wsi_x11_get_connection(struct wsi_device *wsi_dev,
>                      const VkAllocationCallbacks *alloc,
> @@ -264,11 +304,8 @@ VkBool32 wsi_get_physical_device_xcb_
presentation_support(
>     if (!wsi_conn)
>        return false;
>
> -   if (!wsi_conn->has_dri3) {
> -      fprintf(stderr, "vulkan: No DRI3 support detected - required for
presentation\n");
> -      fprintf(stderr, "Note: Buggy applications may crash, if they do
please report to vendor\n");
> +   if (!wsi_x11_check_for_dri3(wsi_conn))
>        return false;
> -   }
>
>     unsigned visual_depth;
>     if (!connection_get_visualtype(connection, visual_id, &visual_depth))
> @@ -313,9 +350,7 @@ x11_surface_get_support(VkIcdSurfaceBase *icd_surface,
>     if (!wsi_conn)
>        return VK_ERROR_OUT_OF_HOST_MEMORY;
>
> -   if (!wsi_conn->has_dri3) {
> -      fprintf(stderr, "vulkan: No DRI3 support detected - required for
presentation\n");
> -      fprintf(stderr, "Note: Buggy applications may crash, if they do
please report to vendor\n");
> +   if (!wsi_x11_check_for_dri3(wsi_conn)) {
>        *pSupported = false;
>        return VK_SUCCESS;
>     }
>

--

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: kai at dev.carbon-project.org


_______________________________________________
mesa-dev mailing list
mesa-dev at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170218/9bfa39e6/attachment-0001.html>


More information about the mesa-dev mailing list