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?