01:41 alyssa: mareko: seems to be worth 3% on glmark2 -bjellyfish on agx. oof.
02:43 Company: is there a way to wait on multiple GLsyncs?
02:44 Company: trying to port code that uses vkWaitForFences() and I'm wondering if there's an equivalent or if I need to track myself which of the fences is the oldest one
02:48 HdkR: Company: Commands are executed sequentially, to wait on multiple you can just wait on a "newer" one and it will ensure all the previous ones are done as well
02:48 Company: yeah
02:49 HdkR: Can't pick and choose like vkWaitForFences
02:49 Company: I just don't track which one is the newest one yet
02:49 gfxstrand: Or you can just wait on them all in sequence
02:49 gfxstrand: Not great but it works.
02:49 gfxstrand: There's no multi-wait if that's what you're asking
02:49 Company: I only want one to trigger
02:49 HdkR: If you also only care about the latest then just have some global atomic that you store to :P
02:50 Company: I'll just order my syncs myself
02:50 gfxstrand: Please don't roll your own timeline semaphores
02:50 Company: and then know which one to wait on
02:50 gfxstrand: Yeah, ordering them is a good idea
02:50 Company: just wanted to make sure I need to do the work
02:56 DemiMarie: @_oftc_randevouz:matrix.org:
03:39 DemiMarie: sorry, did not mean to post that message
03:40 dwfreed: fortunately IRC only saw you attempting to hilight them
04:44 tjaalton: gfxstrand: ah, thanks
05:31 airlied: Lynne: reproduced it, will try and get some time to debug it
06:13 Lynne: thanks
06:13 Lynne: it's possible it's an ffmpeg issue, as I can replicate it on nvidia
06:45 airlied: Lynne: ah yeah if nvidia screws up the same it could be, might be something like tchar was pondering being a problem
08:18 jfalempe: sima: I'm preparing a v10 for drm_panic, but before sending it, I need your opinion on https://lists.freedesktop.org/archives/dri-devel/2024-March/445115.html and https://lists.freedesktop.org/archives/dri-devel/2024-March/445346.html
08:21 sima: jfalempe, yeah sorry I was not up to date on m-l reading, will try to do that
08:22 jfalempe: sima: no problem, and thanks for helping me on this.
08:23 pq: grillo_0, if you or Louis happen to wonder why I'm not replying to VKMS/IGT discussions, I'm currently going through the new KMS color pipeline UAPI series, and I have limited time per day for KMS in general. UAPI and color spec stuff tend to take precedence for me.
08:27 javierm: jfalempe: did you agree with tzimmermann on the drm_fb_blit_from_r1() vs drm_pixmap in the format conversion helpers ?
08:27 javierm: sorry that I didn't take a look to those two series yet. I'll try to do it tomorrow that's when I've more time for reading the m-l
08:28 tzimmermann: javierm, these helpers will for now go into the panic code and we'll figure out something later
08:28 javierm: tzimmermann: Ok
08:28 javierm: tzimmermann: and makes sense, to move things forward
08:34 jfalempe: javierm, tzimmermann: yes I moved them back in drm_panic, that's the main change of the v10
08:35 javierm: jfalempe: cool
09:09 triggeredit: The results what i know from the past and today about my investigation done about abuse in my life, that americans like united states people, considered the power on earth are surprisingly enough not active in the abuse hitting the top of the ranks in the world, they did not manage to extend that conspiracy behind or over the ocean for some reason that is not known to me. I hypothesize that maybe they live too good for that and have better
09:09 triggeredit: ways to deal, generally this appears as a fact that they seem not to be a part of the abuse, even though they started to mark those antigen antbody systems and made the alien conferences initially. And on different years i have gotten the same result. One of the few areas the terror is not spreading to or extending to.
09:16 jani: airlied: sima: I was hoping for an ack from Masahiro on this one, but have gotten no reply. should I wait for the ack, or just merge it? https://lore.kernel.org/r/ba6527a126daeae8e66e1cd64053580645106612.1709898638.git.jani.nikula@intel.com
09:17 sima: jani, since we just missed the merge window I'd pester a bit more for an ack
09:17 sima: I guess you can still land all the prep work at least
09:18 jani: sima: the prep's all been merged
09:19 jani: maybe I'll resend that header test patch so it stands out
09:19 sima: yeah might help
09:19 sima: jani, also maybe wait until after -rc1, many maintainers tend to outright ignore patch submissions during the merge window
09:20 jani: sima: right. though I think that's just silly. to me the merge window is usually the quietest time of the entire release cycle!
09:22 sima: jani, only if you have a decent setup, what I'm still hearing from plumbers is that most maintainers are really stressed out during that time
09:24 jani: :/
09:25 jani: to me the stressful times are a) the last feature pull deadline, and b) when -rc1 hits drm-tip and things fall apart
10:38 tchar: Lynne: airlied: I don't see anything going wrong around frame 30 (which would imply the frame_id handling is going wrong imo)
10:38 tchar: instead I see the colors are a bit off until frame 81, like this: https://people.igalia.com/cturner/av1_test_ext.html
10:38 tchar: and then the tile data seems corrupted in frame 81 (even libaom complains about it and quits)
11:34 Lynne: tchar: this is what I get instead - https://0x0.st/HFqb.mp4
11:36 Lynne: bcheng: airlied: by the way - while making this sample, I managed to replicate the exact flickering problem I've had on navi3x, entirely in FFmpeg - https://files.lynne.ee/av1_decode_corruption_flicker.mp4
11:37 Lynne: ^and jkqxz
12:39 mripard: tzimmermann, sima: ack for https://lore.kernel.org/r/20240304091225.366325-1-mripard@kernel.org ?
12:40 tzimmermann: mripard: a-b: me
12:45 mripard: tzimmermann: thanks!
12:49 sima: mripard, ack but I guess you pushed already :-)
12:49 sima: mripard, I guess time to enable gitlab ci and figure out how to compile test on at least x86-64, arm64 and arm ...
12:49 mripard: yeah, it's been pushed already :)
12:50 sima: well first gitlab ci I guess and see what all falls apart, before we try clever tricks with generating kconfigs with max coverage automatically
13:08 mripard: sima: arm doesn't always catch those kind of errors, for some reason it didn't this time for example
13:08 mripard: archs like m68k always seem to catch them, but I'm not sure it's something we want to have
13:09 sima: hm 32bit x86 reliably catches 64bit divisions, or I thought so
13:10 sima: or has 32bit arm given up and just added the gcc intrinsics?
13:10 sima: *built-ins
13:12 mareko: alyssa: if alpha=1 allows you to disable blending, then you should get better perf with disabled blending unless your hw does that automatically
13:13 alyssa: mareko: I don't have blending hardware ;-)
13:23 tchar: Lynne: https://0x0.st/HFqb.mp4 matches what I see with aomdec
14:06 sima: jfalempe, do you want me to type up the irqsave/restore stuff or you'll do it? I think it's a good idea
14:07 sima: just means we need to add the irqflags as a return value to _lock and as a parameter to _unlock
14:10 sima: jfalempe, also re ogness questions: the issue is if an irq handler runs within drm_panic_lock section
14:10 sima: and then we die in there, so instead of just a handful of instructions in drm code, the critical section becomes the entire interrupt handling including bottom halves
14:11 sima: so _much_ more, and hence a good idea to use the irqsave/restore versions
14:15 jfalempe: sima: I can do the irqsave/restore change, I just didn't know if it was necessary to do so.
14:21 sima: jfalempe, btw did you see the discussion around kmsg_dumper? I really think that's the interface we should use instead of the panic notifier you're using in v9
14:21 sima: since that seems to be for arch/platform code to add additional information to dmesg before all the final dumping happens
14:21 sima: so it's a bit too early and will mean we dump incomplete data
14:22 jfalempe: sima: The problem with kmsg dumper is that you don't have the panic reason, you only get the tons of kernel logs, which I'm not interested in.
14:22 sima: jfalempe, why?
14:22 sima: like that's the stuff we should dump I thought ...
14:23 jfalempe: my vision is to have a simple message for users, and then put additionaly debug data through qr code.
14:24 jfalempe: for example if you want to have a correctly formated stack trace in the qr code, the kmsg dumper is not that good, because everything is already formatted through printk.
14:24 sima: jfalempe, so if you want the panic reason then I think the right way is to add that to kmsg_dump
14:25 sima: that is still not entirely the entire panic dmesg, but at that point it's no longer our problem
14:25 javierm: sima: but that still wouldn't get us the nice QR code that jfalempe wants to add, right ?
14:26 sima: jfalempe, the other issue with qr codes is that at least the standard ones contain way less information than what you can simply print as dmesg output on even just a hd screen resolution
14:26 sima: javierm, years ago when we discussed qr it sounded nice, but has some practical hurdles
14:26 jfalempe: sima, if you compress a bit you can put a lot of things in a qr code.
14:26 sima: you need a special qr decoder to pack enough stuff into it
14:26 sima: jfalempe, yeah but then you can't just decode the stuff with a smartphone because it's binary
14:27 jfalempe: it's a link to a website, so you can decode it there.
14:27 jfalempe: and open a bug with the right info attached.
14:27 sima: jfalempe, the other issue is that even if you do the qr code, the panic notifier is _still_ the wrong callback, since the qr code needs the kmsg_dump hook
14:28 pq: jfalempe, hopefully the actual data will not reach the web server before decoding and inspection? For privacy reasons.
14:28 sima: jfalempe, I'm confused, if you put a link into the qr code, how do you put the dmesg in there too?
14:28 jfalempe: sima: it's easier to get the stack trace, and hw info directly than parsing the kmsg dump
14:29 pq: so loading a web page with JavaScript to decode it is fine, if you can stop the data from going over internet.
14:29 sima: jfalempe, definitely don't parse dmesg, just dump it
14:29 sima: I'm confused ...
14:29 sima: like if drm panic has opinions about what to dump at panic times
14:30 sima: then we're in a bikeshed I'm not going to be in
14:30 sima: and if dmesg is not containing the right stuff, _that_ needs to be fixed
14:30 sima: not repainted in the drm panic code
14:31 sima: otherwise bugs filed with drm panic and bugs filed with e.g. pstore are completely different
14:31 sima: and might be the exact same bug
14:31 javierm: jfalempe: I agree with sima that as a first step just dumping the kernel log buffer content just as formatted by printk
14:31 javierm: then doing more fancy stuff could be a follow-up
14:31 jfalempe: ok, I just find dmesg too cluttered, and prefer to have a stack trace, and hw info separately
14:31 sima: yeah we could try to make sure the panic reason is retained as the first line, just in case
14:32 sima: although usually that doesn't contain much useful stuff if all the other things have scrolled away due to lack of resolution
14:32 sima: very often the dmesg line right before the panic is the real hint for what's gone wrong
14:32 sima: or the backtrace/register state afterwards
14:33 sima: I don't think I ever took the panic reason into account really beyond "it's dead"
14:33 jfalempe: yes it's not that usefull, but it's short, and won't confuse users I think.
14:33 sima: so what I think we want is to dump dmesg, and then try to dump as much as possible of that
14:33 sima: jfalempe, yeah but it's also no use in practice
14:34 happiestguy: i think still you could find a way to make smartphone decode capable qr codes, technically possible to do with bluetooth too, i know you say qr codes are camera based, but send the stream over bluetooth if needed, theres not such phone lacking bluetooth.
14:34 javierm: jfalempe: usually users either can parse the output of just upload a picture for others to make sense of it :)
14:34 javierm: *or just
14:35 jfalempe: sima: ok I will change that to kmsg_dump if that the standard way to raise bugs, that makes sense
14:35 sima: jfalempe, maybe I'm still missing the goal you have perhaps, but yeah for now I'd just dump as much of the bottom end of dmesg as you can from a kmsg_dump hook that only runs for panics
14:36 sima: since that's also what pstore and the other panic dumpers use that try to make the panic debug info available somewhere else than a kernel console
14:36 sima: so if it's the wrong thing, it should at least be consistently wrong like all the others
14:37 sima: iirc john ogness talked about reworking that entire flow that no matter whether it's a kmsg_dumper or the new kernel console with the safe locking (with a fixed serial driver or something like that), you should get the same dmesg output
14:37 jfalempe: at least you can compare it with other panic reports. we may revisit when drm_panic will be ubiquitous.
14:38 sima: jfalempe, kmsg_dump would also give us the option of dumping an oops
14:38 javierm: sima: the goal AFAIU was to mimic what others OS do like Windows: https://www.zdnet.com/article/windows-10-blue-screen-of-death-now-microsoft-adds-qr-codes-to-bsod-crash-support/
14:38 sima: which does destroy the output buffer state in cases where userspace still continues to run, but sometimes the kernel is already too dead to actually debug what's going on
14:38 javierm: but agree that as a first step just dumping the dmesg log makes sense
14:39 sima: javierm, that's not the same kind of info in the qr code as we discussed in the past for linux
14:39 sima: for linux the real debug info is the dmesg, and there's no convenient database to map that to something more meaningful really
14:39 jfalempe: sima: yes but usually with oops you can still use the graphics, if we repaint the screen it might filcker and not be that useful ?
14:39 sima: the panic reason is definitely not comparable
14:40 sima: jfalempe, yeah, therefore only as an option
14:40 sima: for debugging
14:40 demarchi: tursulin: do you want to take a look at https://patchwork.freedesktop.org/series/131049/ ?
14:41 tursulin: demarchi: not particularly if you already have reviews you can add my ack if you want and if I haven't provided it already
14:42 demarchi: tursulin: thanks.... still waiting for review in a couple of patches from rev2
14:43 demarchi: also retriggered CI as it apparently has some unrelated failures
14:43 tursulin: demarchi: maybe ask dolphin to be sure, afair he was reluctant to ack my version back in October
14:43 demarchi: dolphin: ^ :)
14:44 pepp: digetx: Ack on https://lore.kernel.org/all/20240128191218.392061-1-dmitry.osipenko@collabora.com/
14:46 mripard: vsyrjala: any chance you could review https://lore.kernel.org/dri-devel/20240311-kms-hdmi-connector-state-v9-14-d45890323344@kernel.org/ and https://lore.kernel.org/dri-devel/20240311-kms-hdmi-connector-state-v9-20-d45890323344@kernel.org/ to make sure it's consistent with i915?
14:48 digetx: pepp: thanks! though virtio-comment ML isn't related to this channel, hoped you could reply to the email :)
14:49 sima: jfalempe, javierm so adding the panic reason as the very first line to make sure it's not scrolled away does sound like a good idea after a bit of digging around
14:49 sima: but I think the way to do that is by adding it to kmsg_dumper, so that we can do both in one go
14:49 jfalempe: sima, one of the useful panic reason, is when it fails to mount / because you messed up your drive/ramdisk.
14:50 sima: yeah there's some that are good info, but usually the screen should be big enough that you still see that line
14:50 sima: infuriatingly the last line in dmesg repeats the panic reason, but that's printed _after_ kmsg_dump
14:50 sima: so maybe the right fix is to move kmsg_dump further down
14:51 jfalempe: also qr code in window's BSOD doesn't contain any debug info. it's just a static link to their support website.
14:51 sima: yeah already replied to javierm that this isn't really what we want
14:52 sima: jfalempe, I think it has enough to include the error reason, but windows has an actual list and not just a string that people randomly decide on when they merge another panic() call
14:52 javierm: sima: panic reason just before kmsg_dump makes sense regardless indeed, since that's useful for serial too
14:52 sima: javierm, yeah ...
14:54 sima: javierm, the entire panic code after kmsg_dump(PANIC) is very much yolo anyway ...
14:54 javierm: yeah
14:55 jfalempe: sima: an example of qr code link, I used for a demo: https://kdj0c.gitlab.io/panic_report?reason=Kernel+Panic+from+debugfs&bt=dbg_fs_read+0x15/0x20,full_proxy_read+0x5c/0xb0
14:56 jfalempe: so on the website, you get the different parameters, you don't need to parse the kdump format.
14:57 sima: I want full dmesg, as much of it as possible
14:57 sima: I have a few times actually decode the instruction dumps and things like that ...
14:58 jfalempe: yes, I agree, if that's the standard, let's use that.
14:59 jfalempe: Also there was an attempt at panic qrcode 10y ago https://lkml.org/lkml/2014/3/17/525
14:59 karolherbst: does anybody have patches to share for basic HDMI 2.1 support in drm? Like... edid parsing and everything which doesn't require the approval of the HDMI dudes?
14:59 javierm: jfalempe: there are also tools like ./scripts/decode_stacktrace.sh that people use
14:59 javierm: which a picture would be harder but I guess there are ocr command line tools to get the text
15:00 jfalempe: yes that's why I prefer qrcode, than fbcon dmesg output.
15:01 sima: jfalempe, like on really low-res screens it's quite likely that the top part of the panic output won't show up, but not really anything we can do for that :-/
15:02 sima: javierm, all the various tools is why we should get out unchanged dmesg
15:02 sima: whether that's screen or qr code or whatever
15:02 jfalempe: fbcon panic dump on 4K display, is not that easy to read either.
15:02 javierm: sima: yeah, agreed
15:02 sima: jfalempe, you can set a bigger font, but at least it's all there
15:02 javierm: jfalempe: or take a picture and zoom in :)
15:03 jfalempe: javierm: ;)
17:42 zmike:sits down to fix more cts tests
17:52 agd5f: karolherbst, you need the HDMI spec for most of that
17:53 karolherbst: why though?
17:53 jessica_24: hey @pq, did you get a chance to check the latest revision of the solid fill IGT tests (https://patchwork.freedesktop.org/series/127900/)? just wanna make sure I addressed all your comments
17:53 agd5f: karolherbst, it's part of the spec
17:53 karolherbst: well.. what if I check what a different open source driver is doing instead?
17:55 karolherbst: like.. the edid-decode thing actually decodes all the relevant FRL bits, and nvidias open driver also does HDMI 2.1
17:56 karolherbst: so I don't see a reason why we'd need to read the spec for anything (or ask for permission)
18:06 DemiMarie: karolherbst: reverse engineering time?
18:06 DemiMarie: just because the HDMI 2.1 spec isn’t available doesn’t mean that you can’t figure out how it works
18:06 karolherbst: there is nothing to reverse engineer?
18:06 karolherbst: I just check how other open source drivers supporting HDMI 2.1 do it?
18:07 karolherbst: but the point is really just if any work we'd need in drm core has been done and if people have patches for it
18:07 karolherbst: of course there will be bits which you might the spec for, but I specifically asked for the ones you don't
18:13 zmike: mareko: almost done fixing all these tests your opt pass broke
18:22 DemiMarie: agd5f: is there any part of HDMI 2.1 that userspace needs to care about?
18:23 DemiMarie: agd5f: what about just only shipping DisplayPort and expecting the OEM to provide an adapter if they care about HDMI?
18:27 DemiMarie: karolherbst: I hope there is enough to get the uAPI right, because otherwise there are serious problems 😢.
18:28 karolherbst: there are no uapi relevant bits
18:28 karolherbst: why would userspace even care?
18:38 zamundaaa[m]: Userspace might care about the auto low latency thing
18:39 zamundaaa[m]: But personally all I want with it is to have it always be enabled
18:39 DemiMarie: karolherbst: I thought EDID is parsed in userspace/
18:40 zamundaaa[m]: Demi: userspace always gets the full edid, there's no specifics that would be part of uAPI
18:40 DemiMarie: zamundaaa: I see
18:40 karolherbst: zamundaaa[m]: heh... I wonder if there are any drawbacks...
18:41 karolherbst: but for now, I just want users to allow using 4K@120 modes :D
18:42 zamundaaa[m]: karolherbst: it'll disable some processing on the TV side. For me that's a plus, but I could imagine some users wanting that processing to happen for video playback
18:42 karolherbst: yeah fair..
18:42 karolherbst: but it would be a new drm property or something, right?
18:43 karolherbst: nothing we really need knowledge from the HDMI spec
18:43 zamundaaa[m]: Yeah
18:44 karolherbst: for us (nouveau/nvidia) all the link training is done in firmware, so I don't really see what I need to know besides "this is the FRL the link supports" and "I want this FRL speed to be set and do please link train and give me the result" :D
18:45 DemiMarie: karolherbst: would it be feasible to implement native context support for Nouveau?
18:52 agd5f: I don't know that I can really say much without exposing details of the spec
18:54 airlied: karolherbst: yeah just go ahead and make it work, intel only enables it via lspcon chips, so should be similiar enough to what nouveau needs
18:54 airlied: but nouveau needs a lot of work in that area afaik
18:54 airlied: since I don't think it handles bpp yuv/rgb etc stuff properly at all
18:55 karolherbst: yeah.. probably it doesn't :D
18:55 airlied: so for nouveau it add a bunch of display handling that doesn't exist first afaik
19:00 karolherbst: yeah.. though for now I just want to know if I can get the faster links working and to drive higher refresh rates
19:49 Lynne: tchar: airlied: I think the sample is corrupted
19:50 mareko: zmike: nir_opt_varyings - dEQP tests?
19:50 zmike: yes
19:50 zmike: just fixed the last one
19:50 mareko: amazing
19:51 zmike: have to remember what to do with kc-cts patches...
19:56 zmike: hmm I thought I got them all but I think I missed a couple
20:23 zmike: mareko: CLs on https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/4942
20:23 zmike: seems to all be passing now
21:48 tleydxdy: what's stopping people from making a LDMI that just happens to be compatible with HDMI? is it only patents?
22:57 mareko: eric_engestrom: why did you change deqp caselists to "{}/android/cts/main/{}-main.txt" when deqp lacks those files?