Bug 244877 - graphics/mesa-dri: Fix vulkan by switching to unsynchronized userptr ioctls
Summary: graphics/mesa-dri: Fix vulkan by switching to unsynchronized userptr ioctls
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-x11 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-18 00:57 UTC by Austin Shafer
Modified: 2020-04-01 17:15 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (x11)


Attachments
mesa-dri: patch for anv_gem.c (894 bytes, patch)
2020-03-18 00:57 UTC, Austin Shafer
no flags Details | Diff
mesa-dri: patch for anv_gem.c (1.19 KB, patch)
2020-03-18 17:43 UTC, Austin Shafer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Austin Shafer 2020-03-18 00:57:35 UTC
Created attachment 212484 [details]
mesa-dri: patch for anv_gem.c

This is the userspace portion of a change which fixes the Vulkan graphics API on older Intel machines:

https://github.com/FreeBSDDesktop/kms-drm/pull/205

The above PR fixes the unsychronized DRM_IOCTL_I915_GEM_USERPTR which is used by intel's vulkan code. For the fix to be used the ioctl needs to have the I915_USERPTR_UNSYNCHRONIZED flag enabled:

    struct drm_i915_gem_userptr userptr = {
       .user_ptr = (__u64)((unsigned long) mem),
       .user_size = size,
-      .flags = 0,
+      .flags = I915_USERPTR_UNSYNCHRONIZED,
    };

    int ret = anv_ioctl(device->fd, DRM_IOCTL_I915_GEM_USERPTR, &userptr);

I've needed both the PR and this change for some daily vulkan development to work.

It seems that maybe all the mesa stuff is going to be overhauled soon? So maybe this isn't the ideal time to merge this. Please let me know if there is anything I can help with!
Comment 1 Jan Beich freebsd_committer 2020-03-18 04:28:33 UTC
Maybe keep trying to use userptr a la attachment 187401 [details] (ignore timeout part obsoleted by review D23846). Doing so would make it possible to submit upstream[1] in order to help other BSDs.

[1] Confirm https://github.com/myfreeweb/freebsd-ports-dank/tree/lite/graphics/mesa-dev is still affected then rebase. Maybe apply in iris driver as well for consistency.
Comment 2 Jan Beich freebsd_committer 2020-03-18 04:31:47 UTC
Other ports also try regular userptr then fall back to I915_USERPTR_UNSYNCHRONIZED:

$ ls -1d */*/files/*userptr*
lang/intel-compute-runtime/files/patch-userptr
multimedia/libva-intel-media-driver/files/patch-userptr
Comment 3 Jan Beich freebsd_committer 2020-03-18 04:40:53 UTC
When I915_USERPTR_UNSYNCHRONIZED fails it maybe nice to advise user to run as root e.g.,

  if (geteuid() != 0) {
    fprintf(stderr, "%s", "ioctl(I915_GEM_USERPTR) failed. Try running as root but expect poor stability.\n");
  }

where "poor stability" alludes to markj@ comment in https://github.com/FreeBSDDesktop/kms-drm/issues/197#issuecomment-289590556

   That definition only allows unsynchronized userptr objects, and
   such objects can probably be used to trigger nasty system behaviour
   since there's nothing preventing the process from unmapping pages
   bound to a GEM userptr object.

However, I915_USERPTR_UNSYNCHRONIZED seems to work fine in compute-runtime, media-driver and xf86-video-intel.
Comment 4 Austin Shafer 2020-03-18 17:43:26 UTC
Created attachment 212502 [details]
mesa-dri: patch for anv_gem.c

Good ideas, I stole them all and updated the patch.

This works for both mesa-dev and the 18.3.2_9 mesa-dri/mesa-libs in ports.
Comment 5 Austin Shafer 2020-04-01 17:15:56 UTC
removing needs-qa, verified portlint didn't complain about this.

Anything else I need to provide?