00:27 zzoon[m]: airlied: okay.thanks. note that the branch has been updated last Friday.(5days ago)
00:34 zzoon[m]: airlied: yeah confirmed your branch is on top of my latest branch.
00:38 zzoon[m]: airlied: please review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26139 just in case you missed it.
02:48 DemiMarie: If someone could exploit Firefox or Chromium by using WebGL or WebGPU to trigger a bug in Mesa, would this be a Mesa vulnerability or a Firefox/Chromium vulnerability?
02:49 DemiMarie: I don’t think “only receives trusted input” is a reasonable assumption for Mesa’s compilers anymore, unless browsers all switch to having 1 GPU process per origin.
02:51 DemiMarie: In this (hypothetical) example, there is certainly a vulnerability somewhere (website can compromise end user’s system) and certainly a bug in Mesa (undefined behavior triggered via valid API usage).
03:30 jenatali: FWIW the Windows team's perspective is that a graphics API isn't a security boundary. Security needs to be managed at the web, kernel, or hardware levels
03:35 immibis: that makes no sense from a principled perspective
03:35 immibis: or is it a "kernel-coloured glasses" problem?
03:36 immibis: i.e. from a kernel perspective, the kernel can't stop the graphics API having vulns - kernel security boundaries are processes and tokens. But from a graphics API perspective, API calls should only draw on the screen, not format your hard disk
08:03 mripard: sima: so, there's a missing SoB (from the committer) in drm-misc-next, for one of our patches. What should we do about it?
08:04 dj-death: sorry to probably ask again
08:05 dj-death: in the DGC extension, each group of token (containing elements like VkBindIndexBufferIndirectCommandNV, etc...) is stored in the stream buffer given by VkGeneratedCommandsInfoNV::pStreams
08:05 dj-death: where is the stride between each of those group of token?
08:16 sima: mripard, uh that would generally mean someone pushed ignoring dim ...
08:16 sima: or a bug in dim
08:16 sima: imo debug with the committer why this happened
08:17 sima: and then just leave it at that (with the missing sob supplied on the m-l maybe) since we can't really rebase drm-misc-next for this
08:19 mripard: yeah, I already asked https://lore.kernel.org/dri-devel/73cg637ax5cahqocscx5cjvtqkwlt4ves6cxgprbwqllasxq6v@gk6vzsqfc46j/
08:20 mripard: I'll ask for their SoB too then, thanks
08:28 sima: mripard, replied too
08:28 sima: I guess we might need to add cherry-pick to the list of things that are off-limits for committers in that bullet I quoted ...
08:40 mripard: yeah, it looks to me that it's not clear to most
08:47 javierm: sima: another advantage of using dim cherr-pick is that it traverses the Fixes: and wanrs you if you need to cherry-pick another fix (because the "fix" caused a regression too)
08:48 sima: javierm, yeah, but cherry-pick is more meant for adding a bugfix to -fixes that landed in -next first
08:48 sima: the other way round really should be a backmerge with explainer what you're pulling in & why
08:49 javierm: sima: ah, I see. Yeah, I don't think that cherry-picks should be done in -next
08:49 javierm: but backmerges as mripard and you said
08:49 sima: javierm, but we also have dim backmerge with some checks, so "use dim" still applies :-)
08:50 javierm: sima: yeah :)
09:12 jfalempe: tzimmermann, regarding https://gitlab.gnome.org/GNOME/mutter/-/issues/3157 , to mitigate the issue, maybe we can report a BMC connector, only if there is a DP connector.
09:13 jfalempe: for VGA, as it's not possible to know reliably if something is connected, the BMC virtual connector has no added value.
09:13 tzimmermann: jfalempe, the bmc comes with any connector
09:14 tzimmermann: i'm going to rework the connector code
09:14 tzimmermann: i guess, we have to go back to your original proposal and support the bmc transparently
09:15 tzimmermann: for vga, if we detect an EDID, we assume a monitor, otherwise not. and if theres no monitor, we return the bmc resolutions
09:16 tzimmermann: i'm not so super happy about user space failing us, but well
09:16 jfalempe: I though there was some VGA monitor without EDID.
09:16 tzimmermann: what?
09:17 tzimmermann: back to the 80s!
09:17 mripard: also, some VGA cables don't have the DDC signals wired
09:17 tzimmermann: userspace ignoring anything but the first connector would probably already resolve the issue
09:17 tzimmermann: we'd still get the bmc resolutions
09:18 tzimmermann: otherwise it'd would just be 1024x768
09:18 tzimmermann: i though the original problem was that this rsolution was too low?
09:19 jfalempe: the original problem is with DP output. if nothing is connected, it set 640x480
09:19 tzimmermann: that's really a bit low
09:19 tzimmermann: 640x480 was the DP standard's default, right?
09:20 jfalempe: tzimmermann, yes it's the default from the standard. But most monitors fails with 640x480, and works with 1024x768
09:20 tzimmermann: monitors cannot do 640x480 any more?
09:20 jfalempe: at least some of them don't.
09:23 jfalempe: and some userspace don't support 640x480, notably the anaconda installer.
09:25 tzimmermann: jfalempe, i want to rework the connector code anyway. i'd post a patchset soonish. for non-DP we'll see what we can do. having consistent behaviour would be nice, of course
09:25 tzimmermann: maybe someone from gnome meanwhile reacts to the ticket
09:28 jfalempe: tzimmermann, sounds good. yes a fix in mutter would be good too.
09:43 tzimmermann: jfalempe, FYI i've just asked in irc://irc.gnome.org/gnome about the problem
09:46 MrCooper: tzimmermann: FYI, the canonical GNOME channels are on Matrix, the IRC ones currently aren't bridged
09:46 tzimmermann: MrCooper, thanks
10:03 jfalempe: tzimmermann, another way to fix that would be to report the BMC virtual connector as "connected" only when the other connector is disconnected. That way only one connector would be on at a time.
10:04 tzimmermann: depends on gnome. IDK if gnome 'understands' that
10:05 emersion: it should…
10:05 tzimmermann: i mean, even if the connector is disconnected, it is still there
10:06 emersion: yeah
10:06 emersion: that's a common thing
10:06 tzimmermann: gnome still seess two conenctors
10:06 emersion: on your laptop maybe you have a DP and HDMI connectors, without anything plugged in userspace still sees them as disconnected
10:06 emersion: yet userspace doesn't go and try to use them
10:08 tzimmermann: i can easily test this here by hard-coding the bmc to disconnected. give me a minute...
10:10 jfalempe: that way we can even report more resolutions as valid, when the bmc connector is "connected"
10:25 MrCooper: eric_engestrom: FYI, I just marked https://gitlab.freedesktop.org/mesa/mesa/-/issues/10146 as a blocker for 23.3, since it looks like a zink regression, it's initializing with lavapipe when it shouldn't
10:25 MrCooper: tzimmermann: mutter doesn't try to use disconnected connectors
10:29 eric_engestrom: MrCooper: ack, and thanks for the ping :)
10:30 emersion: eric_engestrom: how should i go about marking a series of commits which should be backported, with only the last commit actually fixing a bug?
10:30 emersion: Fixes for all?
10:31 eric_engestrom: I would say `cc: mesa-stable` for those that only need to be backported because of the one with `fixes: $commit`
10:31 emersion: ack
10:32 eric_engestrom: `fixes:` for all would be a bit "wrong" IMO
10:32 eric_engestrom: since these don't actually do a fix
10:32 emersion: indeed
10:33 emersion: but it would make it easier to know which stable branches they should be backported to
10:33 emersion: like, there's a chance to misunderstood this, backporting all Cc commits to all branches, and Fixes to the last one only
10:34 tzimmermann: sounds like a good idea then. if that works, we can adopt it with a lengthy comment explaining the thing.
10:34 emersion: hm actually it sounds like Backport-to is the thing to use now?
10:35 MrCooper: eric_engestrom: no worries; JosExpsito[m]1 is going to create an MR to fix it
10:45 eric_engestrom: emersion: cc goes to all active stable branches, fixes goes to all active stable branches *that contain the fixed commit* (or a backport thereof)
10:45 emersion: right, so cc isn't good here
10:46 emersion: i've done Backport-to with an explicit version number
10:46 eric_engestrom: and yeah, we added backport-to: to make it only backport to specific branches, but there's a bug in that code that I haven't had time to fix yet so I have to check for that one manually right now to make sure I'm not missing anything tagged with that
10:47 emersion: hm
10:48 emersion: well, just let me know what you prefer. the tl;dr is that everything should be only backported to 23.3
10:50 sima: tzimmermann, jfalempe I think if we do a hack in the kernel then default to off modparam would be good
10:50 sima: really not super keen to encode this as uapi expectations because gnome dies
10:50 sima: maybe airlied has a different take (when he's back from lpc)
10:51 sima: tzimmermann, we could also do a drm knob where you only get a maximum of #crtc of connectors reporting as connected
10:51 sima: since the bug can happen in other drivers too
10:52 sima: drm.limit_connector_to_crtc or something like that
10:52 eric_engestrom: emersion: since you're specifying a single branch in your `backport-to:` it should work (the bug is when you have multiple of it) but I'll make sure it's backported 👍
10:53 emersion: ok thx!
10:59 jfalempe: sima, I see this as a temporary fix, the time for userspace to handle this case. As the BMC connector is already in 6.6, this can avoid breaking user's expectation.
11:00 javierm: jfalempe: there's nothing more permanent than a temporary fix :)
11:00 MrCooper: sima: I'd say in this particular case it makes sense by default, since the BMC connector was only added for when the real connector isn't connected in the first place
11:01 sima: ah if it was added then yeah we've hit the inglorious "it's a regression rule" ...
11:01 sima: still means that if we put this in now it's probably going to be forever :-/
11:02 jfalempe: yeah, and it's probably there for a long time already.
11:02 javierm: sima: agreed. But according to MrCooper it may be the correct thing to do (if is meant to only be connected when the other connector is not connected)
11:04 emersion: it all depends if the use-case have having both connectors displaying the output at the sae time is important to you
11:04 emersion: same*
11:04 jfalempe: using BMC and the real monitor at the same time is very unlikely.
11:05 emersion: right, so sounds reasonable to just have one of the two marked as connected then
11:06 tintou: Do we know who is pushing the Mesa builds to Coverity?
11:08 MrCooper: emersion: the BMC connector doesn't actually do anything, it's just so that generic user space doesn't fail to start up when the real connector isn't connected, so remote access via the BMC works
11:09 emersion: ... really?
11:09 emersion: because starting up without any connector connected sounds like a pretty basic thing to handle
11:10 MrCooper: maybe I'm mis-remembering the details, jfalempe?
11:10 emersion: my understanding is that the BMC connector is used for remoting
11:10 emersion: and then a physical connector can be used as well
11:11 emersion: if it's just about headless startup i'd really rather see userspace fixed
11:11 emersion: it's not a new situation and can come up pretty regularily
11:12 emersion: like, you start a rpi or something
11:18 jfalempe: Yes the problem is when nothing is connected to the display port, the default resolution is 640x480, so we added this "virtual" BMC connector, to overcome that.
11:19 jfalempe: and previously for userspace the DP connector was seen as always connected
11:20 emersion: jfalempe: when no external connector is connected, you still want user-space to display something right? and then grab this and send it for remoting?
11:21 jfalempe: emersion, yes because you may want to access the server remotely, it's the main use-case for aspeed card.
11:21 emersion: right
11:21 emersion: okay
11:21 emersion: can you detect if someone is using the remoting part?
11:22 jfalempe: emersion, no, there is currently no way to know that. It's even not possible to know if the hw can handle remoting (as some cards don't).
11:22 emersion: i see
11:23 emersion: right, so 2 connectors with only a single connected at a time, that makes sense to me
11:25 jfalempe: Also some cards have DP output, and older have VGA, and on VGA it's not possible to reliably detect if it's connected. But I don't think that's a real problem.
11:26 pq: jfalempe, how does the remoting actually work in the first place? Is there some dedicted mini-computer reading the BMC output and arranging that to be available via RDP or whatever using its own independent OS?
11:27 jfalempe: pq, it's an ARM chip, actually the VideoRAM is the RAM of the ARM processor. there is a web server running on it, that send the content of the framebuffer on the internet.
11:27 pq: I see.
11:29 tzimmermann: sima, whatever we do, it has to be on by default. our we simply declare this a gnome bug, which is actually is
11:31 sima: tzimmermann, yeah I think since the bmc connector got added later on it's on the kernel to paper over this :-/
11:31 sima: maybe in another lts or so we can try to revert, if we know the known-broken compositors are fixed
11:32 pq: jfalempe, is it hardwired such that the physical output and the remote output always use the same FB to read from? which would be why you need to model it as one CRTC driving two connectors?
11:33 tzimmermann: pq, yes
11:33 pq: ok, makes sense
11:42 kode54: get a load of this guy
11:42 kode54: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26187/diffs?commit_id=e3c978afc0269a17cc4f69d6bd0de59ba85f2ee4
11:48 tzimmermann: jfalempe, hard-coding the bmc to disconnected brought back the old behaviour. nice :) i'd strongly prefer that solution over the other possible workarounds.
11:48 tzimmermann: it's transparent to userspace, automatic, and we can easily remove it
11:48 pq: kode54, sounds like you are either laughing at them, or assuming bad intentions. Neither is nice. Reviewers will catch it in due time.
11:50 emersion: usually they are people not used to GitLab
11:51 MrCooper: this one so far seems immune to feedback though
11:51 jfalempe: tzimmermann, thanks, so I can do the patch, or if you prefer do that with your encoder refactoring ? But we may need that in misc-fixes for 6.6 ?
11:51 emersion: yeah :/
11:53 pq: close the MR instead of point and laugh, right?
11:54 emersion: indeed
11:55 MrCooper: they might just create another one, as they did instead of updating the original one
11:56 pq: if that's too much, there is a process for spam
11:57 MrCooper: not sure it's malice, might be just very clumsy
11:57 pq: it's hard to imagine that "get a load of this guy" is ever appropriate to say
11:58 emersion: tbh i was not sure how to parse this
11:58 karolherbst: yeah, or language barrier, or....
11:58 karolherbst: emersion: it's a meme
11:58 emersion: i assumed "i get a load of MRs from this guy"
11:58 emersion: oh, i'm just too old then
11:59 karolherbst: from friends
11:59 karolherbst: the tv series
11:59 pq: I don't recall the meme, but I have the impression it's derogative phrase
11:59 karolherbst: though the history seems older.. anyway
11:59 karolherbst: https://knowyourmeme.com/memes/get-a-load-of-this-guy
12:00 karolherbst: (for context)
12:00 karolherbst: seems like it's not from frinds actually.. I just saw it with that picture usually.. anyway
12:00 kode54: yikes, that spawned a whole conversation on the etiquette of link dropping?
12:01 karolherbst: I'm just here to explain
12:01 pq: kode54, not link dropping but the "load" phrase
12:01 kode54: ah
12:01 kode54: one of the earlier sources was possibly Wayne's World
12:02 karolherbst: yeah.. it's meant in a more humourus way usually, but I'd be careful with pointing out new contributors this way
12:02 kode54: right
12:03 ccr: I'm fairly sure that saying is way older than Wayne's World tho.
12:03 ccr: (irrelevant factoid, I know)
12:03 kode54: I do guess I'm doing exactly the wrong things I regularly expect others are doing to me
12:03 karolherbst: that's a common misconception, yes
12:03 karolherbst: I mean.. it always depends on the environment
12:03 kode54: I regularly expect everyone is pointing and laughing at me when I'm not there to see it
12:03 karolherbst: here we at least pretend to act more professional
12:04 karolherbst: nobody meant malice here anyway I hope
12:32 kode54: no, I wasn't meaning malice intentionally
12:35 kode54: also I originally thought that malice comment was related to me possibly suggesting the user was malicious
12:35 kode54: maybe making a rookie mistake
12:36 kode54: but doesn't look malicious
12:36 kode54: though it is a bit strange they decided to reconfigure the global CI to accept more rebuild actions
12:36 kode54: or at least, it looked like that's what it does
12:36 pq: that may just have been an attempt to get CI to run at all
12:37 pq: anyway, all good - careful with memes and popular phrases
13:02 tzimmermann: jfalempe, patch sent
13:06 eric_engestrom: tintou: I think it's brianp or vlee (they are the admins of the mesa project on coverity, which I think means it has to be one of them)
13:09 airlied: pretty sure it's vlee
13:35 tintou: Alright, emailed them both then :)
13:37 tintou: (I wanted to know which driver were being compiled because I don't see virgl there so that's suspicious 😅)
15:54 emersion: agd5f hwentlan__: is it fine to merge the amd patches for atomic async page-flips via drm-misc-next?
17:19 tjaalton: dcbaker: when can we expect mesa 23.2.2?
17:57 agd5f: emersion, fine with me
17:57 emersion: ty
18:39 eric_engestrom: tintou: `-D gallium-drivers=all -D vulkan-drivers=all` is what we want for builds like coverity; you can tell them that in your email conversation :)
18:40 eric_engestrom: also, I'd be interested in helping maintain the "components" list, it's in dire need of tlc
18:41 eric_engestrom: could you cc me (eric@engestrom.ch) into the conversation with these two notes?
18:56 tintou: Alright, I'll cc you when I get a reply 🙂
20:30 karolherbst: jenatali: I fixed my problem and I already hate it.... so the idea is to not emit "private" global variables, but have function local copies of them or something...: https://github.com/karolherbst/SPIRV-LLVM-Translator/commit/aab7a270861369fa143185a28ddad62be4905edc
20:30 karolherbst: sadly the AI model returns bogus values with mesa :')
20:31 karolherbst: and no idea what's up there
20:31 jenatali: karolherbst: That seems like the right solution. I don't know the code well enough to give you any kind of review though...
20:31 karolherbst: yeah...
20:32 karolherbst: I'll probably rebase it on the main branch and see what people say about it
20:32 jenatali: I really need to finish getting CLOn12 up to 100% conformance and then figure out a way to get CTS into some automation somewhere so it stays that way
20:32 karolherbst: yeah...
20:32 karolherbst: I kinda want to CI on the CTS as well
20:32 jenatali: Gotta figure out the right subset of it at least. Because there's no way you're running the whole thing in any kind of reasonable timeframe
20:33 karolherbst: so intel says the picture I have is 66.5% a minivan, it isn't really, looks more like a "normal" car, but rusticl on iris says 2.2% combination lock and nothing higher :')
20:33 karolherbst: jenatali: I do, in 5-10 minutes
20:34 karolherbst: let me show you
20:34 karolherbst: https://gitlab.freedesktop.org/karolherbst/opencl_cts_runner/-/blob/master/clctsrunner.py?ref_type=heads
20:34 karolherbst: grep for `quick`
20:35 karolherbst: that's roughly 5-10 minutes depending on the driver on a decent 12/20 core intel CPU
20:35 karolherbst: 20 threads
20:35 karolherbst: ehh
20:35 karolherbst: 8+4/20 I mean...
20:35 karolherbst: ehh quick + wimpy
20:35 jenatali: Cool
20:35 karolherbst: I only use that for testing
20:36 karolherbst: once I did a full run with zink I had like 4 fails, mostly MT related
20:36 karolherbst: so it's good enough
20:36 karolherbst: one bug with denorms only showing with longer runs
20:36 jenatali: Then the question is, do I put that in our GitHub project or do I try to onboard it to Mesa CI? And which component has to deal with ABI breaks between the compiler and runtime? Or do I try to move, or maybe even abandon the separate runtime? Idk
20:37 karolherbst: my script also can use the offline compiler to test the spir-v path and then with 3 drivers each online/spirv and each native/zink it takes like 2 hours in total across all combinations
20:37 karolherbst: and that's 12 runs i think
20:37 jenatali: I wish I could just adopt rusticl, but there's so many shenanigans in making CL-sourced nir usable for D3D (e.g. global => SSBO) that I don't think it's realistically feasible
20:38 karolherbst: yeah.. would have to move it all into the gallium driver
20:38 jenatali: Which is impossible if rusticl doesn't send me the buffers that the global addresses came from
20:38 karolherbst: or you just use it through zink :D
20:38 karolherbst: I benchmarked it against nvidia CL and zink got 92% performance
20:38 jenatali: Requires BDA, doesn't it?
20:38 karolherbst: yeah
20:38 jenatali: Yeah, we can't do that in Dozen
20:38 karolherbst: pain
20:39 jenatali: Yep
20:39 jenatali: Maybe someday
20:39 karolherbst: anyway.. openvino runs but gives wrong results atm :')
20:39 karolherbst: this will be fun to debug now
20:39 jenatali: Yeah, good luck
20:39 karolherbst: but at least no funky spir-v validation errors anymore
20:41 karolherbst: wouldn't surprise me if something with the compiler, but uhhh... those kernels are like huge
20:41 karolherbst: or maybe it's just broken on non intel
20:41 karolherbst: they have subgroup emulation code which isn't used on intel's stack obviously
20:41 karolherbst: I should check against nvidia on my desktop tomorrow
20:41 karolherbst: and AMD
22:59 gfxstrand: I think I just broken marge...
22:59 gfxstrand: Hopefully she fixes herself.