On Thu, Jun 01, 2017 at 11:06:39AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Sync objects are new toplevel drm object, that contain a
> pointer to a fence. This fence can be updated via command
> submission ioctls via drivers.
>
> There is also a generic wait obj API modelled on the vulk
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).
These objects can be
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).
These objects can be
On 25 May 2017 at 18:30, Chris Wilson wrote:
> On Wed, May 24, 2017 at 05:06:11PM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> Sync objects are new toplevel drm object, that contain a
>> pointer to a fence. This fence can be updated via command
>> submission ioctls via drivers.
>>
>> Ther
On Wed, May 24, 2017 at 05:06:11PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Sync objects are new toplevel drm object, that contain a
> pointer to a fence. This fence can be updated via command
> submission ioctls via drivers.
>
> There is also a generic wait obj API modelled on the vulk
I can't really review for all of the kernel details (though the seem ok to
me) so this mostly applies to the API:
Reviewed-by: Jason Ekstrand
On Wed, May 24, 2017 at 12:06 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Sync objects are new toplevel drm object, that contain a
> pointer to a fe
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).
These objects can be
On Fri, May 12, 2017 at 10:34:53AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Sync objects are new toplevel drm object, that contain a
> pointer to a fence. This fence can be updated via command
> submission ioctls via drivers.
>
> There is also a generic wait obj API modelled on the vulk
On Fri, May 12, 2017 at 10:34:53AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Sync objects are new toplevel drm object, that contain a
> pointer to a fence. This fence can be updated via command
> submission ioctls via drivers.
>
> There is also a generic wait obj API modelled on the vulk
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).
These objects can be
On Mon, May 8, 2017 at 7:26 PM, Dave Airlie wrote:
> On 4 May 2017 at 18:16, Chris Wilson wrote:
> > On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote:
> >> +#include
> >
> > I wonder if Daniel has already split everything used here into its own
> > headers?
>
> not sure, if drm_file
On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Sync objects are new toplevel drm object, that contain a
> pointer to a fence. This fence can be updated via command
> submission ioctls via drivers.
>
> There is also a generic wait obj API modelled on the vulk
On Tue, May 09, 2017 at 12:26:34PM +1000, Dave Airlie wrote:
> On 4 May 2017 at 18:16, Chris Wilson wrote:
> > On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote:
> >> +#include
> >
> > I wonder if Daniel has already split everything used here into its own
> > headers?
>
> not sure, if
On 4 May 2017 at 18:16, Chris Wilson wrote:
> On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote:
>> +#include
>
> I wonder if Daniel has already split everything used here into its own
> headers?
not sure, if drm_file is out there yet. I'll find out when I rebase
this onto something ne
On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote:
> +#include
I wonder if Daniel has already split everything used here into its own
headers?
> +#include
> +#include
> +#include
> +
> +#include "drm_internal.h"
> +#include
> +
> +static struct drm_syncobj *drm_syncobj_get(struct d
On 2017年04月26日 11:28, Dave Airlie wrote:
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelle
On 2017年04月26日 11:28, Dave Airlie wrote:
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelle
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).
These objects can be
18 matches
Mail list logo
