01:26bl4ckb0ne: is it me or `piglit_translation_matrix` is wrong?
01:28bl4ckb0ne: diagonal should be 1 instead of 0
01:28bl4ckb0ne: based on https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glTranslate.xml
01:41imirkin: odd indeed
01:43bl4ckb0ne: seems like the test im writing is the only one using it
01:43bl4ckb0ne: should I fix it in my new test?
01:43imirkin: have a separate patch fixing it, imo
01:44bl4ckb0ne: will do then, thanks
02:03imirkin: -- Found PythonInterp: /usr/bin/python3.7 (found version "3.7.6")
02:03imirkin: how do i convince cmake to use python3.6?
02:05imirkin: aha, -DPYTHON_EXECUTABLE:FILEPATH=foo
09:03leonmaxx: Hello! How can I test if compressed texture format (e.g. ASTC) is supported by hardware and not decompressed on upload to GPU?
10:06udovdh: when booting with pci=nocrs the firmware things fail: https://pastebin.com/mL6Bmc4h
10:06udovdh: what is wrong?
10:09pendingchaos: leonmaxx: I think glGetInternalformativ with GL_INTERNALFORMAT_PREFERRED would give GL_NONE if it's decompressed on upload (I haven't tested though)
10:09pendingchaos: not sure if Mesa is correct to return GL_NONE in this case though
10:13karolherbst: is there a way to properly debug piglit in terms of gbm support?
10:15karolherbst: uhh.. seems like I just missed some packages, nvm
10:26leonmaxx: pendingchaos: Will test that, thanks!
10:45leonmaxx: It returns GL_FALSE for ASTC and BPTC. But I believe BPTC format is supported in hardware by Radeon 5600 XT.
14:54dj-death: anybody knows what piece of code in Xorg is responsive for composition when there is no compositor?
14:57emersion: there's no composition when there's no compositor
15:03dj-death: but something must put everything into a single buffer for scanout right?
15:21MrCooper: dj-death: it just draws to the front buffer directly
15:22dj-death: MrCooper: you know where that code is?
15:22MrCooper: it's the so-called screen pixmap, which is basically a pixmap like any other as far as the drawing code is concerned
15:22MrCooper: so there's no special code for it
15:23dj-death: MrCooper: apps don't have a backbuffer in that case?
15:26MrCooper: nope; normally X clients just draw to a window, which without compositing directly uses the screen pixmap for its storage
15:27MrCooper: (i.e. ScreenRec::GetWindowPixmap(window) returns the screen pixmap in that case)
15:54dj-death: MrCooper: thanks
16:16bnieuwenhuizen: MrCooper: How does that work with DRI3?
16:17bnieuwenhuizen: since with DRI3+Present the app provides the buffer ...
16:17imirkin: Present presumably
16:17MrCooper: DRI3 back buffers are represented as separate pixmaps on the server side; the Present extension is then used to copy from such a pixmap to the window
16:19bnieuwenhuizen: Wait, so if we have a compositor, then the window buffer and the buffer given by the last Present command a seperate?
16:26dj-death: MrCooper: looking these corruptions https://gitlab.freedesktop.org/xorg/xserver/-/issues/1012
16:26dj-death: MrCooper: as far as I can tell the GPU isn't even involved
16:26dj-death: according to perf & i915/perf traces
16:27dj-death: there is no listening to the drm vblank events either
16:28dj-death: looks like cpu cachelines corruptions
16:28imirkin: bnieuwenhuizen: lots and lots of copying :)
16:31dj-death: same with either i965/iris
16:31dj-death: that is somewhat odd...
16:32dj-death: though I noticed those corruption tend to disappear if the cpu is lightly loaded
16:45dj-death: I have no idea how display is supposed to properly display things when no pageflips seems to happen
16:53imirkin: dj-death: huh?
16:53imirkin: scanout just scans out whatever's in ra
16:58dj-death: imirkin: sure, but if an application writes to it at the same time, how does that work? ;)
16:59dj-death: I'm probably missing something
17:01imirkin: how does what work?
17:02imirkin: scanout's job is to serialize memory into a "data stream" to be sent over the wire
17:02imirkin: application's job is to update memory
17:03imirkin: if one chooses to be clever, one can use vblank interrupts to try and not cause tearing. but one rarely chooses to be clever.
17:03imirkin: also with front-buffer rendering, you're only updating small parts of the screen, not the whole fb
17:03imirkin: this was all probably designed where the thought of updating a whole fb within 1/60th of a second was laughable.
17:05HdkR: Now we live in a world where updating a 1080p display at 300hz isn't unheard of :)
17:05HdkR: And 360hz for the newest one
17:07imirkin: right, but that's not the world of 1980.
17:51daniels: I've heard there's a new window system around that solves these problems
17:57HdkR: I haven't seen it, must not exist :P
17:57karolherbst: one question about kmsro: is it required under wayland as well? How does XWayland change things here?
17:59imirkin: karolherbst: XWayland is surfaceless, so i don't think it needs the display component
17:59karolherbst: yeah.. that would be my guess as well
17:59imirkin: not 100% sure though
17:59imirkin: kmsro is largely needed for X to have a single thing that both displays and renders
17:59imirkin: but XWayland isn't in the displaying business
18:00karolherbst: ohhhh, right
18:00karolherbst: makes sense
18:00imirkin: but it's also based on X, so there could be a dumb reason instead of a good one.
18:09anarsoul: karolherbst: wayland compositors can't deal with separate display and render nodes either
18:09anarsoul: so yeah, you need kmsro for wayland
18:09karolherbst: okay, good to know
18:09imirkin: really? :(
18:09karolherbst: anarsoul: but couldn't compositors also do the copy themselves though?
18:09karolherbst: or well.. wahtever kmsro is doing
18:09anarsoul: what copy?
18:09imirkin: could but don't, i guess...
18:10emersion: > wayland compositors can't deal with separate display and render nodes either
18:10emersion: hmm, they can?
18:10anarsoul: but they don't?
18:10emersion: at least sway does it
18:11emersion: and GNOME supports DisplayLink (not sure about multi-GPU)
18:12anarsoul: emersion: so you're saying that sway can start on a system that has only 2 cards, one is display only, another is render only?
18:13emersion: hmm, sway supports multi-GPU, but i'm not sure it supports this particular setup
18:13emersion: i think GNOME does
18:13anarsoul: gnome doesn't
18:13emersion: GNOME supports render-only devices
18:13emersion: maybe it's missing the tiny bit to use render-only devices
18:13emersion: not hard to fix
18:19anarsoul: well, let's hope that gnome devs will get a board with utgard or midgard mali some day :)
18:26daniels: they still all need kmsro, and kmsro works fine with lima & panfrost
18:27daniels: because the allocator doesn't really exist, so we don't have any other way to allocate suitable buffers when the GPU & display controller have different requirements for pitch/tile/address alignment and physical contiguity
18:28daniels: anyway, Weston works just fine on imx/etnaviv, lima/*, panfrost/*, fdno/msm, etc etc
18:28daniels: mutter does too last I saw, and unless wlroots has done something really special with its renderer redesign, it does too
18:34anarsoul: yeah, they all work fine with kmsro
18:36karolherbst: heh.. meson optimization should support fast btw :)
21:04MrBIOS-: hi folks, I have a question about setting font sizes when you're using fbdev emulation
21:05MrBIOS-: the old boot time argument fbcon=font:SUN12x22 no longer seems to be honored with modern kernels, is there a new equivalent?>
21:36chen: Hi all?
21:36chen: I recently opened a issue about mesa proformance on my AMD laptop.. https://gitlab.freedesktop.org/mesa/mesa/-/issues/2759
21:38chen: not sure if this is a mesa-realted issue or X-related but a specific version of mesa (19.3.4) would make the performance issue disappear.. can anyone possibly give some suggestions on this issue? (like how can I better determine where the problem is...)