So, you apply the same logic in the function
intel_gpgpu_event_get_exec_timestamp here.

BSpec really have some mistakes.
But for most of the IVB platform, 
>-    result = result & 0xFFFFFFFFF0000000;
>-    result = result >> 28;
works very well.

So I think if you want to correct this, you should add the PCIID check
like HSW.
 IS_XXXX(gpgpu->drv->device_id) should be added here.

If you do not know how to do it, please notify the PCIID of your
Baytrail-I E3827 



On Wed, 2014-06-04 at 16:15 +0000, [email protected] wrote:
> commit a9ab94503348068579e8e816e80eb62598fd7f5f
> Author: Michael Ferguson <[email protected]>
> Date:   Fri May 30 11:32:36 2014 -0600
> 
>     Fix cl_event_get_timestamp for submit and queued
>     
>     The cl_gpgpu_event_get_gpu_cur_timestamp function did not apply the same 
> logic as the cl_gpgpu_event_get_exec_timestamp regarding the timestamp 
> counter on the Baytrail, which resulted in a bogus GPU current timestamp.
>     
>     Tests on the Baytrail-I E3827 indicated the following clock values in the 
> profiling_exec test before this patch:
>     
>         queued = 1920
>         submit = 1920
>         start  = 2762442307840
>         end    = 2762442351360
>     
>     Obviously these values were not correct for the queued and submit 
> counters. After applying this patch the values in the profiling_exec test 
> indicated:
>     
>         queued = 320306542080
>         submit = 320306617600
>         start  = 320308817920
>         end    = 320308857600
> 
> diff --git a/src/intel/intel_gpgpu.c b/src/intel/intel_gpgpu.c
> index bde9bd5..22e04f5 100644
> --- a/src/intel/intel_gpgpu.c
> +++ b/src/intel/intel_gpgpu.c
> @@ -1138,8 +1138,12 @@ intel_gpgpu_event_get_gpu_cur_timestamp(intel_gpgpu_t* 
> gpgpu, uint64_t* ret_ts)
>    if (IS_HASWELL(gpgpu->drv->device_id)) {
>      result = result & 0x0000000FFFFFFFFF;
>    } else {
> -    result = result & 0xFFFFFFFFF0000000;
> -    result = result >> 28;
> +    /* 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;
>    }
>    result *= 80;
> 
> _______________________________________________
> Beignet mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/beignet



_______________________________________________
Beignet mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/beignet

Reply via email to