00:01alyssa: --That was a lot harder in my head :p
00:13krh: glmark looks different with $OTHER_DRIVER too
00:13krh: terrain, that is
00:13alyssa: krh: so that's two glmark mediump bugs in a week then :p
00:13krh: alyssa: it matches what I've seen
00:14krh: alyssa: this should look broken too: https://webglsamples.org/fishtank/fishtank.html
01:36mareko: nobody uses nir_lower_bool_to_bitsize, even though it was added as part of the last mediump MR
01:40robclark: anholt had some WIP to lower bool to 16b, but that is blocked on actually making 16b work in gs/tess..
01:42alyssa: mareko: fwiw, for midgard, I don't plan to use it; I *think* we can always do 16b unconditionally (even in highp) and just do some scheduling fixup for the corner case
01:42alyssa: for bifrost, I'm not sure what we're doing yet
07:25HdkR: oop! I'm right in the middle of an Ice Lake GPU hang
07:26HdkR: What do I need to do to help with diagnosis?
07:30HdkR: https://hastebin.com/aratusacaf.rb Some additional environment information
07:31HdkR: i3wm is flipping slowly between a fully rendered frame and a partially corrupt frame
07:32HdkR: Seems like it just isn't recovering
07:35HdkR: Managed to blindly/cleanly exit out of i3 and it returned to whatever Ubuntu's login screen is
07:46HdkR: That didn't last long. Did another hang
07:47HdkR: Let's disable compton this time around and hope for the best
08:38HdkR: blah, even without compton it failed
08:46HdkR: Alright, let's try Kitty temporarily, maybe this version of alacritty is being terrible
08:56HdkR: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2841 Looks like it might be a known issue
08:59sxlijin: oh lookie, i do remember my freenode password
09:01sxlijin: hi folks! i don't know graphics things, but civ 6 keeps segfaulting on my debian laptop (integrated intel gfx) and i kinda suspect mesa/opengl, but i have no idea if i'm starting in the right place
09:01sxlijin: any advice for how i would start ruling out suspects?
09:03sxlijin: or if there's another community that i should start with
10:27HdkR: Looks like the hanging problem I have is specific to how Alacritty is rendering. Kitty hasn't reproduced it...yet anyway
10:33MrCooper: sxlijin: a backtrace should tell where it's crashing
11:58jekstrand: HdkR: snag /sys/class/card0/error
12:00jekstrand: HdkR: Also, there were some pretty nasty i915 bugs in 5.6.0. Should be fixed in 5.6.6 or so.
15:15pcercuei: I want to set crtc_state->mode_changed in my plane's .atomic_check, when it gets disabled, so that a full modeset is performed
15:15pcercuei: problem is, when my plane gets disabled, its state->crtc is NULL
17:01valoga: I have an embedded device with a mali bifrost g31 graphics chip. I'm currently just using drmModeSetCrtc in a separate thread using 2 buffers
17:02valoga: I assume there are better ways about this? i read up on PageFlip and there also seems to be drmModeAtomic* functions as well
17:05imirkin: that's the standard double-buffered setup
17:05imirkin: you can move to triple-buffering too, depending on your needs
17:05valoga: you mean using a separate thread to manage 2-3 buffers and use drmModeSetCrtc?
17:06imirkin: well, doesn't have to be a separate thread
17:06imirkin: but there are basically just a handful of options here...
17:06imirkin: e.g. you have a single buffer, and you always render to it
17:06imirkin: this is aka front-buffer rendering
17:06imirkin: you get tearing, but it's dead-simple
17:06valoga: right I've experienced that
17:06imirkin: you can have 2 buffers, where you display 1 and draw to the other
17:06imirkin: and when you're done drawing, you flip
17:07imirkin: this is aka double-buffered rendering
17:07imirkin: or back-buffer rendering
17:07valoga: this is platform for game emulation so I'm mostly interested in least cost to the fast path (the thread posting the buffer to be drawn) and of course providing the best experience
17:07imirkin: the downside there is if you're trying to be careful about vblanks
17:07emersion: valoga: you might be interested in https://github.com/ascent12/drm_doc
17:07imirkin: and if you are, this is where triple-buffered rendering comes in
17:08imirkin: the more n-buffers, the more annoying it is to manage it all
17:08valoga: emersion: thank you for the link, I hadn't come across that yet
17:08valoga: ideally I would like to do away with the need for a separate thread
17:08imirkin: is this for MAME or something?
17:09valoga: imirkin: no, it's a basic emulator front end
17:09imirkin: most game emulation things already support drm interfaces
17:09valoga: I basically get callbacks with buffers to output
17:09imirkin: ah ok
17:09imirkin: oh, well then you can just do a page flip with the new buffer each time then
17:09imirkin: if it's being rendered into a fresh buffer each time
17:09imirkin: yeah, that's the simplest thing to do
17:10imirkin: don't worry about double-buffering or whatever
17:10valoga: it would appear rockchip (the graphics card maker) provides their own lib which I'm not using yet
17:10imirkin: most rendering APIs don't work like that btw
17:11valoga: I'd have to look through the code some more to understand if they might be doing any specifically beneficial
17:11valoga: right now I'm just using standard libdrm
17:11emersion: valoga: you shouldn't need to use vendor-specific APIs
17:11imirkin: also if you're using something like GL or Vulkan, then those come with winsys integrations
17:11imirkin: which handle all this stuff -- gbm is the thing that handles the drm integration stuff, i think
17:11valoga: emersion: I wonder why they provide it?
17:12emersion: valoga: the mesa driver uses the vendor-specific interfaces
17:13valoga: emersion: interesting considering that I have their proprietary mesa driver (egl, glesv2, etc..) installed but I don't even have their libdrm installed and mesa appears to work?
17:15valoga: I'll read that doc and go from there
17:15valoga: thanks for the input all
17:31valoga: read those docs but I guess the sections on hw acceleration and drmModeAtomics hasn't been written yet
17:34emersion: valoga: for that, you can read https://gitlab.freedesktop.org/daniels/kms-quads
17:35valoga: thank you
18:04HdkR: jekstrand: SAdly the GPU isn't recovering in my setup, so it never dumps the card0/error file
19:04HdkR: jekstrand: I updated to 5.6.11, will let you know if it fixes anything
19:05HdkR: Seemingly takes about half a day before it gets funky though
19:12sravn: danvet: Any reason why you did not kill the last few users of FBINFO_MISC_USEREVENT when you looked at fbdev stuff?
19:12sravn: Replacing the few users with an extra call to fbcon_update_vcs() after fb_set_var() looks like what is needed.
19:13sravn: Also FB_EVENT_MODE_CHANGE looks like one we could drop, but there may be implicit dependencies
19:19jekstrand: HdkR: Also, if you've been seeing funky hangs on old 5.6, I recommend running fsck.
19:19jekstrand: HdkR: You don't want to know why. Just run it. :D
19:20HdkR: I hate that being a fix on a fresh install on a fresh device
19:20imirkin: then don't run it, see where that gets you :p
19:20HdkR: Its wacky
19:30ickle: what are you going on about?
19:31HdkR: Unrecoverable Ice Lake hangs on the kernel version I was on
19:32ickle: I was more concerned by jekstrand
19:33HdkR: Oh right, the wacky fsck fix
19:54danvet: sravn, mostly because fbdev/fbcon is a horror show :-)
19:55danvet: sravn, note that MISC_USEREVENT is badly misnamed
19:55danvet: it should be called FBINFO_DONT_RECURSE
19:55danvet: since that's what it does
19:56danvet: this is to avoid fbcon->fbdev->fbcon lolz
19:56danvet: and the real reason why this is a problem is because fbdev/fbcon locking is bonkers
19:56danvet: it "works" if you use one or the other
19:56danvet: but not both
19:56danvet: fbcon uses console_lock
19:56danvet: fbdev the lock_fb_info (plus a few other things)
19:57danvet: so untangling this for real means rewriting the locking for fbdev vs fbcon
19:57danvet: I choose not to :-)
19:58danvet: sravn, but I guess as a small cleanup you could make this more explicit by pulling out the fbcon_update_vcs calls
19:58danvet: but I'm not sure whether I've found some locking issues with that which would make things worse than it is already
19:59danvet: HdkR, card0/error should be created before we try to recover
20:00danvet: pcercuei, old_plane_state->crtc
20:01HdkR: danvet: Interesting, I had checked that file but it was empty
20:01danvet: pcercuei, also this smells like you want simple display pipe helpers if the plane is fully tied to the crtc
20:01danvet: or at least require that they are only switched on/off together
20:01danvet: HdkR, then something went wrong somewhere
20:01HdkR: Sounds about right :)
20:12danvet: sravn, wrt FB_EVENT_MODE_CHANGED, look at fb_notifier_callback in lcd.c
20:12danvet: maybe we should make this an explicit switch so grep finds it
20:29sravn: danvet: I have typed something that drops MISC_USEREVENT, that I think is fine. Will massage into a patch and submit maybe tomorrow
20:30sravn: Thanks for the lcd.c hint, I also typed something so it is now listed to avoid fooling me another time
20:32sravn: As for locking, I am not at all prepared for messing with that. And the above was just a detoru because I accidently opened backlight.c...
22:35pcercuei: Is there a twist with adding a new drm_property? If I do so, modetest tells me "could not get plane 31 properties: Invalid argument"
22:41EdB: Hello, for those interseted, I've got a branch with clover mostly ready to advertise CL 1.2 : https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4974
22:43airlied: EdB: don't we need printf?
22:44airlied: though those all look useful!
22:46EdB: airlied: yes we need printf. However I made clover adverdise a printf buffer of size 0 so, we may remplace it by a stub :)
22:47pcercuei: ah. I guess I need to implement .atomic_get_property()
23:08EdB: mh :/ that was a long time ago, I forgot that FULL profile need at least 1M for printf
23:11pcercuei: airlied: I want to add a "scaling mode" (nearest-neighbour, bilinear, bicubic) and "sharpness" (bicubic alpha factor) to my plane. Is that something I should add to the DRM core instead?
23:24airlied: pcercuei: not an area I know, but yeah properties that might be useful elsewhere should be added to core
23:24pcercuei: the problem is knowing if it's useful elsewhere ;)
23:25pcercuei: I guess that question will be answered once I send the patches for review
23:47jekstrand: ickle, HdkR: We had a couple cases where it corrupted memory it very much shouldn't have.
23:47jekstrand: I don't know the details.
23:48jekstrand: In fairness to the i915 folks, this bug is the first time I've heard of that sort of thing happening in about 5 years and probably the first time I've heard of it happening in upstream ever.
23:48jekstrand: And, honestly, it may have had nothing to do with memory stomping. It may have been kernel threads dying at very bad times.
23:49jekstrand: But we did have at least one case where someone got burned by it pretty bad.