09:18 MrCooper: macc24: I read somewhere that even Nvidia will stop supporting generic SLI (with the generation after Ampere?); multi-GPU support will be all up to the applications, which should work with Mesa
09:19 MrCooper: bnieuwenhuizen: please don't do such ugly workarounds in WSI; non-vsync swapchains are useful with Wayland as well (e.g. for lower input→output latency)
09:38 mripard: airlied: danvet_: we have a few leftovers in drm-misc-next-fixes, should I just merge drm-misc-next-fixes into drm-misc-fixes and send you that PR later during the week, or would you prefer a final drm-misc-next-fixes PR today?
09:48 danvet_: mripard, I think just merging it into the weekly -fixes is fine
09:48 danvet_: that also makes dim push -next to linux-next again
09:53 danvet_: mripard, [PATCH] drm/v3d: Fix double free in v3d_submit_cl_ioctl()
09:53 danvet_: from Dan
09:53 danvet_: fell through the cracks apparantly
09:53 danvet_: while you're working -fixes :-)
09:53 DPA: danvet_: Judgeing from your reply to a reply of v1 of my patch, are you not getting the mails I send to the list?
09:55 danvet_: DPA, I need more context
09:55 danvet_: like maybe archive link
09:56 DPA: danvet_: https://lore.kernel.org/dri-devel/CAKMK7uEX38yzJGy6PWBs-L375kUGAPQK7SMPjT8Ze+3oKk38Mg@mail.gmail.com/T/#t
09:58 danvet_: DPA, I only commented on this because vsyrjala found out that we have a general mess around modifier support in display drivers
09:59 danvet_: DPA, did you expect something else?
10:00 danvet_: DPA, you're patch hasn't shown up yet, but might just be stuck somewhere still, dunno
10:00 danvet_: shown up here I mean
10:03 DPA: danvet_: I see. I don't think it will. I'll have to ask the mailman@lists.freedesktop.org to enable dmarc from header mungeing, I think that's the problem.
10:03 emersion: what do you mean by "enable dmarc from header mungeing"?
10:04 danvet_: yeah if you're dkim/dmarc is set up correctly, it should allow mailing list
10:04 danvet_: if not, and you can't change that, then you need a different mail provider like gmail
10:05 danvet_: sravn, just realized that it's better to update the kerneldoc example in the core constify patch
10:05 danvet_: so I'll do that there, ok?
10:08 emersion: > if you're dkim/dmarc is set up correctly, it should allow mailing list
10:08 emersion: not quite
10:08 DPA: danvet_: How is that supposed to work? The mailing list changes the message body, and since DMARC requires SPF Alignment, I can't make that match either. So the DMARC check is bound to fail.
10:08 DPA: Or will the list allow me to set the From: header to the list and put my mail into the reply to to header myself?
10:08 emersion: because lists.freedesktop.org mutates the emails
10:08 emersion: adding a footer for instance
10:08 emersion: DPA: DMARC doesn't require SPF alignment
10:08 emersion: it requires either SPF or DKIM
10:09 emersion: and with the current lists.fdo behaviour neither can work
10:09 danvet_: yeah there's a magic way to set this up and get through mailing list
10:09 danvet_: and a lot of other recommended ways which don't work
10:10 danvet_: I forgot the details, but ffwll.ch works
10:10 emersion: my recommendation is to stop mutating emails like lists.sr.ht, but there were concerns about unsubscribing, even though the standard List-Unsubscribe header is there
10:10 emersion: danvet_: Authentication-Results: mailin006.protonmail.ch; dmarc=none (p=none dis=none)
10:11 emersion: header.from=ffwll.ch
10:11 emersion: danvet_: anybody can send an email from ffwll.ch with this DMARC policy
10:12 DPA: emersion: With enableing dmarc from header mungeing, I mean what is described here, see munge_from: https://mailman.readthedocs.io/en/release-3.1/src/mailman/handlers/docs/dmarc-mitigations.html
10:12 emersion: oh please don't mungle From ;_;
10:13 danvet_: emersion, well I set up something and gmail is happy now
10:13 danvet_: email is broken anyway
10:13 emersion: danvet_: and i can'
10:13 emersion: t trust your emails
10:13 emersion: > email is broken anyway
10:13 danvet_: you shouldn't
10:13 danvet_: yeah
10:13 emersion: just because you break it doesn't mean it's broken
10:14 emersion: anyways, if you really want to keep the silly footer, the "official" fix is https://tools.ietf.org/html/rfc8617
10:15 emersion: * requires the receiving server to trust lists.fdo
10:15 DPA: emersion: It's only for dmarc users. And I won't disable DMARC, I have DMARC reports showing that spoofing my mail address has been attempted at least once already.
10:15 danvet_: yeah at that point you're down to mailer reputation
10:16 emersion: DPA: yes i agree disabling DMARC like danvet_ does is not a good idea
10:16 emersion: i don't have DMARC disabled either
10:16 emersion: but mungling From is really bad UX
10:16 emersion: google groups does it and it's terrible
10:18 DPA: I've already got used to it.
10:18 emersion: you mean, "my email client doesn't show the correct sender anymore and i'm fine with that"?
10:19 emersion: also, "regular email operations like Reply vs. Reply-All don't work anymore"
10:21 DPA: My mail client can "Reply to list -> all". And yes, I'm fine with that.
10:22 emersion: this breaks email semantics badly
10:22 danvet_: ok I read this crap again
10:22 emersion: this is just a workaround, and there's a real proper solution available
10:24 danvet_: I have dkim, that helps with getting mails accepted
10:24 danvet_: and everything else maximally relaxed, so it gets in
10:24 danvet_: because I need my mails to arrive
10:26 emersion: well. maybe you don't care about email spoofing, but other people may care
10:26 emersion: and recommend them to not care to post to the ML isn't great
10:27 danvet_: have one domain for patch bombing
10:27 danvet_: another one for stuff where you maximally lock down your mailer because business
10:27 DPA: At least this the mailing list doesn't seam to reencode everything in base64.
10:27 DPA: Maybe I can get away with revisiting my effort of specifying the count of to be verified bytes of the message in DKIM for certain emails again this time around.
10:28 emersion: DPA: some receiving servers have a policy to reject DKIM signatures with a bh= param
10:28 emersion: because it's inherently insecure
10:29 emersion: danvet_: so the ML is broken, and each ML user needs to fix their setup to work around it?
10:30 emersion: s/bh/l/
10:30 emersion: DPA: https://tools.ietf.org/html/rfc6376#section-8.2
10:31 danvet_: emersion, I guess you can volunteer to admin a massive mail amplifier, dunno
10:31 pq: bnieuwenhuizen, https://gitlab.freedesktop.org/xorg/app/xisxwayland/
10:32 danvet_: real fix is going to be gitlab for patches and most discussions
10:33 emersion: :(
10:33 DPA: emersion: Is google or MS doing the reject l= thing? If it's only some small unimportant mail server operators, I may just ignore them.
10:33 danvet_: it's fairly regular that we mass-unsubscribe domains because some mailers have a fight over what they're ok with again
10:34 emersion: DPA: i haven't tested google/ms
10:34 emersion: in my software, i just reject l=
10:34 emersion: daniels: is there a way i could help getting ARC setup for the ML? https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/arc_sign.html
10:35 emersion: err, we're still on mailman 2…
10:35 danvet_: emersion, yeah you'd volunteer to run this show
10:36 emersion: yak shaving involves https://docs.mailman3.org/en/latest/migration.html
10:37 DPA: emersion: Why? Isn't the l= covered by the dmarc signature? I mean, it boils down to a disable dmarc/dkim for this mail feature. Are you blocking non-dmarc signed mails too?
10:37 daniels: yeah, especially the archives having to be split was pretty awesome
10:39 DPA: s/dmarc/dkim/
10:39 daniels: if someone else who loves email more than I do wants to take over, I'd be all for it
10:40 emersion: DPA: https://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html#hdr2.2
10:40 mripard: danvet_: done (for the v3d fix)
10:41 emersion: DPA: i consider DKIM with l= to be as good as no DKIM signature
10:45 emersion: daniels: actually we can do ARC without upgrading mailman
10:46 emersion: just needs to be done in the MTA instead of mailman itself
10:46 DPA: emersion: It shouldn't be as much of a problem for non-multipart messages, with the l= covering all of the pre-existing message including the headers though, right?
10:48 emersion: DPA: again, it depends. if Content-Type is not signed or signed only once, can overwrite it with a multipart one and overwrite the whole body
10:48 emersion: also, if it's HTML, then there are all sort of things you could do
10:49 emersion: so in the special case of "Content-Type signed properly and text/plain body", you can only append untrusted text
10:49 emersion: but you can still append bad stuff
10:50 emersion: there are so many special cases and footguns that rejecting l= outright is less dangerous
10:53 mripard: danvet_: there's a scary (to me) merge conflict in drivers/gpu/drm/i915/gem/i915_gem_pages.c, who should I ping?
10:55 danvet_: mripard, due to the backmerge?
10:56 danvet_: there shouldn't really be anything new, the dma-api rework conflict I think airlied should already have solved
10:56 danvet_: so imo look at the current drm-tip and try to match your resolution
10:56 danvet_: it probably just moved around a bit between merge points and context
10:56 ickle: vmalloc interfaces have been changed
10:56 danvet_: otherwise ping ickle here
10:56 danvet_: oh I bet on dma-api without looking :-)
10:56 mripard: there's some stuff that went through torvalds' tree directly apparently
10:57 danvet_: yeah hch is busy
10:57 danvet_: and banned on fd.o :-)
11:00 DPA: I guess I'll just order a new domain, specifically for sending mails to such MLs, for now.
11:03 emersion: you can also use a sub-domain
11:04 emersion: name it email-is-broken.<existing domain> :P
11:08 DPA: emersion: My DMARC is strict and thus applies to all my subdomains. I don't think it's possible to set a different policy for a specific subdomain.
11:10 emersion: DPA: you can use the sp= tag to change a subdomain policy
11:10 emersion: eh, maybe not
11:11 emersion: DPA: ok, yeah, you can override the DMARC policy per subdomain
11:11 MrCooper: danvet_: FWIW, hch is only banned on the dri-devel list (and maybe others), he can still post e.g. to the amd-gfx list; TBH I suspect the dri-devel ban is an overall loss at this point
11:12 bnieuwenhuizen: MrCooper: I got the impression from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7033#note_652386 that Wayland (and hence by extension XWayland) doesn't really support IMMEDIATE semantics, only FIFO and MAILBOX?
11:12 DPA: Oh, cool, I didn't know that. This makes everything much easier.
11:12 bnieuwenhuizen: I thought it would be worth either stop claiming support for IMMEDIATE or switching the implementation to MAILBOX if we find wayland in the mix?
11:13 emersion: bnieuwenhuizen: yeah, that sounds correct…
11:15 danvet_: MrCooper, hm I thought it was just fd.o
11:15 danvet_: daniels, ^^
11:15 danvet_: MrCooper, I mostly get them because I get cc'ed
11:15 MrCooper: bnieuwenhuizen: IMMEDIATE with Xwayland ends up more or less as what MAILBOX should be. IIRC MAILBOX itself currently works differently though; if that was changed to always submit frames to Xwayland instead of doing the mailbox behaviour on the client side, then dropping IMMEDIATE might make sense
11:16 bnieuwenhuizen: MrCooper: client side = app?
11:16 MrCooper: Mesa WSI
11:16 bnieuwenhuizen: k
11:16 bnieuwenhuizen: that never dropped frames IIRC
11:17 bnieuwenhuizen: So reason why going for the MAILBOX impl might make sense: we wait for rendering to finish in the app (async thread) as otherwise that gets less than ideal results in the X11 server
11:17 bnieuwenhuizen: like with all the queueing for flip even before we know for sure that frame is going to be ready etc.
11:17 bnieuwenhuizen: with implicit sync
11:17 bnieuwenhuizen: and you get the 5 images in the WSI :P
11:21 MrCooper: how does MAILBOX set the target MSC?
11:22 bnieuwenhuizen: 0
11:22 bnieuwenhuizen: but without XCB_PRESENT_OPTION_ASYNC (compared to IMMEDIATE)
11:24 MrCooper: right, that's a problem
11:25 MrCooper: it means Xwayland picks the first available buffer, then waits for the Wayland frame callback
11:25 MrCooper: not really mailbox
11:25 bnieuwenhuizen: yeah ...
11:26 bnieuwenhuizen: at least by waiting on the WSI side we got the first available buffer correct wrt implicit sync
11:26 bnieuwenhuizen: but you still get 1 frame of latency due to queueing in KMS at least
11:26 MrCooper: right, though I'd argue that's really the Wayland compositor's job :)
11:27 bnieuwenhuizen: I honestly think we should just move to explicit sync and make that separation clear :)
11:27 MrCooper: wait, actually since MSC has always passed already, Xwayland might be doing the right thing
11:28 MrCooper: MSC 0
11:28 bnieuwenhuizen: well, it is still eager and you can't override a flip that is already queued in KMS
11:28 bnieuwenhuizen: so you are still losing that frame of latency
11:28 MrCooper: that's definitely the Wayland compositor's job
11:29 MrCooper: should be possible to get much lower
11:29 bnieuwenhuizen: sure
11:30 bnieuwenhuizen: well for Xwayland to be doing the right thing it should also send over a next frame before the frame callback for the previous one is received no?
11:31 bnieuwenhuizen: otherwise the wayland compositor never gets the chance to schedule a newer image to the flip
11:32 MrCooper: I just confirmed MSC 0 without XCB_PRESENT_OPTION_ASYNC doesn't work as intended for MAILBOX (with Xwayland; it's probably the best you can do with Xorg, without tearing)
11:32 MrCooper: right, exactly
11:33 ickle: mripard: should be resolved
11:34 mripard: ickle: awesome, thanks!
11:34 MrCooper: bnieuwenhuizen: bottom line, dropping IMMEDIATE for Xwayland might make sense if MAILBOX sets XCB_PRESENT_OPTION_ASYNC instead
11:35 bnieuwenhuizen: why ASYNC?
11:35 MrCooper: that's what allows frames to be sent independently from frame callbacks
11:35 bnieuwenhuizen: I thought that results in tearing for non Xwayland which is not what we want
11:36 MrCooper: right, only for Xwayland
11:36 bnieuwenhuizen: or I guess we just have differences in mailbox between xwayland and normal X
12:08 tzimmermann: danvet_, your comment on leaking the fb address was not meant to be fixed in the patchset (?)
12:12 danvet_: tzimmermann, which patch set?
12:14 tzimmermann: danvet_, i mean the discussion at https://patchwork.freedesktop.org/patch/395923/?series=80038&rev=6
12:16 danvet_: tzimmermann, I think if you don't you can blow up
12:16 danvet_: and it's a tiny change, just add && map.is_iomem to the condition
12:16 tzimmermann: well, ok then
12:17 danvet_: one annoyance is also that fb core uses that for it's own mmap
12:17 danvet_: but I think for generic fbdev emulation we always go through the gem mmap function
12:21 danvet_: tzimmermann, I guess strictly speaking it's fallout from using fbdev helpers for iomem in general
12:21 danvet_: but since your patch set is fixing that fallout, imo should be included
12:21 danvet_: if you want split it out into a separate patch, but imo not needed
12:22 tzimmermann: i see when i find time
12:22 tzimmermann: it's no big deal
12:49 haasn: How surprised should I be that eglExportDMABUFImageQueryMESA is returning DRMDRM_FORMAT_MOD_INVALID as the modifiers?
12:49 haasn: I'd have expected DRM_FORMAT_MOD_NONE or something like that
12:50 haasn: (this being on amdgpu)
12:52 bnieuwenhuizen: haasn: not surprised at all
12:52 haasn: So should I treat that function returning _INVALID and _NONE as equivalent (i.e. no modifiers needed)?
12:53 bnieuwenhuizen: well, ONE has this issue that it is aliased with _LINEAR
12:53 bnieuwenhuizen: NONE*
12:53 bnieuwenhuizen: so better treat _NONE as a mistake that nobody will use, and treat its value as _LINEAR
12:55 haasn: ah
12:55 haasn: good point
12:55 haasn: I somehow missed that
12:55 bnieuwenhuizen: we should probably add some documentation about that in drm_fourcc.h ...
13:10 emersion:writes patch
13:14 pq: I didn't even realize DRM_FORMAT_MOD_NONE was actually defined.
13:14 emersion: it's even in the list of vendors ><
13:17 pq: there are three uses of it in the kernel, too
13:17 pq: all in vc4 driver
13:17 emersion: haasn: https://lists.freedesktop.org/archives/dri-devel/2020-October/284158.html
14:18 zmike: anyone have any tips for forcing a DEVICE_LOST error during a shader?
14:18 zmike: nir is too good at optimizing out all my infinite loops
14:22 bnieuwenhuizen: zmike: something stupid like finding the second even prime?
14:25 bnieuwenhuizen: probably just even taking the sum from 1 to INT_MAX-1 is enough to not be optimized
14:25 bnieuwenhuizen: just make sure you output the result somewhere?
14:26 zmike: ah, that's a good one
14:26 zmike: thanks bnieuwenhuizen
14:41 jekstrand: zmike: "for (uint i = 0; i < 10; i += u_zero)" where u_zero is a uniform that conatins zero.
14:42 jekstrand: And do something in the loop you use
14:44 zmike: hm will try this, a 32bit int summation wasn't succeeding at failing
14:45 zmike: are int64 types explicitly prohibited as loop iterators? I've been trying to find that in a glsl spec, but it just says they're "fully supported"
14:45 jekstrand: zmike: Why are you trying to force DEVICE_LOST?
14:45 zmike: to test the callback for resetting the device
14:45 jekstrand: zmike: They should be supported.
14:45 zmike: jekstrand: they crash atm
14:45 zmike: in loop_analysis.cpp
14:46 zmike: the first check is for 32bit ints and then assumes that if that fails it must be a float/double
14:46 jekstrand: zmike: That's not good. Also, not surprising.
14:46 karolherbst: jekstrand: btw, I found a bug inside lower_cl_images_to_tex: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7241/diffs?commit_id=c388a9f744b94330208e4ad26367924a507c93b0
14:46 zmike: then later int64/uint64 is just missing from the switch
14:46 jekstrand: zmike: Crashing in GLSL IR or NIR?
14:46 zmike: I can add this
14:46 karolherbst: and I think array coordinates are still broken
14:46 zmike: glsl
14:46 zmike: I just wasn't able to find the spec saying one way or the other
14:47 jekstrand: karolherbst: rb
14:47 karolherbst: array indices have to be integers, right?
14:48 jekstrand: karolherbst: Yes
14:48 karolherbst: right.. that might give a hint why float coords are broken with array images
14:48 jekstrand: karolherbst: I wouldn't be surprised if sample() on an array with integer coordinates is broken. :)
14:48 jekstrand: Because we have to convert all but the last one to float and add 0.5.
14:48 karolherbst: ahh, right
14:48 karolherbst: I remember this part
14:48 karolherbst: will take a look later
14:50 karolherbst: jekstrand: anyway, testing with the CTS I am now confident enough to say that the broken luxmark rendering isn't caused by broken image support :)
14:50 karolherbst: I just suspect we still have a bunch of random issues
14:50 karolherbst: or just CL precision problems
14:50 jekstrand: karolherbst: Yeah. Did you see my two memcpy fixes over the weekend? :-)
14:51 jekstrand: karolherbst: I wouldn't at all be surprised if you're hitting one of those.
14:51 karolherbst: yeah, didn't try them out
14:51 karolherbst: but yeah
14:51 karolherbst: they could help
14:51 karolherbst: I also added that struct size thing, but that didn't change a thing
14:51 zmike: jekstrand: that loop also manages to not lose the device :/
14:51 zmike: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7316 for 64bit iterator fix
14:52 karolherbst: all images tests are passing now, except a few ones crashing because I don't properly support 8 bit in nouveau
14:52 karolherbst: but yeah, overall it's working now
14:54 jekstrand: karolherbst: Woo!
14:54 karolherbst: mh, though, samplerless reads are a bit broken, and I am not sure why yet
14:55 karolherbst: but I think the CTS just complains that stuff is a bit different
14:55 karolherbst: comparing to samplerful reads
14:55 karolherbst: oh well.. 1.2 features anyway
15:09 karolherbst: ehh.. okay, seems like my kernel traps with the samplerless reads tests.. uff
15:14 karolherbst: ahh nice, apitrace broke for big endian between 7.1 and 8.0
15:27 danvet_: tzimmermann, so what's the verdict, should I split the constification patch up per-driver?
15:39 daniels: danvet_: hmm I thought it was all of fd.o too - I remember editing Postfix rules - but I can't see it atm
15:42 sravn: danvet_: add const to the example in another patch is fine
15:43 karolherbst: :/
15:44 sravn: danvet_, tzimmermann - personally I prefer that the patch just goes in drm-misc-next ad mripard (and I) already acked it. Then it is done and we can move forward from there. It is not like the patch breaks the workd, it only makes it harder to mis-use the drm infrastructure
15:44 karolherbst: snappy broke be :/
15:47 daniels: emersion: cool that we can do ARC in the MTA. :) tbh our Postfix setup hasn't been meaningfully changed or brought up to date since ... about 2007? I think the only things since then have been setting up TLS and splitting @x.org out as a very separate namespace
15:47 emersion: yeah, i can understand that
15:50 kubast2: Is there some kind of enivormental variable
15:50 kubast2: to set a custom llvmpipe vendor id
15:51 kubast2: I have an application which wants to know the vendor id of llvmpipe and read out 0000 and shutsdown shortly after
15:56 pepp: kubast2: maybe try force_gl_vendor ?
16:08 tzimmermann: danvet_, i do backports of drm patches and some like this give me nightmares. but OTOH, maybe just commit what you have
16:11 danvet_: tzimmermann, I dont think you should backport this one
16:12 danvet_: I've looked carefully, but with stuff like amdgpu mangling drm_driver I might have missed something
16:12 zmike: jekstrand: any other ideas for triggering a DEVICE_LOST from a shader test?
16:13 danvet_: tzimmermann, or do you stuff like only backport a specific driver, not anything else?
16:16 tzimmermann: danvet_, it depends
16:16 tzimmermann: but go ahead and merge it
16:24 AI6K: Is there a channel specific to playing around w/ Vulkan on the Raspberry Pi? Or is the best way to take a look at the demo code in the Git repo?
16:30 nroberts: AI6K: you could try #videocore. the vulkan pi driver devs are in there
16:30 pepp: daniels: hi! do you think you could take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5096 (EGL_EXT_protected_surface) this week?
16:35 AI6K: Maybe I need to take a step back and ask a more pertinent question. I want to start learning about creating simple demos, maybe like you used to see from the Demoscene a few decades ago, like Second Reality, but on the Raspberry Pi. My apologies for spamming this channel.
16:42 jekstrand: zmike: Is infinite looping not working for you?
16:45 AndrewR: karolherbst, so, you nearly fixed it all (OpenCL images on nvc0) :} Thanks a lot
16:47 zmike: jekstrand: doesn't seem to be, no
16:48 jekstrand: :-/
16:51 anholt: AI6K: there shouldn't really be anything raspberry pi specific for that, assuming you're on a pi4 and can build Mesa yourself (I don't know that raspbian ships the driver yet)
16:58 seanpaul: emersion: did you manage to get vrr working on amd?
17:04 emersion: seanpaul: yes!
17:04 emersion: seanpaul: i used https://github.com/emersion/drm_monitor to make sure the timings change appropriately
17:05 seanpaul: emersion: ah cool, thanks for confirming! had a couple questions internally here about vrr support and saw some emails from you about it :)
17:05 emersion: it's also implemented in sway (and released in sway 1.5)
17:06 emersion: yeah, VRR can be tricky, especially how to handle flickering screens
17:07 seanpaul: awesome, sounds like there's fun ahead then
17:15 emersion: the current status is that we (user-space) expect kernel drivers to handle this
17:15 emersion: by implementing a slew rate for refresh rate changes
17:15 emersion: but we still get flickering screens, at least on amdgpu
17:15 emersion: (note, just with *some* screens, not all)
17:15 emersion: (mine works fine for instance)
18:02 kreyren: I found this IRC on https://docs.mesa3d.org/lists.html is this a good place to get more relevant informations to https://gitlab.freedesktop.org/mesa/mesa/-/issues/3694 because i am impatient and trying to fix it myself?~
18:04 kreyren: currently trying to figure out if it's mesa bug or game bug assuming https://youtu.be/L9QritXkozY?t=114
18:42 zmike: jekstrand: somehow it's not actually looping infinitely even though the shader nir definitely looks like it should be
18:42 zmike: it breaks out after ~10s on iris and ~1-2 on zink
18:44 jekstrand: :-/
18:44 jekstrand: zmike: That really should ge giving you a DEVICE_LOST
18:45 jekstrand: zmike: Are you seeing any reset messages on dmesg?
18:56 airlied: jekstrand: i think kernel hang detect is broken
18:56 airlied: or wierd
18:57 airlied: danvet_: may knownmore
18:57 danvet_: which gen/platform?
18:57 danvet_: and yes as long as you can still preempt, current i915 doesn't kill you and declare you dead
18:58 airlied: gen11 i think zmike has
18:58 danvet_: but it varies what can preempt, and whether mid-thread/shaders or just between 3dprim from the batch
18:58 danvet_: I think that can preempt mid-shader
18:58 danvet_: iirc for gen12 or so they lost that for $reasons
18:59 danvet_: also kernel version
18:59 danvet_: but not sure you can go back far enough and still have working gen11
19:00 danvet_: but if the shader does eventually stop it's not that
19:00 danvet_: or what does "break out" mean
19:01 danvet_: I think you also don't get the loud message (by default) in dmesg when we just do an engine reset
19:02 ickle: you do
19:02 danvet_:should probably go back to dinner and let people with working knowledge of the code speak :-)
19:03 ickle: you've got to the root of it; what does break out mean
19:11 airlied: also not sure if a device lost is approoriste if the shader is exited but the device lives
19:11 airlied: but i cant remeber the api semantics
19:11 airlied: jekstrand: does loop umroll also boow.up your shader?
19:14 jekstrand: airlied: ?
19:20 airlied: jekstrand: just wondering if we unroll a loop that calls a fn that geta inlined
19:21 bnieuwenhuizen: depends on the size of the body including inlined function
19:21 jekstrand: airlied: context?
19:21 jekstrand: airlied: Generally, loop unrolling happens after inlining
19:21 airlied: jekstrand: cl shader that gets big
19:21 airlied: and ooms
19:21 jekstrand: airlied: No, it OOMS in the initial function inline
19:22 airlied: ah cool
19:22 airlied: jekstrand: any idea how useful the spirv inline hints are?
19:22 airlied: ive started hookinf them up
19:22 airlied: for llvmpipe
19:23 jekstrand: airlied: Today, we inline everything
19:23 jekstrand: airlied: If we wanted to stop doing that... I don't know. I imagine they're about as useful as they are to C compilers.
19:24 airlied: yeah my branch is not inlining
19:24 jekstrand: Have fun with that!
19:24 airlied: but i need to write a function cleanuo pass to discard dead fns
19:24 jekstrand: I'm sure lots of optimizations are busted if there are calls
19:25 airlied: it makes it through to llvmpipe at least
19:25 airlied: but cleaning up dead fns is necessay
20:32 danvet_: emersion, just noticed you're comment on newsy fighting the good fight
20:32 danvet_: it's kinda impressive how like 80% in the comments is just bonkers
20:33 emersion: yeah, i should just stop trying ;_;
20:36 zmike: jekstrand: sorry, I've been in and out this afternoon
20:36 zmike: no reset messages or anything
20:38 zmike: I used to get a DEVICE_LOST from spec@arb_shader_storage_buffer_object@execution@ssbo-atomiccompswap-int in zink, but somehow after either mesa or kernel updates I'm no longer getting them
20:38 zmike: and I can't seem to trigger them no matter what I try :/
20:38 zmike: makes testing a gallium device reset callback challenging
20:38 airlied: danvet_: all the comments in most sites are bonkers
20:43 danvet_: zmike, tried isolating which upgrade changed this?
20:43 danvet_: could be either kernel or maybe also mesa
20:44 danvet_: airlied, popular topics like this seem to be worth
20:44 danvet_: still only a handful of people with some clue, but more clueless to drown them out
20:46 airlied: danvet_: you should have said it on a monetised blog :-P
20:48 danvet_: airlied, well phoronix would still have copypasted and stolen all the adclicks
20:48 danvet_: as probably like 5$ in total
20:51 ccr: uhh .. 245 comments.
20:53 karolherbst: yep
20:54 karolherbst: wondering if I should throw some more comments into it or not :D
20:54 airlied: you should always throw more tyures onto a tyre fire
20:55 zmike: danvet_: not particularly since I haven't paid attention to it for a couple months now, so it could've been just about anything :/
20:55 airlied: I was consiering going full blog post to amp it up
20:55 karolherbst: airlied: ehh, the replies I got are quite stupid
20:55 danvet_: airlied, do it
20:55 danvet_: just .... DO IT
20:55 karolherbst: somebody tells me, that preventing applications from grabbing input/recording screen is bad, because it treats people as children
20:56 karolherbst: or rather "is just to protect them from themselves"
20:56 karolherbst: I'd be glad if such people never decide anything security sensitive :D
20:56 karolherbst: sadly, those do
20:58 airlied: danvet_: just register isxorgabandoned.com
20:58 karolherbst: Xorg countdown
20:58 danvet_: also need whenwillX12ship.com and just redirect to mutter or whatever
20:58 karolherbst: uhm
20:58 karolherbst: xorgclock.org
20:58 karolherbst: like https://pythonclock.org/
20:58 karolherbst: and just put 0s
20:58 danvet_: karolherbst, I don't think that'll happen
20:59 karolherbst: I know you want to do it
20:59 danvet_: I guess in 1-2 years someone's going to be fed up, filter xwayland out of the xserver repo
20:59 karolherbst: just do it
20:59 danvet_: and we'll ship that thing for another few decades or so
20:59 airlied: danvet_: MrCooper is already workong on that
20:59 karolherbst: that's already decided :p
20:59 danvet_: lol
20:59 danvet_: I thought the plan is to trick emersion into doing it
21:00 airlied: < MrCooper> xwayland release branches with other DDXen dropped
21:00 airlied: I'm assuming we'd just filter to do that
21:00 airlied: inside the xserver repo
21:00 karolherbst: I think we can keep things like Xvfb? dunno
21:00 danvet_: make it the official xorg-xserver 1.21 release
21:00 karolherbst: dropping everything sounds a bit drastic
21:00 danvet_: just to rub it it
21:00 karolherbst: but...
21:00 karolherbst: if somebody does it and nobody disagrees, I'd be fine with that
21:01 karolherbst: danvet_: +1
21:01 danvet_: karolherbst, there's no wnest or similar yet?
21:01 karolherbst: no clue
21:01 danvet_: or fire up weston on vkms.ko with xwayland
21:01 karolherbst: uhmmm
21:01 karolherbst: sounds more painful than just running Xvfb
21:01 danvet_: maybe we get an outreachy this winter to add configfs support to vkms
21:02 danvet_: so you can have all the fake compositor instances you need
21:02 airlied: karolherbst: no reason to ship and updated Xvfb
21:02 airlied: it would still be in the Xorg package
21:02 karolherbst: well, we need a simple way of being able to do headless GL
21:02 emersion: karolherbst: is this what you want? https://github.com/Hjdskes/cage
21:02 airlied: the idea behind xwayland release is you would just get xwayland
21:02 karolherbst: airlied: ahh, so X is 1.20 for eternity, and only xwayland gets releases?
21:02 airlied: karolherbst: yes
21:03 airlied: until someone volunteers to RM X.org
21:03 karolherbst: emersion: more painful than just running Xvfb
21:03 emersion: karolherbst: how so?
21:03 karolherbst: need to build it
21:03 emersion: :P
21:03 emersion: indeed
21:03 karolherbst: getting Xvfb running is literally two commands
21:03 karolherbst: one if it's already installed
21:04 emersion: cage is in some repos
21:04 emersion: oh, and i forget that weston has a kiosk mode now too
21:04 danvet_: yeah I'd expect every semi-competent compositor will have something like that for testing
21:05 danvet_: quick search says kwaylandtest is, didn't look further for the others
21:05 emersion: just running in nested mode is supported by almost all wayland compositors i know of
21:05 karolherbst: emersion: but then you already need something
21:05 danvet_: well you need to put your turtles all the way down on something
21:05 karolherbst: I meant to run it on a server
21:05 karolherbst: worst case, no GPU
21:05 danvet_: aka s390
21:05 karolherbst: :p
21:06 danvet_: if rh engineers come up with something funny, it's always s390
21:06 karolherbst: hey.. still planning to CI llvmpipe on that, but god that will be painful
21:06 danvet_: especially post ibm :-P
21:06 karolherbst:whistles
21:43 karolherbst: airlied: interested? https://github.com/llvm/llvm-project/commit/89808ce7343b22586bfd0d3fafddcdbba94fbcbb :p
21:45 airlied: karolherbst: lols, won't be as fast as llvmpipe :-P
21:45 karolherbst: :D
21:45 karolherbst: of course not
23:43 airlied: ah yes execution mask and function calling interactions are fun