Pekka Paalanen writes:
> I did not mean you would be solving that problem. I meant that it would
> be good to figure out what people actually want from the API to be able
> to solve the problem themselves.
Thanks for the clarification. I'd suggest that we not try and solve that
problem until we
On Tue, 10 Jul 2018 11:02:23 -0700
"Keith Packard" wrote:
> Pekka Paalanen writes:
>
> > On Sat, 23 Jun 2018 12:13:53 -0500
> > Jason Ekstrand wrote:
> >
> >> I haven't thought through this comment all that hard but would it make
> >> sense to have three timestamps, CPU, GPU, CPU so that
Pekka Paalanen writes:
> On Sat, 23 Jun 2018 12:13:53 -0500
> Jason Ekstrand wrote:
>
>> I haven't thought through this comment all that hard but would it make
>> sense to have three timestamps, CPU, GPU, CPU so that you have error bars
>> on the GPU timestamp? At the very least, two
On Sat, 23 Jun 2018 12:13:53 -0500
Jason Ekstrand wrote:
> I haven't thought through this comment all that hard but would it make
> sense to have three timestamps, CPU, GPU, CPU so that you have error bars
> on the GPU timestamp? At the very least, two timestamps would be better
> than one
I haven't thought through this comment all that hard but would it make
sense to have three timestamps, CPU, GPU, CPU so that you have error bars
on the GPU timestamp? At the very least, two timestamps would be better
than one so that, when we pull it into the kernel, it can provide something
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to correlate GPU and CPU
timestamps.
v2: Adopt Jason Ekstrand's coding
