XenevaOS
Loading...
Searching...
No Matches
Public Attributes | List of all members
drm_xe_sync Struct Reference

#include <xe_drm.h>

Public Attributes

__u64 extensions
 
__u32 type
 
__u32 flags
 
union { 
 
   __u32   handle 
 
   __u64   addr 
 
};  
 
__u64 timeline_value
 
__u64 reserved [2]
 

Detailed Description

struct drm_xe_sync - sync object

The @type can be:

and the @flags can be:

A minimal use of &struct drm_xe_sync looks like this:

.. code-block:: C

struct drm_xe_sync sync = {
    .flags = DRM_XE_SYNC_FLAG_SIGNAL,
    .type = DRM_XE_SYNC_TYPE_SYNCOBJ,
};
struct drm_syncobj_create syncobj_create = { 0 };
ioctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, &syncobj_create);
sync.handle = syncobj_create.handle;
    ...
    use of &sync in drm_xe_exec or drm_xe_vm_bind
    ...
struct drm_syncobj_wait wait = {
    .handles = &sync.handle,
    .timeout_nsec = INT64_MAX,
    .count_handles = 1,
    .flags = 0,
    .first_signaled = 0,
    .pad = 0,
};
ioctl(fd, DRM_IOCTL_SYNCOBJ_WAIT, &wait);

Member Data Documentation

◆ [union]

union { ... } drm_xe_sync

◆ addr

__u64 drm_xe_sync::addr

@addr: Address of user fence. When sync is passed in via exec IOCTL this is a GPU address in the VM. When sync is passed in via VM bind IOCTL this is a user pointer. In either case, it is the user's responsibility that this address is present and mapped when the user fence is signalled. Must be qword aligned.

◆ extensions

__u64 drm_xe_sync::extensions

@extensions: Pointer to the first extension struct, if any

◆ flags

__u32 drm_xe_sync::flags

@flags: Sync Flags

◆ handle

__u32 drm_xe_sync::handle

@handle: Handle for the object

◆ reserved

__u64 drm_xe_sync::reserved[2]

@reserved: Reserved

◆ timeline_value

__u64 drm_xe_sync::timeline_value

@timeline_value: Input for the timeline sync object. Needs to be different than 0 when used with DRM_XE_SYNC_TYPE_TIMELINE_SYNCOBJ.

◆ type

__u32 drm_xe_sync::type

@type: Type of this sync object


The documentation for this struct was generated from the following file: