similar to: [PATCH 0/2] drm/nouveau: option for staging ioctls and new SET_TILING ioctl

Second version of this patchset addressing Ben's comments and fixing a few extra things. This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates the use of this staging option with the SET_TILING ioctl, which can be used to

On 20 May 2015 at 15:56, Alexandre Courbot <acourbot at nvidia.com> wrote: > Add a module option allowing to enable staging/unstable APIs. This will > allow us to experiment freely with experimental APIs for a while before > setting them in stone. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drm/nouveau/nouveau_drm.c | 18

On 21 May 2015 at 15:49, Alexandre Courbot <gnurou at gmail.com> wrote: > On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On 20 May 2015 at 15:56, Alexandre Courbot <acourbot at nvidia.com> wrote: >>> Add a module option allowing to enable staging/unstable APIs. This will >>> allow us to experiment freely with experimental

Hi there, Resending these now that they've had some more polish and testing, and I heard that Ben's vacation is over :-) These patches work as a starting point for more explicit error mechanisms and better robustness. At the moment, when a job hangs or faults, it seems that nouveau doesn't quite know how to handle the situation and often results in a hang. Some of these situations

From: Thierry Reding <treding at nvidia.com> This small series of patches implements support for waiting on and emitting fence FDs on kickoff. This enables explicit fencing and can be used for example to synchronize buffer accesses between the display engine and the GPU on Tegra. The first patch lays the groundwork by splitting up nouveau_fence_sync() to allow reuse. Patch 2 is where the

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

On 1/27/23 02:05, Matthew Brost wrote: > On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote: >> This commit provides the interfaces for the new UAPI motivated by the >> Vulkan API. It allows user mode drivers (UMDs) to: >> >> 1) Initialize a GPU virtual address (VA) space via the new >> DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel

Am 27.01.23 um 02:26 schrieb Danilo Krummrich: > On 1/27/23 02:05, Matthew Brost wrote: >> On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote: >>> This commit provides the interfaces for the new UAPI motivated by the >>> Vulkan API. It allows user mode drivers (UMDs) to: >>> >>> 1) Initialize a GPU virtual address (VA) space via the new

On 7/22/23 00:58, Faith Ekstrand wrote: > > On Wed, Jul 19, 2023 at 7:15?PM Danilo Krummrich <dakr at redhat.com > <mailto:dakr at redhat.com>> wrote: > > This commit provides the interfaces for the new UAPI motivated by the > Vulkan API. It allows user mode drivers (UMDs) to: > > 1) Initialize a GPU virtual address (VA) space via the new >

From: Thierry Reding <treding at nvidia.com> Hi, This series implements a new IOCTL to submit push buffers that can optionally return a sync FD or sync object to userspace. This is useful in cases where userspace wants to synchronize operations between the GPU and another driver (such as KMS for display). Among other things this allows extensions such as eglDupNativeFenceFDANDROID to be

Hi, this work is based on the virtio_wl driver in the ChromeOS kernel by Zach Reizner, currently at: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c There's one feature missing currently, which is letting clients write directly to the host part of a resource, so the extra copy in TRANSFER_TO_HOST isn't needed. Have pushed the

Hi all, As some of you may know there some subtle distinction between C and C++ structs, thus one should wrap/annotate them roughly like below. ... #if defined(__cplusplus) extern "C" { #endif struct foo { int bar; ... }; ... #if defined(__cplusplus) } #endif In order to work around the lack of these users can wrap the header inclusion in the same way. For example:

On 06/15/2015 04:09 PM, Alexandre Courbot wrote: > From: Ari Hirvonen <ahirvonen at nvidia.com> > > Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling > mode for imported dma-bufs. This ioctl is staging for now > and enabled with the "staging_tiling" module option. Adding Thierry to the conversation since he knows best about exported buffers and attributes.

From: Emil Velikov <emil.velikov at collabora.com> The authentication can be circumvented, by design, by using the render node. >From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org Cc: David Airlie <airlied at linux.ie> Cc: Daniel

From: Emil Velikov <emil.velikov at collabora.com> The authentication can be circumvented, by design, by using the render node. >From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org Cc: David Airlie <airlied at linux.ie> Cc: Daniel

Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied at redhat.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/Makefile | 3 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 10 + drivers/gpu/drm/virtio/virtgpu_drv.h | 60 ++++

Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied at redhat.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/Makefile | 3 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 10 + drivers/gpu/drm/virtio/virtgpu_drv.h | 60 ++++

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

From: Emil Velikov <emil.velikov at collabora.com> The authentication can be circumvented, by design, by using the render node. >From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Note: the outstanding DRM_AUTH instance is: - legacy DRI1 ioctl, which is already neutered Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at