On Tue, 5 Aug 2014 19:43:22 +0200
Daniel Vetter wrote:
> On Tue, Aug 5, 2014 at 7:09 PM, Jesse Barnes wrote:
> >> >> >> Then we need similar flags for vblank events and pageflips to do the
> >> >> >> same (obviously those are drm core patches) and it's all there. That
> >> >> >> should probably
On Tue, Aug 5, 2014 at 7:09 PM, Jesse Barnes wrote:
>> >> >> Then we need similar flags for vblank events and pageflips to do the
>> >> >> same (obviously those are drm core patches) and it's all there. That
>> >> >> should probably integrated as a special type of drm_event, so that
>> >> >> drive
On Tue, 5 Aug 2014 18:08:16 +0200
Daniel Vetter wrote:
> On Tue, Aug 5, 2014 at 6:05 PM, Jesse Barnes wrote:
> > On Tue, 5 Aug 2014 17:08:22 +0200
> > Daniel Vetter wrote:
> >
> >> On Tue, Aug 5, 2014 at 4:59 PM, Jesse Barnes
> >> wrote:
> >> >> This doesn't really look like the interface I'd
On Tue, 5 Aug 2014 18:08:16 +0200
Daniel Vetter wrote:
> On Tue, Aug 5, 2014 at 6:05 PM, Jesse Barnes wrote:
> > But yes, I want the Android guys to try this out too. I've already
> > pinged them internally to check things out. Probably the biggest
> > remaining opens there would be having a t
On Tue, Aug 5, 2014 at 6:05 PM, Jesse Barnes wrote:
> On Tue, 5 Aug 2014 17:08:22 +0200
> Daniel Vetter wrote:
>
>> On Tue, Aug 5, 2014 at 4:59 PM, Jesse Barnes
>> wrote:
>> >> This doesn't really look like the interface I'd expected. Imo we just
>> >> need to add a flag to execbuf so that user
On Tue, 5 Aug 2014 17:08:22 +0200
Daniel Vetter wrote:
> On Tue, Aug 5, 2014 at 4:59 PM, Jesse Barnes wrote:
> >> This doesn't really look like the interface I'd expected. Imo we just
> >> need to add a flag to execbuf so that userspace can tell the kernel to
> >> create a fence for that execbuf
On Tue, Aug 5, 2014 at 5:03 PM, Jesse Barnes wrote:
> Oops, yeah. I still need to add a way to request a fence on a specific
> ring, and that ties into our context API, so that's still open. But I
> definitely don't want a sync timeline here with this approach.
Wrt timelines I think we want one
On Tue, Aug 5, 2014 at 4:59 PM, Jesse Barnes wrote:
>> This doesn't really look like the interface I'd expected. Imo we just
>> need to add a flag to execbuf so that userspace can tell the kernel to
>> create a fence for that execbuf, and switch one of the leftover rsvd
>> fields to __s32 as an ou
On Tue, 05 Aug 2014 10:09:56 +0200
Maarten Lankhorst wrote:
> op 05-08-14 01:18, Jesse Barnes schreef:
> > Expose an ioctl to create Android fences based on the Android sync point
> > infrastructure (which in turn is based on DMA-buf fences). Just a
> > sketch at this point, no testing has been
op 05-08-14 16:59, Jesse Barnes schreef:
> On Tue, 5 Aug 2014 09:44:00 +0200
> Daniel Vetter wrote:
>
>> On Tue, Aug 5, 2014 at 1:18 AM, Jesse Barnes
>> wrote:
>>> +#define DRM_IOCTL_I915_GEM_FENCE DRM_IOWR
>>> (DRM_COMMAND_BASE + DRM_I915_GEM_FENCE, struct drm_i915_gem_fe
On Tue, 5 Aug 2014 09:44:00 +0200
Daniel Vetter wrote:
> On Tue, Aug 5, 2014 at 1:18 AM, Jesse Barnes wrote:
> > +#define DRM_IOCTL_I915_GEM_FENCE DRM_IOWR
> > (DRM_COMMAND_BASE + DRM_I915_GEM_FENCE, struct drm_i915_gem_fence)
> >
> > /* Allow drivers to submit batchbuffe
op 05-08-14 01:18, Jesse Barnes schreef:
> Expose an ioctl to create Android fences based on the Android sync point
> infrastructure (which in turn is based on DMA-buf fences). Just a
> sketch at this point, no testing has been done.
>
> There are a couple of goals here:
> 1) allow applications
On Tue, Aug 5, 2014 at 1:18 AM, Jesse Barnes wrote:
> +#define DRM_IOCTL_I915_GEM_FENCE DRM_IOWR
> (DRM_COMMAND_BASE + DRM_I915_GEM_FENCE, struct drm_i915_gem_fence)
>
> /* Allow drivers to submit batchbuffers directly to hardware, relying
> * on the security mechanisms p
Expose an ioctl to create Android fences based on the Android sync point
infrastructure (which in turn is based on DMA-buf fences). Just a
sketch at this point, no testing has been done.
There are a couple of goals here:
1) allow applications and libraries to create fences without an
assoc
14 matches
Mail list logo