I verified this patch on both my 32bits and 64bits IVB platforms. Both results are OK and pass the profiling_exec test case.
On Tue, 2014-06-10 at 16:17 +0800, Yang Rong wrote: > In x86_64 system, the low 32bits of timestamp count are stored in the high 32 > bits of result which > got from drm_intel_reg_read, and 32-35 bits are lost; but in i386 system, the > timestamp count match bspec. > It seems the kernel readq bug. So shift 32 bit in x86_64, and only remain 32 > bits data in i386. > > Signed-off-by: Yang Rong <[email protected]> > --- > src/intel/intel_gpgpu.c | 31 ++++++++++++++++--------------- > 1 file changed, 16 insertions(+), 15 deletions(-) > > diff --git a/src/intel/intel_gpgpu.c b/src/intel/intel_gpgpu.c > index a1bd672..7aa5563 100644 > --- a/src/intel/intel_gpgpu.c > +++ b/src/intel/intel_gpgpu.c > @@ -1170,12 +1170,16 @@ > intel_gpgpu_event_get_gpu_cur_timestamp(intel_gpgpu_t* gpgpu, uint64_t* > ret_ts) > drm_intel_bufmgr *bufmgr = gpgpu->drv->bufmgr; > > drm_intel_reg_read(bufmgr, TIMESTAMP_ADDR, &result); > - if (IS_HASWELL(gpgpu->drv->device_id)) { > - result = result & 0x0000000FFFFFFFFF; > - } else { > - result = result & 0xFFFFFFFFF0000000; > - result = result >> 28; > - } > + /* In x86_64 system, the low 32bits of timestamp count are stored in the > high 32 bits of > + result which got from drm_intel_reg_read, and 32-35 bits are lost; but > match bspec in > + i386 system. It seems the kernel readq bug. So shift 32 bit in x86_64, > and only remain > + 32 bits data in i386. > + */ > +#ifdef __i386__ > + result = result & 0x0ffffffff; > +#else > + result = result >> 32; > +#endif /* __i386__ */ > result *= 80; > > *ret_ts = result; > @@ -1195,15 +1199,12 @@ intel_gpgpu_event_get_exec_timestamp(intel_gpgpu_t* > gpgpu, intel_event_t *event, > uint64_t* ptr = event->ts_buf->virtual; > result = ptr[index]; > > - if (IS_HASWELL(gpgpu->drv->device_id)) > - result = (result & 0xFFFFFFFFF) * 80; //convert to nanoseconds > - else > - /* According to BSpec, the timestamp counter should be 36 bits, > - but comparing to the timestamp counter from IO control reading, > - we find the first 4 bits seems to be fake. In order to keep the > - timestamp counter conformable, we just skip the first 4 bits. > - */ > - result = ((result & 0x0FFFFFFFF) << 4) * 80; //convert to nanoseconds > + /* According to BSpec, the timestamp counter should be 36 bits, > + but comparing to the timestamp counter from IO control reading, > + we find the first 4 bits seems to be fake. In order to keep the > + timestamp counter conformable, we just skip the first 4 bits. > + */ > + result = (result & 0x0FFFFFFFF) * 80; //convert to nanoseconds > *ret_ts = result; > > drm_intel_gem_bo_unmap_gtt(event->ts_buf); _______________________________________________ Beignet mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/beignet
