On Fri, Sep 26, 2025 at 3:41 AM Lukas Zapolskas <[email protected]> wrote:
>
> Hello Chia-I,
>
[...]
> > + switch (out->cpu_clockid) {
> > + case CLOCK_MONOTONIC:
> > + cpu_timestamp = ktime_get_ns;
> > + break;
> > + case CLOCK_MONOTONIC_RAW:
> > + cpu_timestamp = ktime_get_raw_ns;
> > + break;
> > + case CLOCK_REALTIME:
> > + cpu_timestamp = ktime_get_real_ns;
> > + break;
> > + case CLOCK_BOOTTIME:
> > + cpu_timestamp = ktime_get_boottime_ns;
> > + break;
> > + case CLOCK_TAI:
> > + cpu_timestamp = ktime_get_clocktai_ns;
> > + break;
>
> Out of interest, what is the use-case for the REALTIME, BOOTTIME and TAI
> clocks? Looking at
> VK_KHR_calibrated_timestamps, it seems that only MONOTONIC and MONOTONIC_RAW
> are exposed directly.
> I worry that providing the other clocks may make it easier for accidentally
> querying timestamps that
> can't be correlated with driver state. A recent Mesa change aligned PanVK
> Perfetto instrumentation on
> MONOTONIC_RAW [1], and the performance counter patches I've proposed also use
> MONOTONIC_RAW
> as the only clock source.
I followed drm_xe_query_engine_cycles without giving much thought. As
long as we leave room for future extension, we can certainly only
allow those required by vulkan.
