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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
