From: Daniel Vetter <daniel@ffwll.ch> To: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jianxin Xiong <jianxin.xiong@intel.com>, Leon Romanovsky <leon@kernel.org>, linux-rdma@vger.kernel.org, dri-devel@lists.freedesktop.org, Doug Ledford <dledford@redhat.com>, Daniel Vetter <daniel.vetter@intel.com>, Christian Koenig <christian.koenig@amd.com> Subject: Re: [PATCH rdma-core 3/5] pyverbs: Add dma-buf based MR support Date: Tue, 24 Nov 2020 16:16:58 +0100 [thread overview] Message-ID: <20201124151658.GT401619@phenom.ffwll.local> (raw) In-Reply-To: <20201123180504.GA244516@ziepe.ca> On Mon, Nov 23, 2020 at 02:05:04PM -0400, Jason Gunthorpe wrote: > On Mon, Nov 23, 2020 at 09:53:02AM -0800, Jianxin Xiong wrote: > > > +cdef class DmaBuf: > > + def __init__(self, size, unit=0): > > + """ > > + Allocate DmaBuf object from a GPU device. This is done through the > > + DRI device interface (/dev/dri/card*). Usually this requires the Please use /dev/dri/renderD* instead. That's the interface meant for unpriviledged rendering access. card* is the legacy interface with backwards compat galore, don't use. Specifically if you do this on a gpu which also has display (maybe some testing on a local developer machine, no idea ...) then you mess with compositors and stuff. Also wherever you copied this from, please also educate those teams that using /dev/dri/card* for rendering stuff is a Bad Idea (tm) > > + effective user id being root or being a member of the 'video' group. > > + :param size: The size (in number of bytes) of the buffer. > > + :param unit: The unit number of the GPU to allocate the buffer from. > > + :return: The newly created DmaBuf object on success. > > + """ > > + self.dmabuf_mrs = weakref.WeakSet() > > + self.dri_fd = open('/dev/dri/card'+str(unit), O_RDWR) > > + > > + args = bytearray(32) > > + pack_into('=iiiiiiq', args, 0, 1, size, 8, 0, 0, 0, 0) > > + ioctl(self.dri_fd, DRM_IOCTL_MODE_CREATE_DUMB, args) > > + a, b, c, d, self.handle, e, self.size = unpack('=iiiiiiq', args) Yeah no, don't allocate render buffers with create_dumb. Every time this comes up I'm wondering whether we should just completely disable dma-buf operations on these. Dumb buffers are explicitly only for software rendering for display purposes when the gpu userspace stack isn't fully running yet, aka boot splash. And yes I know there's endless amounts of abuse of that stuff floating around, especially on arm-soc/android systems. > > + > > + args = bytearray(12) > > + pack_into('=iii', args, 0, self.handle, O_RDWR, 0) > > + ioctl(self.dri_fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, args) > > + a, b, self.fd = unpack('=iii', args) > > + > > + args = bytearray(16) > > + pack_into('=iiq', args, 0, self.handle, 0, 0) > > + ioctl(self.dri_fd, DRM_IOCTL_MODE_MAP_DUMB, args); > > + a, b, self.map_offset = unpack('=iiq', args); > > Wow, OK > > Is it worth using ctypes here instead? Can you at least add a comment > before each pack specifying the 'struct XXX' this is following? > > Does this work with normal Intel GPUs, like in a Laptop? AMD too? > > Christian, I would be very happy to hear from you that this entire > work is good for AMD as well I think the smallest generic interface for allocating gpu buffers which are more useful than the stuff you get from CREATE_DUMB is gbm. That's used by compositors to get bare metal opengl going on linux. Ofc Android has gralloc for the same purpose, and cros has minigbm (which isn't the same as gbm at all). So not so cool. The other generic option is using vulkan, which works directly on bare metal (without a compositor or anything running), and is cross vendor. So cool, except not used for compute, which is generally the thing you want if you have an rdma card. Both gbm-egl/opengl and vulkan have extensions to hand you a dma-buf back, properly. Compute is the worst, because opencl is widely considered a mistake (maybe opencl 3 is better, but nvidia is stuck on 1.2). The actually used stuff is cuda (nvidia-only), rocm (amd-only) and now with intel also playing we have xe (intel-only). It's pretty glorious :-/ Also I think we discussed this already, but for actual p2p the intel patches aren't in upstream yet. We have some internally, but with very broken locking (in the process of getting fixed up, but it's taking time). Cheers, Daniel > Edward should look through this, but I'm glad to see something like > this > > Thanks, > Jason > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch> To: Jason Gunthorpe <jgg@ziepe.ca> Cc: Leon Romanovsky <leon@kernel.org>, linux-rdma@vger.kernel.org, dri-devel@lists.freedesktop.org, Doug Ledford <dledford@redhat.com>, Daniel Vetter <daniel.vetter@intel.com>, Christian Koenig <christian.koenig@amd.com>, Jianxin Xiong <jianxin.xiong@intel.com> Subject: Re: [PATCH rdma-core 3/5] pyverbs: Add dma-buf based MR support Date: Tue, 24 Nov 2020 16:16:58 +0100 [thread overview] Message-ID: <20201124151658.GT401619@phenom.ffwll.local> (raw) In-Reply-To: <20201123180504.GA244516@ziepe.ca> On Mon, Nov 23, 2020 at 02:05:04PM -0400, Jason Gunthorpe wrote: > On Mon, Nov 23, 2020 at 09:53:02AM -0800, Jianxin Xiong wrote: > > > +cdef class DmaBuf: > > + def __init__(self, size, unit=0): > > + """ > > + Allocate DmaBuf object from a GPU device. This is done through the > > + DRI device interface (/dev/dri/card*). Usually this requires the Please use /dev/dri/renderD* instead. That's the interface meant for unpriviledged rendering access. card* is the legacy interface with backwards compat galore, don't use. Specifically if you do this on a gpu which also has display (maybe some testing on a local developer machine, no idea ...) then you mess with compositors and stuff. Also wherever you copied this from, please also educate those teams that using /dev/dri/card* for rendering stuff is a Bad Idea (tm) > > + effective user id being root or being a member of the 'video' group. > > + :param size: The size (in number of bytes) of the buffer. > > + :param unit: The unit number of the GPU to allocate the buffer from. > > + :return: The newly created DmaBuf object on success. > > + """ > > + self.dmabuf_mrs = weakref.WeakSet() > > + self.dri_fd = open('/dev/dri/card'+str(unit), O_RDWR) > > + > > + args = bytearray(32) > > + pack_into('=iiiiiiq', args, 0, 1, size, 8, 0, 0, 0, 0) > > + ioctl(self.dri_fd, DRM_IOCTL_MODE_CREATE_DUMB, args) > > + a, b, c, d, self.handle, e, self.size = unpack('=iiiiiiq', args) Yeah no, don't allocate render buffers with create_dumb. Every time this comes up I'm wondering whether we should just completely disable dma-buf operations on these. Dumb buffers are explicitly only for software rendering for display purposes when the gpu userspace stack isn't fully running yet, aka boot splash. And yes I know there's endless amounts of abuse of that stuff floating around, especially on arm-soc/android systems. > > + > > + args = bytearray(12) > > + pack_into('=iii', args, 0, self.handle, O_RDWR, 0) > > + ioctl(self.dri_fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, args) > > + a, b, self.fd = unpack('=iii', args) > > + > > + args = bytearray(16) > > + pack_into('=iiq', args, 0, self.handle, 0, 0) > > + ioctl(self.dri_fd, DRM_IOCTL_MODE_MAP_DUMB, args); > > + a, b, self.map_offset = unpack('=iiq', args); > > Wow, OK > > Is it worth using ctypes here instead? Can you at least add a comment > before each pack specifying the 'struct XXX' this is following? > > Does this work with normal Intel GPUs, like in a Laptop? AMD too? > > Christian, I would be very happy to hear from you that this entire > work is good for AMD as well I think the smallest generic interface for allocating gpu buffers which are more useful than the stuff you get from CREATE_DUMB is gbm. That's used by compositors to get bare metal opengl going on linux. Ofc Android has gralloc for the same purpose, and cros has minigbm (which isn't the same as gbm at all). So not so cool. The other generic option is using vulkan, which works directly on bare metal (without a compositor or anything running), and is cross vendor. So cool, except not used for compute, which is generally the thing you want if you have an rdma card. Both gbm-egl/opengl and vulkan have extensions to hand you a dma-buf back, properly. Compute is the worst, because opencl is widely considered a mistake (maybe opencl 3 is better, but nvidia is stuck on 1.2). The actually used stuff is cuda (nvidia-only), rocm (amd-only) and now with intel also playing we have xe (intel-only). It's pretty glorious :-/ Also I think we discussed this already, but for actual p2p the intel patches aren't in upstream yet. We have some internally, but with very broken locking (in the process of getting fixed up, but it's taking time). Cheers, Daniel > Edward should look through this, but I'm glad to see something like > this > > Thanks, > Jason > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-11-24 15:17 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-23 17:52 [PATCH rdma-core 0/5] Add user space dma-buf support Jianxin Xiong 2020-11-23 17:52 ` Jianxin Xiong 2020-11-23 17:53 ` [PATCH rdma-core 1/5] verbs: Support dma-buf based memory region Jianxin Xiong 2020-11-23 17:53 ` Jianxin Xiong 2020-11-23 18:01 ` Jason Gunthorpe 2020-11-23 18:01 ` Jason Gunthorpe 2020-11-24 10:31 ` Yishai Hadas 2020-11-24 10:31 ` Yishai Hadas 2020-11-24 18:00 ` Xiong, Jianxin 2020-11-24 18:00 ` Xiong, Jianxin 2020-11-23 17:53 ` [PATCH rdma-core 2/5] mlx5: " Jianxin Xiong 2020-11-23 17:53 ` Jianxin Xiong 2020-11-23 18:01 ` Jason Gunthorpe 2020-11-23 18:01 ` Jason Gunthorpe 2020-11-23 19:40 ` Xiong, Jianxin 2020-11-23 19:40 ` Xiong, Jianxin 2020-11-23 17:53 ` [PATCH rdma-core 3/5] pyverbs: Add dma-buf based MR support Jianxin Xiong 2020-11-23 17:53 ` Jianxin Xiong 2020-11-23 18:05 ` Jason Gunthorpe 2020-11-23 18:05 ` Jason Gunthorpe 2020-11-23 19:48 ` Xiong, Jianxin 2020-11-23 19:48 ` Xiong, Jianxin 2020-11-24 15:16 ` Daniel Vetter [this message] 2020-11-24 15:16 ` Daniel Vetter 2020-11-24 15:36 ` Jason Gunthorpe 2020-11-24 15:36 ` Jason Gunthorpe 2020-11-24 16:21 ` Xiong, Jianxin 2020-11-24 16:21 ` Xiong, Jianxin 2020-11-24 18:45 ` Xiong, Jianxin 2020-11-24 18:45 ` Xiong, Jianxin 2020-11-25 10:50 ` Daniel Vetter 2020-11-25 10:50 ` Daniel Vetter 2020-11-25 12:14 ` Jason Gunthorpe 2020-11-25 12:14 ` Jason Gunthorpe 2020-11-25 19:27 ` Xiong, Jianxin 2020-11-25 19:27 ` Xiong, Jianxin 2020-11-26 0:00 ` Jason Gunthorpe 2020-11-26 0:00 ` Jason Gunthorpe 2020-11-26 0:43 ` Xiong, Jianxin 2020-11-26 0:43 ` Xiong, Jianxin 2020-11-23 17:53 ` [PATCH rdma-core 4/5] tests: Add tests for dma-buf based memory regions Jianxin Xiong 2020-11-23 17:53 ` Jianxin Xiong 2020-11-23 17:53 ` [PATCH rdma-core 5/5] tests: Bug fix for get_access_flags() Jianxin Xiong 2020-11-23 17:53 ` Jianxin Xiong 2020-11-24 20:26 ` John Hubbard 2020-11-24 20:26 ` John Hubbard 2020-11-24 20:43 ` Xiong, Jianxin 2020-11-24 20:43 ` Xiong, Jianxin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201124151658.GT401619@phenom.ffwll.local \ --to=daniel@ffwll.ch \ --cc=christian.koenig@amd.com \ --cc=daniel.vetter@intel.com \ --cc=dledford@redhat.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=jgg@ziepe.ca \ --cc=jianxin.xiong@intel.com \ --cc=leon@kernel.org \ --cc=linux-rdma@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.