[Intel-gfx] Broken TIMESTAMP on x86_64 - how to stay compatible

[Michał Winiarski]

Hi,

Some time ago I've raised an issue, that only 32bits of TIMESTAMP are being
exposed to userspace on x86_64, you suggested that we need to stay compatible
with old (and new) userspace and proposed adding a new param that can can be
accessed via getparam. 
However, after checking beignet and mesa, I've noticed that they are already
broken. Currently the register looks like this:

f = valid counter value
X = garbage

i386:
0x0000000fffffffff

x86_64:
0xffffffffXXXXXXXX
(on gen8 we get duplicated 32-bit timestamp in both halves)

Mesa expects values from x86_64 arch, so it's broken on i386, beignet is
checking (compile time) if it's being built for 32 or 64 bits and adjusts its
behaviour for gen7 (broken for 32-bit userspace running on 64-bit kernel - not
sure if that's a valid usecase). For gen8 it's just masking high 32-bits.

Taking all of this under consideration, it's actually impossible to stay
compatible with old userspace and include additional 4-bits. I posted a patch,
that basically stuffs additional 4-bits into high portion of returned value, but
haven't received any comments.

http://lists.freedesktop.org/archives/intel-gfx/2014-October/053455.html
Skipped additional param since well-behaved userspace can just check if there
are zeroes in unused portion of register, as Chris suggested.

Unfortunately because of inconsistent userspace behaviour this actually causes
some breakage (i386 or gen8 beignet). Would it be acceptable? (I don't like it
since we could skip shuffling bytes around and that would just break other
scenarios)
If not, what's your opinion on solution where we setparam from userspace, and
that adjusts kernel behaviour (if param is set we use 2x32 read)?

-- 
Michał Winiarski
Intel VPG