search for: drm_ioctl_prime_handle_to_fd

...ffer, renders into it, then passes a file handle for that shmem block together with some meta data (size, format, ...) to the wayland server. (b) gpu rendering: client opens a render node, allocates a buffer, asks the cpu to renders into it, exports the buffer as dma-buf (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server (again including meta data of course). Is that correct? Now, with virtualization added to the mix it becomes a bit more complicated. Client and server are unmodified. The client talks to the guest proxy (wayland protocol). The guest proxy talks to the...

...ffer, renders into it, then passes a file handle for that shmem block together with some meta data (size, format, ...) to the wayland server. (b) gpu rendering: client opens a render node, allocates a buffer, asks the cpu to renders into it, exports the buffer as dma-buf (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server (again including meta data of course). Is that correct? Now, with virtualization added to the mix it becomes a bit more complicated. Client and server are unmodified. The client talks to the guest proxy (wayland protocol). The guest proxy talks to the...

...for that shmem block together > > with some meta data (size, format, ...) to the wayland server. > > > > (b) gpu rendering: client opens a render node, allocates a buffer, > > asks the cpu to renders into it, exports the buffer as dma-buf > > (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server > > (again including meta data of course). > > > > Is that correct? > > Both are correct descriptions of typical behaviors. But it isn't spec'ed > anywhere who has to do the buffer allocation. Well, according to Pekka&...

...for that shmem block together > > with some meta data (size, format, ...) to the wayland server. > > > > (b) gpu rendering: client opens a render node, allocates a buffer, > > asks the cpu to renders into it, exports the buffer as dma-buf > > (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server > > (again including meta data of course). > > > > Is that correct? > > Both are correct descriptions of typical behaviors. But it isn't spec'ed > anywhere who has to do the buffer allocation. Well, according to Pekka&...

...lient_cap { }; #define DRM_CLOEXEC O_CLOEXEC +#define DRM_SYNC_FD O_DSYNC struct drm_prime_handle { __u32 handle; /** Flags.. only applicable for handle->fd */ __u32 flags; - /** Returned dmabuf file descriptor */ + /** + * DRM_IOCTL_PRIME_FD_TO_HANDLE: + * in: dma-buf fd + * DRM_IOCTL_PRIME_HANDLE_TO_FD: + * in: sync fence fd if DRM_SYNC_FD flag is passed + * out: dma-buf fd + */ __s32 fd; }; -- 1.8.1.5

...ock together >>> with some meta data (size, format, ...) to the wayland server. >>> >>> (b) gpu rendering: client opens a render node, allocates a buffer, >>> asks the cpu to renders into it, exports the buffer as dma-buf >>> (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server >>> (again including meta data of course). >>> >>> Is that correct? >> >> Both are correct descriptions of typical behaviors. But it isn't spec'ed >> anywhere who has to do the buffer allocation. >...

...then passes a file handle for that shmem block together > with some meta data (size, format, ...) to the wayland server. > > (b) gpu rendering: client opens a render node, allocates a buffer, > asks the cpu to renders into it, exports the buffer as dma-buf > (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server > (again including meta data of course). > > Is that correct? Both are correct descriptions of typical behaviors. But it isn't spec'ed anywhere who has to do the buffer allocation. In practical terms, the buffer allocation happens in e...

...ne DRM_SYNC_FD O_DSYNC > struct drm_prime_handle { > __u32 handle; > > /** Flags.. only applicable for handle->fd */ > __u32 flags; > > - /** Returned dmabuf file descriptor */ > + /** > + * DRM_IOCTL_PRIME_FD_TO_HANDLE: > + * in: dma-buf fd > + * DRM_IOCTL_PRIME_HANDLE_TO_FD: > + * in: sync fence fd if DRM_SYNC_FD flag is passed > + * out: dma-buf fd > + */ > __s32 fd; > }; > > -- > 1.8.1.5 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

...handle for that shmem block together >> ?????? with some meta data (size, format, ...) to the wayland server. >> >> ?? (b) gpu rendering: client opens a render node, allocates a buffer, >> ?????? asks the cpu to renders into it, exports the buffer as dma-buf >> ?????? (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server >> ?????? (again including meta data of course). >> >> Is that correct? > > Both are correct descriptions of typical behaviors. But it isn't spec'ed > anywhere who has to do the buffer allocation. > > In practical terms...

...handle for that shmem block together >> ?????? with some meta data (size, format, ...) to the wayland server. >> >> ?? (b) gpu rendering: client opens a render node, allocates a buffer, >> ?????? asks the cpu to renders into it, exports the buffer as dma-buf >> ?????? (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server >> ?????? (again including meta data of course). >> >> Is that correct? > > Both are correct descriptions of typical behaviors. But it isn't spec'ed > anywhere who has to do the buffer allocation. > > In practical terms...

On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote: > On 02/05/2018 01:20 PM, Gerd Hoffmann wrote: > > Hi, > > > > > > Why not use virtio-vsock to run the wayland protocol? I don't like > > > > the idea to duplicate something with very simliar functionality in > > > > virtio-gpu. > > > > > > The reason for

On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote: > On 02/05/2018 01:20 PM, Gerd Hoffmann wrote: > > Hi, > > > > > > Why not use virtio-vsock to run the wayland protocol? I don't like > > > > the idea to duplicate something with very simliar functionality in > > > > virtio-gpu. > > > > > > The reason for

...source 4. QEMU maps that buffer to the guest's address space (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver 5. DRM_VIRTGPU_RESOURCE_CREATE returns the resource id just created 6. Client mmaps it with DRM_IOCTL_VIRTGPU_MAP+mmap and can render to it 7. Gets a FD with DRM_IOCTL_PRIME_HANDLE_TO_FD that can be sent around Send of shareable buffer by guest --------------------------------------------- 1. Client sends the host a message that refers to this buffer, passing the FD using SCM_RIGHTS 2. Guest proxy passes the message (serialized data + FDs) on to the virtio driver responsable...

Hi, This is a proof of concept of GPU forwarding for Linux guest on Linux host. I'd like to get comments and suggestions from community before I put more time on it. To summarize what it is: 1. It's a solution to bring GPU acceleration for Linux vm guest on Linux host. It could works with different GPU although the current proof of concept only works with Intel GPU. 2. The basic idea

Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes