Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions sdk/CMakeLists.txt
Original file line number Diff line number Diff line change
Expand Up @@ -240,6 +240,7 @@ if(BUILD_TESTING AND PTI_BUILD_SAMPLES)
add_subdirectory(samples/onemkl_gemm)
add_subdirectory(samples/iso3dfd_dpcpp)
add_subdirectory(samples/metrics_iso3dfd_dpcpp)
add_subdirectory(samples/callback)
endif()

if(BUILD_TESTING AND PTI_BUILD_TESTING)
Expand Down
3 changes: 2 additions & 1 deletion sdk/include/pti/pti.h
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,8 @@ typedef enum {
//!< PTI_VIEW_EXTERNAL_CORRELATION
PTI_ERROR_BAD_TIMESTAMP = 6, //!< error in timestamp conversion, might be related with the user
//!< provided TimestampCallback
PTI_ERROR_BAD_API_ID = 7, //!< invalid api_id when enable/disable runtime/driver specific api_id
PTI_ERROR_BAD_API_ID = 7, //!< invalid api_id when enable/disable runtime/driver specific api_id
PTI_ERROR_AT_LEAST_ONE_GPU_VIEW_MUST_BE_ENABLED = 8, //!< at least one GPU view must be enabled for kernel tracing
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
PTI_ERROR_AT_LEAST_ONE_GPU_VIEW_MUST_BE_ENABLED = 8, //!< at least one GPU view must be enabled for kernel tracing
PTI_NO_GPU_VIEW_ENABLED = 8, //!< at least one GPU view must be enabled for kernel tracing

I think having a shorter name for the error is actually helpful here.
If developers are interested in having a string description of their error code, one could think about implementing a function like const char* ptiGetErrorMessage(...), similar to CUPTI: https://docs.nvidia.com/cupti/api/group__CUPTI__RESULT__API.html

PTI_ERROR_DRIVER = 50, //!< unknown driver error
PTI_ERROR_TRACING_NOT_INITIALIZED = 51, //!< installed driver requires tracing enabling with
//!< setting environment variable ZE_ENABLE_TRACING_LAYER
Expand Down
227 changes: 227 additions & 0 deletions sdk/include/pti/pti_sync_callback.h
Original file line number Diff line number Diff line change
@@ -0,0 +1,227 @@
//==============================================================
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused about the file name. pti_sync_callback.h sounds to me like we're only dealing with synchronization stuff here, although this looks to be all callback related event handling.
Can we find a better name for this? Maybe even just drop the _sync part?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that was a suggestion from @jmellorcrummey - to name it in a way to pronounce that these callbacks are synchronous. may be I misunderstood
if you and @jmellorcrummey (and anyone) can suggest better name - this would be great

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea, but I think using the abbreviation sync might be a bit unfortunate. I'm also not the best person for naming things though, so I don't have a better idea 😄
The naming of this file should certainly not be a blocker. Even having a short description in the file that this contains synchronous callbacks is sufficient to clearly communicate what this is about.

// Copyright (C) Intel Corporation
//
// SPDX-License-Identifier: MIT
// =============================================================

#ifndef PTI_SYNC_CALLBACK_H_
#define PTI_SYNC_CALLBACK_H_

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#include <stdint.h>

So we don't have implicit dependencies on other header files.

#include "pti/pti_metrics.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we include metrics in callbacks if metrics is going to be a user of the callbacks?

#include "pti/pti_view.h"

/**
* This file contains APIs that so far experimental in PTI
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* This file contains APIs that so far experimental in PTI
* This file contains APIs that so far experimental in PTI.

* APIs and data structures in this file are work-in-progress and subject to change!
Comment on lines +14 to +15
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* This file contains APIs that so far experimental in PTI
* APIs and data structures in this file are work-in-progress and subject to change!
* This file contains APIs that are so far experimental in PTI
* APIs and data structures in this file are work-in-progress and subject to change!

*
* All in this file concerns Callback API
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* All in this file concerns Callback API
* All content in this file concerns Callback API.

* Callback API is useful for many things,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Callback API is useful for many things,
* The Callback API is useful for many purposes,

* including to the implementation of MetricsScope functionality that wants to subscribe for
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* including to the implementation of MetricsScope functionality that wants to subscribe for
* including to the implementation of `MetricsScope` functionality that needs to subscribe to

* kernel append to command list .. and may be to other events.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* kernel append to command list .. and may be to other events.
* events like kernel appends to a command list, and potentially other events.

*
* So MetricsScope API is the first user of [for now internal] Callback API
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* So MetricsScope API is the first user of [for now internal] Callback API
* The `MetricsScope` API is in progress and the first (internal) user of the Callback API.

Because the callback API isn't internal now, right? Due to this PR?

*
*/


/* clang-format off */
#if defined(__cplusplus)
extern "C" {
#endif

typedef uint32_t pti_callback_subscriber_handle;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it too late to make this a opaque pointer? Could avoid mistakes with invalid domain handles.


#define PTI_CALLBACK_SUBSCRIBER_HANDLE_INVALID 0

typedef enum _pti_callback_domain {
PTI_CB_DOMAIN_INVALID = 0,
PTI_CB_DOMAIN_DRIVER_CONTEXT_CREATED = 1, //!< Not implememted yet
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
PTI_CB_DOMAIN_DRIVER_CONTEXT_CREATED = 1, //!< Not implememted yet
PTI_CB_DOMAIN_DRIVER_CONTEXT_CREATED = 1, //!< Not implemented yet

And below. Implemented is spelled wrong in almost all these comments.

//!< attempt to enable it will return PTI_ERROR_NOT_IMPLEMENTED
PTI_CB_DOMAIN_DRIVER_MODULE_LOADED = 2, //!< Not implememted yet
//!< attempt to enable it will return PTI_ERROR_NOT_IMPLEMENTED
PTI_CB_DOMAIN_DRIVER_MODULE_UNLOADED = 3, //!< Not implememted yet
//!< attempt to enable it will return PTI_ERROR_NOT_IMPLEMENTED
PTI_CB_DOMAIN_DRIVER_GPU_OPERATION_APPENDED = 4, //!< This also serves as PTI_CB_DOMAIN_DRIVER_GPU_OPERATION_DISPATCHED
//!< when appended to Immediate Command List,
//!< which means no separate callback PTI_CB_DOMAIN_DRIVER_GPU_OPERATION_DISPATCHED
Comment on lines +44 to +46
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for my understanding:
The comment basically states that attaching an event to an immediate command list only dispatches this event. We still get an event when the operation has completed, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right. there still be event on the completion.
But append and dispatch "merged" into one for Immediate command list

PTI_CB_DOMAIN_DRIVER_GPU_OPERATION_DISPATCHED = 5, //!< Not implememted yet
//!< attempt to enable it will return PTI_ERROR_NOT_IMPLEMENTED
PTI_CB_DOMAIN_DRIVER_GPU_OPERATION_COMPLETED = 6,
PTI_CB_DOMAIN_DRIVER_HOST_SYNCHRONIZATION = 7, //!< Not implememted yet
//!< attempt to enable it will return PTI_ERROR_NOT_IMPLEMENTED

PTI_CB_DOMAIN_DRIVER_API = 1023, //!< Not implemeted yet,
//!< attempt to enable it will return PTI_ERROR_NOT_IMPLEMENTED
//!< Callback created for all Driver APIs
Comment on lines +53 to +55
Copy link

@Thyre Thyre Sep 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you intend to have something like a RUNTIME_API as well or would this be handled in any other way? Would that even make sense with Level Zero, since runtime is most likely something like SYCL, OpenCL or other programming paradigms?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DRIVER_API here exactly refers to Level Zero. OpenCL would be also "driver level" (when/if supported)

May be one day we might want to add Callbacks to "user"-side /runtime APIs, that many users directly us - e.g. think oneCCL.

// below domains to inform user about PTI internal events
PTI_CB_DOMAIN_INTERNAL_THREADS = 1024, //!< Not implemeted yet
PTI_CB_DOMAIN_INTERNAL_EVENT = 1025, //!< Not implemeted yet

PTI_CB_DOMAIN_MAX = 0x7fffffff
} pti_callback_domain;

typedef enum _pti_callback_phase {
PTI_CB_PHASE_INVALID = 0,
PTI_CB_PHASE_API_ENTER = 1,
PTI_CB_PHASE_API_EXIT = 2,
Comment on lines +65 to +66
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could there be any case where something like ENTEREXIT makes sense, similar to what the OpenMP Tools Interface has with ompt_scope_beginend?

PTI_CB_PHASE_INTERNAL_THREAD_START = 3,
PTI_CB_PHASE_INTERNAL_THREAD_END = 4,
PTI_CB_PHASE_INTERNAL_EVENT = 5,

PTI_CB_PHASE_MAX = 0x7fffffff
} pti_callback_phase;

typedef enum _pti_backend_command_list_type {
PTI_BACKEND_COMMAND_LIST_TYPE_UNKNOWN = (1<<0),
PTI_BACKEND_COMMAND_LIST_TYPE_IMMEDIATE = (1<<1),
PTI_BACKEND_COMMAND_LIST_TYPE_MUTABLE = (1<<2),

PTI_BACKEND_COMMAND_LIST_TYPE_MAX = 0x7fffffff
} pti_backend_command_list_type;

typedef void* pti_backend_command_list_t; //!< Backend command list handle
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: maybe organize in a difference place.

Like, keep the enums together and the handles separately.


/**
* A user can subscribe to notifications about non-standard situation from PTI
* when it collects or processes the data
*/
typedef enum _pti_internal_event_type {
PTI_INTERNAL_EVENT_TYPE_INFO = 0,
PTI_INTERNAL_EVENT_TYPE_WARNING = 1, // one or few records data inconsistences, or other
// collection is safe to continue
PTI_INTERNAL_EVENT_TYPE_CRITICAL = 2, // critical error after which further collected data are invalid

PTI_INTERNAL_EVENT_TYPE_MAX = 0x7fffffff
} pti_internal_event_type;

typedef enum _pti_gpu_operation_kind {
PTI_GPU_OPERATION_KIND_INVALID = 0,
PTI_GPU_OPERATION_KIND_KERNEL = 1,
PTI_GPU_OPERATION_KIND_MEMORY = 2,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does the memory operation kind contain?
Is this only a memcpy operation, or could it also contain malloc/free?
Having it separated could help some tools, which want to handle certain function groups separately (e.g. correlate a memcpy, but not an allocation).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are only for GPU ops. I guess we need others for malloc/free

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At a first step, I'm totally fine with omitting an operation kind for allocations. That's exactly what we are considering at the moment during completely reworking one of our adapters as well.
More operation kinds can be added later on easily.

PTI_GPU_OPERATION_KIND_OTHER = 3,

PTI_OPERATION_KIND_MAX = 0x7fffffff
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
PTI_OPERATION_KIND_MAX = 0x7fffffff
PTI_GPU_OPERATION_KIND_MAX = 0x7fffffff

for consistency.

} pti_gpu_operation_kind;

typedef struct _pti_gpu_op_details {
pti_gpu_operation_kind _operation_kind; //<! Kind of the operation: kernel, mem op
uint64_t _operation_id; //<! GPU kernel or memory operation instance ID,
//<! unique throughout the process
uint64_t _kernel_handle; //!< a handle uniquly identifying kernel object as
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
uint64_t _kernel_handle; //!< a handle uniquly identifying kernel object as
uint64_t _kernel_handle; //!< a handle uniquely identifying kernel object as
//!< contained in the module at the specific offset.
//!< This will be zero if not defined or for memory operations.

//!< contained in the module at the specific offset
//!< it will be zero in case of not defined or
//!< for a memory operations
Comment on lines +110 to +113
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest introducing a variable for the undefined / invalid case, in case you ever want to change the value. This also has the benefit that tools can use this variable to write "cleaner" code.

Maybe something like:

#define PTI_INVALID_KERNEL_HANDLE (0x7fffffff)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see suggestion above but "a memory operations" should be just memory operations

const char* _name; //!< symbolic name of a kernel or memcpy operation
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would the name of the memcpy operation look like?
I would've only expected to see kernel names, though I won't object getting names for memcpy operations as well. Makes things just easier for us 😄

} pti_gpu_op_details;

typedef struct _pti_callback_gpu_op_data {
pti_callback_domain _domain; // domain of the callback
pti_backend_command_list_type _cmd_list_properties; //!< Immediate command list, Command Queue execute,..
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inconsistent capitalization, above in the comments, Immediate command list is capitalized as Immediate Command Lists. However, here is lower case. Probably should make it lowercase everywhere or capitalize everywhere. (likely lowercase)

pti_backend_command_list_t _cmd_list_handle; //!< Device back-end command list handle
pti_backend_queue_t _queue_handle; //!< Device back-end queue handle
pti_device_handle_t _device_handle; //!< Device handle,
pti_callback_phase _phase; //!< Could be ONLY_NOTIFY or API Call ENTER/EXIT
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ONLY_NOTIFY case is missing, see my prior comment.

uint32_t _return_code; // will be valid only for L0 API EXIT, for others will be nullptr
Copy link

@Thyre Thyre Sep 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nullptr wouldn't really be valid for uint32_t, should probably also be a defined value as suggested above.

uint32_t _correlation_id; // ID that corresponds to the same call reported by View API records
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems to be a switch from //!< ---> // through this file. I think its a good idea to keep this consistent. //!< is probably for the documentation.

uint32_t _operation_count; // number of operations submitted to the GPU,
// non-zero only for DOMAIN_DRIVER_GPU_OPERATION_LAUNCH,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see DOMAIN_DRIVER_GPU_OPERATION_LAUNCH in the API?

maybe?

Suggested change
// non-zero only for DOMAIN_DRIVER_GPU_OPERATION_LAUNCH,
// non-zero only for DOMAIN_DRIVER_GPU_OPERATION_APPENDED,

// or API related to GPU operation submission
pti_gpu_op_details* _operation_details; // not Null only for DOMAIN_DRIVER_GPU_OPERATION_LAUNCH,
// or API related to GPU operation submission.
} pti_callback_gpu_op_data;

typedef struct _pti_internal_callback_data {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is inconsistently named with _pti_callback_gpu_op_data.

Should it be _pti_gpu_op_callback_data ? or vice versa

pti_callback_domain _domain; // domain of the callback
pti_callback_phase _phase; // THREAD START/END or INTERNAL EVENT
uint32_t _detail; // depending on the domain should be casted/interpreted
// as a purpose of an internal PTI thread or
// pti_internal_event_type
Comment on lines +136 to +138
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
uint32_t _detail; // depending on the domain should be casted/interpreted
// as a purpose of an internal PTI thread or
// pti_internal_event_type
uint32_t _detail; // For THREAD START/END, this describes the internal PTI thread purpose.
// For INTERNAL EVENT, this describes the pti_internal_event_type.

Is there any way to get the internal PTI thread purpose?
Having a number without any actual meaning feels a bit pointless, even if we have the message in the same struct.

const char* _message; // explains details
} pti_internal_callback_data;

typedef void (*pti_callback_function)(
pti_callback_domain domain,
pti_api_group_id driver_api_group_id, // driver API group ID, keep it to distinguish between L0 and OpenCL
// although the current implementation is only for L0
Comment on lines +144 to +145
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this always the driver_api ID, or may we also get other event types here?
PTI_API_GROUP_SYCL would be a runtime group_id, just by looking at the comments.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest just dropping the driver_ part from this argument and the next one. This gives a bit more flexibility in the future without breaking code building on top of this API.

uint32_t driver_api_id,
pti_backend_ctx_t backend_context, //!< Driver (L0) level context handle
void* cb_data, //!< depending on the domain it should be type-casted to the pointer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since both pti_callback_gpu_op_data and pti_internal_callback_data contain _domain and _phase can we seperate those into a base record and make this,

pti_callback_base {
.. _domain
.. _phase.
}

pti_callback_base* cb_data

then cast based on the value of cb_data->domain?

struct _pti_callback_gpu_op_data {
pti_callback_base*
}

then I think you can remove domain from the callback too but not sure about that

//!< to either pti_callback_gpu_op_data, pti_internal_callback_data
//!< or to others to be defined
void* global_user_data, //!< Any global data defined by user returned
//!< to every callback from a same subscriber
void** instance_user_data); //!< Data that could be passed between ENTER and EXIT
//!< phases of one API call

/**
* Callback API functions
* None of the PTI API functions should be called from a Callback function
* Exceptions are the helper functions that returns character representation of enums
*/

/**
* @brief Initialize Callback subscriber
*
* @param subscriber - subscriber handle
* @param callback - pointer to the callback function
* @param user_data - user data to be passed to the callback function
* @return pti_result
*/
pti_result PTI_EXPORT
ptiCallbackSubscribe(pti_callback_subscriber_handle* subscriber,
pti_callback_function callback,
void* user_data);
Comment on lines +170 to +173
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just as a question out of curiosity. Do you plan to support more than one subscriber at a time?
CUPTI certainly won't allow more than one, I don't know about the AMD APIs. The OpenMP Tools Interface also only allows one, but one can multiplex this interface, as demonstrated by LLVM.

Having the option to attach multiple subscribers can have its benefit, with the main drawback obviously being the potential overhead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Current design/implementation supports multiple subscribers. Right - having multiple ones would bring additional overhead,. plus we also need explain how they should work together.


/**
* @brief Unsubscribe Callback subscriber, this unsubscribes from all domains, disables callback,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* @brief Unsubscribe Callback subscriber, this unsubscribes from all domains, disables callback,
* @brief Unsubscribe Callback subscriber. This unsubscribes from all domains, disables the callback,

* clean all resources related to the subscriber handle and invalidate the handle
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* clean all resources related to the subscriber handle and invalidate the handle
* cleans up all resources related to the subscriber handle, and invalidate the handle.

*/
pti_result PTI_EXPORT
ptiCallbackUnsubscribe(pti_callback_subscriber_handle subscriber);

/**
* @brief Enables callbacks on specific domain
*
* @param subscriber - subscriber handle
* @param domain - domain to enable
* @param enter_cb - indicate if callback called on enter/start: 0-no, 1-yes; used only for domains with 2 sites
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no/yes should probably be an enum. The API is ambiguous this way.

* @param exit_cb - indicates if callback called on exit/end: 0-no, 1-yes; used only for domains with 2 sites
Comment on lines +187 to +188
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One should probably document which domains support these two parameters.
How should one call this function with these domains if he want to enable this domain?

What would happen if one passes false for both enter_cb and exit_cb?
Would the domain be disabled? Should this return an error code?

* @return pti_result
*/
pti_result PTI_EXPORT
ptiCallbackEnableDomain(pti_callback_subscriber_handle subscriber,
pti_callback_domain domain,
uint32_t enter_cb,
uint32_t exit_cb);

/**
* @brief Disables callbacks for specific domain
*/
pti_result PTI_EXPORT
ptiCallbackDisableDomain(pti_callback_subscriber_handle subscriber,
pti_callback_domain domain);

/**
* @brief Disables the callback of the subscriber for all domains
*/
pti_result PTI_EXPORT
ptiCallbackDisableAllDomains(pti_callback_subscriber_handle subscriber);

/**
* @brief Helper function to return stringified enum members for pti_callback_domain
*
* @return const char*
*/
PTI_EXPORT const char* ptiCallbackDomainTypeToString(pti_callback_domain domain);

/**
* @brief Helper function to return stringified enum members for pti_callback_phase
*
* @return const char*
*/
PTI_EXPORT const char* ptiCallbackPhaseTypeToString(pti_callback_phase phase);

#if defined(__cplusplus)
}
#endif
#endif // PTI_SYNC_CALLBACK_H_
32 changes: 32 additions & 0 deletions sdk/samples/callback/CMakeLists.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
cmake_minimum_required(VERSION 3.14)

project(PTI_Samples_CALLBACK CXX)

if(NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE "Release")
endif()

# TODO: find_package(IntelSYCL)?
include(CheckCXXCompilerFlag)
check_cxx_compiler_flag("-fsycl" has_sycl)

if (NOT has_sycl)
message(WARNING "${PROJECT_NAME} requires a sycl compatible compiler")
return()
endif()

add_executable(callback main.cc)

target_link_options(callback PUBLIC -fsycl -gline-tables-only)
target_compile_options(callback PUBLIC -fsycl -gline-tables-only)

target_include_directories(callback PRIVATE "${PROJECT_SOURCE_DIR}/../samples_utilities")

target_link_libraries(callback PRIVATE LevelZero::level-zero)

# Allow building in-source and out-of-source
if (NOT TARGET Pti::pti_view)
find_package(Pti REQUIRED)
endif()

target_link_libraries(callback PUBLIC Pti::pti_view)
Loading