search for: drm_syncobj

...akes > > care of all that, but engines behind host1x can use the IOCTL extensions > > provided here to emit fence FDs that in turn can be used to synchronize > > their jobs with either the scanout engine or the GPU. > > Whilst hooking up fences, I advise you to also hook up drm_syncobj. > Internally they each resolve to another fence, so the mechanics are > identical, you just need another array in the uABI for in/out syncobj. > The advantage of drm_syncobj is that userspace can track internal fences > using inexhaustible handles, reserving the precious fd for IPC or...

...ines behind host1x can use the IOCTL extensions > > > > provided here to emit fence FDs that in turn can be used to synchronize > > > > their jobs with either the scanout engine or the GPU. > > > > > > Whilst hooking up fences, I advise you to also hook up drm_syncobj. > > > Internally they each resolve to another fence, so the mechanics are > > > identical, you just need another array in the uABI for in/out syncobj. > > > The advantage of drm_syncobj is that userspace can track internal fences > > > using inexhaustible handle...

...of all that, but engines behind host1x can use the IOCTL extensions > > > provided here to emit fence FDs that in turn can be used to synchronize > > > their jobs with either the scanout engine or the GPU. > > > > Whilst hooking up fences, I advise you to also hook up drm_syncobj. > > Internally they each resolve to another fence, so the mechanics are > > identical, you just need another array in the uABI for in/out syncobj. > > The advantage of drm_syncobj is that userspace can track internal fences > > using inexhaustible handles, reserving the pre...

...userspace will start using sync objects, IMO. > I wasn't talking about generic UAPI, but having drm helpers instead. The former (as you pointed out) would need time to crystallize. While the latter can be done even today. > ... > >> +static void virtio_gpu_reset_syncobjs(struct drm_syncobj **syncobjs, > >> + uint32_t nr_syncobjs) > >> +{ > >> + uint32_t i; > >> + > >> + for (i = 0; i < nr_syncobjs; i++) { > >> + if (syncobjs[i]) > >> + drm_syncobj_rep...

...au because the KMS core takes > care of all that, but engines behind host1x can use the IOCTL extensions > provided here to emit fence FDs that in turn can be used to synchronize > their jobs with either the scanout engine or the GPU. Whilst hooking up fences, I advise you to also hook up drm_syncobj. Internally they each resolve to another fence, so the mechanics are identical, you just need another array in the uABI for in/out syncobj. The advantage of drm_syncobj is that userspace can track internal fences using inexhaustible handles, reserving the precious fd for IPC or KMS. -Chris

From: Thierry Reding <treding at nvidia.com> This set of patches adds support for fences to Tegra DRM and complements the fence FD support for Nouveau. Technically this isn't necessary for a fence-based synchronization loop with Nouveau because the KMS core takes care of all that, but engines behind host1x can use the IOCTL extensions provided here to emit fence FDs that in turn can be

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

...c + :export: diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c0e5a7e59536..02ee5faf1a925 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -18,7 +18,7 @@ drm-y := drm_auth.o drm_cache.o \ drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \ - drm_managed.o + drm_managed.o drm_vblank_work.o drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o drm_dma.o drm_scatter.o drm_lock.o drm-$(CONFIG_DRM_LIB_RANDOM) += lib/d...

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up