00:18 Kayden: dj-death: shouldn't intel_device_info_timebase_scale probably be using floating point or fixed point math or something? right now it's just truncating the clock from 1000000000 / 19200000 = 52.083333333 to 52 ns per clock, dropping the .08ns entirely
00:18 Kayden: looking at ext_timer_query-time-elapsed that managed to accumulate an error of 0.28ms
00:18 Kayden: (283660ns)
00:21 Kayden: I guess anv doesn't use this outside of utrace
00:21 Kayden: and iris also drops the fractional parts sometimes
00:42 dj-death: Kayden: huh yeah...
00:44 dj-death: Kayden: also worried about floating point ;)
00:45 Kayden: hmm, windows reports 64-bits for GL_QUERY_COUNTER_BITS
01:27 Kayden: karolherbst: huh, literally nobody does this except iris. trying out https://gitlab.freedesktop.org/kwg/mesa/-/commit/654e696957b759b689507da8a4d04839c2f417e0 now
01:28 Kayden: I'm not sure this made sense in 2012 with 32-bit timestamps and 80ns/clock scaling, but I really don't think it makes sense now with 36-bit timestamps and 52.08333ns/clock scaling
02:39 babyfaceold: There is a bit of problems when you make your code as default, instead of cryptographic maturer versions like miden-vm, its about energy consumption, we now have the code, however i have been working on security as of now, MAC and NIC and PCI interconnect safety and security that is. but i am not saying your code serves no purpose or is easy to implement, all i say is that you should pull in extensions that would allow to mitigate that energy
02:39 babyfaceold: crisis and temporal global warming maddness, those extensions are already done.
09:06 CounterPillow: mriesch: drm, fbdev is deprecated and has been forever
12:04 mriesch: CounterPillow: ah ok. i guess a tinydrm driver would be suitable
12:15 mriesch: how could a drm Driver access the data of a (dumb) framebuffer?