14:04 karolherbst: funky.... openvino through zink just works (if I force enable subgroups)
14:04 karolherbst: on iris it gives wrong results and on radeonsi it runs into a page fault...
14:08 karolherbst: (on the gpu that is)
14:28 pitust: Hello -- I'm trying to manually write some pixels to a DRM device, but I seem to be misconfiguring something. Specifically, even though I write one 4-byte pixel value into the buffer, two different pixels on the display light up.
14:29 pitust: code: https://paste.sr.ht/~pitust/6a7b61e9db00d1e224e148af393853c5dc4e2db1
14:29 pitust: So I write to pixel at offset 48 (*4 because uint32_t), which *should* light up one pixel. However, two different pixels light up: (48, 0) and (1, 48).
14:41 pitust: oh. i had to set the height to 64 for... some reason
17:11 DavidHeidelberg: Have anyone tried run VK/GL CTS with GPU on x1 riser? I assume few tests may be bandwidth dependent, but what about majority, should it be fine?
17:48 calebccff: hey folks, I'm trying to figure out a regression on Qualcomm SDM845 (a630), since 6.6 the framebuffer emulation seems to be broken with some(?) DSI panels. This breaks VT and framebuffer splash screens during boot, but running a DRM client and then killing it seems to resolve the issue
17:49 calebccff: is anyone using FBDEV emulation anymore? Or is it time to just write userspace replacements for the VT...
17:50 karolherbst: DavidHeidelberg: I'd expect that to be kinda slow tbh
17:50 karolherbst: given that tests create new textures like most of the time, I wouldn't be surprised if the CTS actually hits bottlenecks there
17:50 karolherbst: the main point of the CTS is to upload stuff and download them again
17:58 calebccff: lumag: do you have some idea why I need to start a DRM client to get the framebuffer to start working on 6.6?
23:24 lumag: calebccff, do you have CONFIG_FRAMEBUFFER_CONSOLE enabled?