In a 32-bit chroot, the profiling_exec() test returns garbage: queue_to_submit is always exactly 2**32 nanoseconds, while submit_to_start and start_to_end are sometimes exactly 0 and sometimes non-round but obviously wrong (e.g. >60sec, failing the test, when it visibly took <10sec).
This affects both 1.1.2 and current master.
This does not happen in a 64-bit chroot (I haven't tried a 32-bit kernel as I don't have one set up). Both chroots are Debian unstable (libdrm 2.4.67, llvm 3.7.1) with /dev/dri bind-mounted, while the base system is 64-bit Debian stable (linux 3.16 with register whitelist patch). Hardware is i5-3230M.
The comments in intel_gpgpu_read_ts_reg_gen7 and intel_gpgpu_event_get_exec_timestamp (src/intel/intel_gpgpu.c) suggest it is known that 32- and 64-bit systems use different formats for the GPU timestamp.
Yes, I think you are right, the timestamp read from kernel are different between 32-bit and 64-bit kernel. Beignet check the kernel is 32bits or 64bits used the compiler macro __i386__, it seems not correct, as your system, 32-bit chroot + 64-bit kernel.
Can you show me the output of command "uname -m" in your system? Or do you know how to get the kernel type?
$ uname -m
$ uname -a
Linux rnpalmer-laptop 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29) x86_64 GNU/Linux
These are the same both outside and inside the chroot.
'uname' is also available as a system call - http://www.gnu.org/software/libc/manual/html_node/Platform-Type.html#Platform-Type
OK, I will send a patch use the uname to check the get kernel info, thanks.
I have send a patch for it:
Could you have a try?
It fixes the problem in 1.1.2 (but I haven't checked whether it still works in all-64-bit).
I couldn't check master as it failed to compile with this (unrelated-looking) error:
/home/rnpalmer/Debian/builds/stackbuild/beignet/utests/compiler_workgroup_reduce.cpp: In function 'void workgroup_generic(WG_FUNCTION, T*, T*)':
/home/rnpalmer/Debian/builds/stackbuild/beignet/utests/compiler_workgroup_reduce.cpp:193:57: error: call of overloaded 'abs(float)' is ambiguous
float num_diff = abs(num_computed - num_expected) / abs(num_expected);
Fixed in 1.2.0