04:14 treasuryx: <treasuryx> so it's quite simple for Bitcoin you generate random numbers and ask for collision from in format own generated number with blocks nodes in the Blockchain to see if servers rng did good job, that means only if collision is detected you need a new number, otherwise the occupancy does never matter. the rng technically would never fail if they were cheating like you in life, if
04:14 treasuryx: they were as <treasuryx> big as trash as you however. But you have to collect the response all the time, it's rpc but not internet in cpuminer so it is the bottleneck, can be recoded however number of threads in too aggressive modes, would cause random runaheads and you'd have no way of telling what to discard, remember that you are butchers not programmers you are alien butcher staff.
04:14 treasuryx: someday soon your balls will <treasuryx> be removed however. so you are pushing number of generated hashes to comparison through multibank accesses the single threaded mode already accommodates block size length of this you can not push to several blocks at the same time that way you would cause your own numbers to collide and .... validating yourself is not very intelligent thing to do, as
04:14 treasuryx: you give work to yourself where as you <treasuryx> never used rng in the first place so your numbers do not collide anyways. so even Bitcoin miner does not take advantage of multiple threads it's too simple model for it. vulkan compute shaders hence, pointless.
04:23 Ermine: dwfreed: requesting banhammer
05:39 DavidHeidelberg: eric_engestrom: I could reproduce the same failure 2 times in my MR, but not in the different previous MRs pipelines, now it passed, but I'm afraid something is wrong, can you check it's ok? https://mesa.pages.freedesktop.org/-/mesa/-/jobs/58794048/artifacts/results/summary/results/trace@broadcom-rpi4@behdad-glyphy@glyphy-v2.trace.html
05:39 DavidHeidelberg: it's not standard flake, because the screenshot was identical each time and it's pretty non-flake specific
08:20 luc: I'd appreciate if someone could shed light on the throttle thing under X11/mesa? When exactly is it needed? https://elixir.bootlin.com/mesa/latest/source/src/gallium/frontends/dri/dri_drawable.c#L529
08:23 MrCooper: luc: it limits how many frames the CPU can run ahead of the GPU
08:25 luc: MrCooper: if vblank is enabled, does it imply to throttling?
08:26 MrCooper: not directly
08:28 MrCooper: with the same number of colour buffers in the rotation, sync-to-vblank makes the underlying issue worse, since it results in higher input→output latency
08:46 luc: MrCooper: IIUC, it means even if vblank is enabled, we still have to do throttling for lower latency, doesn't it?
08:47 MrCooper: right
08:47 luc: thanks a lot
08:48 MrCooper: no worries
11:43 sima: pinchartl, did you look at the bridge hotplug proposal already?
11:46 sima: well especially the hotunplug part ...
11:49 pinchartl: sima: notyet. I suppose I should ? :-)
11:50 pinchartl: sima: what's your opinion on making connectors more dynamic, and allowing them to be created and removed at runtime ?
11:51 emersion: they already are
11:51 emersion: for DP-MST
11:53 pinchartl: indeed
12:35 sima: pinchartl, yeah that's my main take on this too, we should tie bridge hotplug a lot more to the connector
12:35 sima: since hotplug for that is already solved
12:36 sima: but it means that "who creates the connector" becomes even more fun for bridges ...
12:38 pinchartl: if we want bridges to become hot-pluggable resources, we need a way to signal bridges being removed, and we need drivers to react to that correctly
12:39 pinchartl: we may need a complete redesign of the bridge attach/detach API
12:42 mripard: plus all the use after free issues I'm sure it would entail :)
12:44 pinchartl: mripard: yes, those come as an added bonus of course
12:45 pinchartl: you get them for free
12:53 sima: pinchartl, yeah I think I'll just put that part as an open into my mail
12:54 sima: the patch set has a hotplug bridge to absorb some of the fun, but I think that needs to be lifted into shared code or it wont work all that well
12:54 sima: I'll focus more on the lifetime/locking fun
12:57 pinchartl: the "hotplug bridge" seems a bit of a hack :-S
13:42 karolherbst: mareko: I'm hitting the assert you added in 0e546fb6833dd178bb9f7889c82ae38e14dd868d sometimes when calling into clear_buffer
14:04 karolherbst: gfxstrand: up for a quick review? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29230
15:44 gfxstrand: karolherbst: done
15:50 karolherbst: thanks!
17:58 DavidHeidelberg: karolherbst: heya! I think about the freedreno+rusticl could be merged (at least for LLM it works), but I would maybe guard it somehow to prevent people accidentally using it ?
17:59 DavidHeidelberg: lumag: what do you think ^ ?
18:03 karolherbst: DavidHeidelberg: I mean.. there is still the env variable
18:04 karolherbst: soo... nobody will use it unless they really want to anyway
18:12 DavidHeidelberg: right :)
18:52 JoshuaAshton: pinchartl, sima: FWIW, there are still weird issues with unavoidable EINVALs with MST hotplugging due to connectors being removed/added kernel side. It broke a lot of userspace assumptions.
18:54 emersion: i think we fixed these?
18:54 JoshuaAshton: Link?
18:55 JoshuaAshton: I remember seeing those in Gamescope still with our dock that transitions from SST to MST when > 1 connector, definitely hit an EINVAL at some point there occasionally
18:56 emersion: i remember about this one https://lore.kernel.org/dri-devel/20231005131623.114379-1-contact@emersion.fr/
18:58 JoshuaAshton: I am thinking about where you get a New Device event thing from polling, then go to set up the connector, query it, then by the time you want to use it it's been removed
18:58 emersion: t should be in the unregistered state
18:58 emersion: iit*
18:58 emersion: hm
18:58 emersion: maybe that only happens when the connector has been enabled?
18:58 emersion: would need to check the kernel source again
18:59 JoshuaAshton: It's very difficult to see in like typical cable plug scenarios, but a Dock initializing as SST then doing a MST transition very shortly after triggers it pretty reliably fwir
19:03 JoshuaAshton: You could probably reproduce it synthetically in your app by just adding a big sleep after you query the connectors and unplugging the cable in that time
19:03 JoshuaAshton: (on an MST dock)
19:07 sima: JoshuaAshton, so as long as you don't include the connector, you shouldn't get EINVAL due to hotunplug
19:07 sima: at least we've tried to fix all these
19:07 sima: if you do include it, it's kinda unavoidable by design, because userspace doesn't hold a connector reference
19:07 JoshuaAshton: yeah
19:07 sima: so between you getting the connector stuff and then trying a modeset it might be gone again
19:08 sima: if you want to fix that, we could add userspace refcounting
19:08 sima: like a special GETCONNECTOR ioctl flag that opens a reference
19:08 sima: and you need to promise to close that with some new ioctl again
19:08 JoshuaAshton: Sounds good to me -- but also migggghtttt be abusable?
19:09 JoshuaAshton: I guess there is nothing stopping a userspace from being naughty and leaking connectors kernel side then
19:09 sima: you'd still get an EINVAL though if it's gone, but at least there's a guarantee that the connector id won't be reused by something else
19:09 sima: JoshuaAshton, you need to physically replug to actually leak anything
19:09 JoshuaAshton: Sure
19:09 sima: and we'd drop the refcount on close(drmfd)
19:09 JoshuaAshton: ye
19:09 sima: so it's kinda meh
19:10 sima: but also, it's not really giving you the "no EINVAL" guarantee, since if the thing is gone it's kinda hard to modeset on it
19:10 sima: I guess we could allow that, but might be somewhat funky and timeout prone ...
19:10 sima: (only on these special refcounted drm connectors)
19:11 emersion: another way would be a "i've seen this hotplug event" kind of IOCTL from userspace
19:11 JoshuaAshton: Yeah, makes sense when you can't modeset on it anyway really
19:11 sima: JoshuaAshton, so anyway, if it's a big issue we can certainly adjust the uapi
19:11 emersion: or, if you just want a workaround, wat 30s and then delete the connector
19:11 emersion: wait*
19:11 sima: but kinda another point in making hotpluggable bridges work like dp mst connectors, defo don't want to flavours of all these sharp uapi corners
19:12 sima: emersion, there's kinda the hotplug sequence counter for that
19:12 emersion: yea
19:12 sima: I guess we could pass that sequence counter in as part of the atomic commit
19:12 emersion: not exposed to userspace
19:12 sima: and if they mismatch, give you a special errno
19:12 emersion: … maybe
19:12 sima: well would be a good reason to do that
19:13 sima: but fundamentally there's just a race there
19:14 sima: and I think the current uapi that guarantees (or well tries to, we still find bugs&corners) that you wont get a hotunplug EINVAL as long as you don't include connector properties in your atomic commit is probably the best we can do
19:17 emersion: the timer workaround thing would solve it
19:18 emersion: it's not _great_, but we've been doing that for Wayland globals (which are Hard to fix for reasons) and it works very well
19:32 sima: emersion, the timer would need to be on the connector status change to unplugged itself
19:32 sima: which kinda opens a can of worms if we do this across all drivers
19:32 emersion: not sure i understand
19:33 sima: since delaying the connector deletion only delays reallocating the kms id of that connector
19:33 sima: you still get EINVAL the moment it's unplugged (if it's included in a modeset/atomic ioctl call)
19:33 emersion: hm yeah
19:33 sima: so also a bit a question of what's the real issue, just connector id confusion, or also the EINVAL
19:36 sima: emersion, hence why I'm leaning towards exposing the hotplug seqno and passing that as an argument to atomic and then failing with a special E_OUT_OF_DATE errno or so
19:36 emersion: yeah that sounds better
19:36 sima: and then just leaving it to userspace how it wants to recover
19:36 sima: EIDRM sounds neat for this :-)
19:37 emersion: it could generalize to other state that needs sync as well
19:38 sima: yeah could do it in general for IMMUTABLE properties that the kernel sets
19:39 sima: if the value you supply doens't match you get the special errno back
19:39 sima: but the hotplug seqno should cover it all pretty well, including the connector id confusion case
19:39 emersion: well
19:39 emersion: connector confusion would happen anyways
19:40 emersion: you can GETCONNECTOR and then get the wrong thing back
19:41 sima: well would need it there too
19:41 sima: hm the epoch counter is per connector
19:41 emersion: but that wouldn't generalize
19:41 emersion: GETPROPERTY etc
19:42 emersion: eh
19:42 sima: so you actually cannot use that to avoid confusion, we'd need to make the epoch counter at least device global
19:42 emersion: i think the epoch counter is per-connector for a good reason?
19:42 emersion: hm
19:42 emersion: i think to detect when a connector changed?
19:42 sima: yeah it needs to be per-connector
19:42 sima: but we'd need a global timeline
19:42 emersion: so would need a new but similar thing
19:42 emersion: right
19:42 sima: so that when a connector is unplugged and a new one is replugged, it has a higher epoch counter
19:43 sima: well it's not yet exposed, so doesn't matter
19:43 emersion: right
19:43 emersion: indeed
19:43 sima: and even if it is, it would just mean the epoch increments a bit faster, when it does
19:43 sima: which userspace already needs to cope with anyway
19:43 emersion: yea
19:43 sima: emersion, so thinking some more for the GET* one, if you just wrap it in GETPROP calls for the epoch, that should be enough?
19:44 sima: like you get the connector id from the uevent, so you can just go right ahead and grab the epoch of that
19:44 sima: and then do whatever you feel like, and then recheck the epoch
19:44 sima: so we'd also need to make sure that we send out the connector id everywhere
19:45 emersion: that sounds a bit cumbersome for userspace i must admit
19:46 emersion: do a bunch of things, then check the epoch, f it changed rollback all these things…
19:46 emersion: would be nicer to have -ETRYAGAIN
19:47 emersion: a "ACK epoch" mechanism would allow for that
19:47 sima: uh there's still a lot of places which don't even send out the connector id :-/
19:47 emersion: yeah, and we can't send the connector ID always
19:48 emersion: when you unplug a dock there might be 2 connectors involved
19:48 sima: well I mean a lot of places that could but don't
19:48 sima: emersion, well those could just send 2 events
19:48 emersion: i tried to fix at least some of them
19:48 emersion: sima, amdgpu groups these
19:48 emersion: well, it's nicer to have a single uevent for a single logical change
19:48 emersion: user-space only needs to rescan once
19:49 sima: well most should go out through dp mst helpers, which atm just batches them because it doesn't bother
19:49 emersion: i reall thought i fixed that…
19:49 sima: wouldn't be too hard to keep track of the impacted connector, and if there's more than one, clear that and send the big event
19:50 emersion: yeah i implemented something like this
19:50 sima: emersion, I think on the big driver the usual connector events are fixed, but not dp mst stuff
19:51 sima: I think at least, from a few quick greps
19:52 emersion: hm i fixed drivers but not DP-MST it seems
19:52 emersion: https://patchwork.freedesktop.org/series/95938/
19:53 sima: yeah, there's also a pile more
19:54 sima: git grep is 48 vs 19 ...
20:00 ernstp: so intel-vulkan requires llvmspirvlib now?
20:03 airlied: yeah to buuild
20:11 ernstp: been trying to maintain a mesa ppa with ubuntu 20.04 (focal) support but I think I have to drop that now
20:11 ernstp: well, there has to come a time for that
20:54 kisak: ernstp: fwiw, spirv-llvm-translator 15-18 are on the build farm focal i386 whitelist. You can unstuck yourself https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa/+sourcepub/15775693/+listing-archive-extra
21:04 ernstp: hi kisak! looked like spirv-llvm-translator wanted gcc-13 though? and got some test failures when building with gcc-9 instead..
21:05 ernstp: was trying with -16 though. perhaps -15 would work better...
21:19 pinchartl: emersion: sima: I like the seqno idea
21:21 pinchartl: regarding reuse of the connector id, I wonder if we could avoid reusing ids. that won't work if we consider transient objects like frame buffers, but for objects that have a longer life span, could we just increase the id ?
21:21 pinchartl: that brings other issues obviously
21:21 pinchartl: we'll have a wraparound at some point
21:22 pinchartl: but maybe we don't need to care about >2G plugs/unplugs ?
21:25 kisak: spirv-llvm-translator-## should be the same number as the llvm build you're using with mesa.
21:32 emersion: imho warparound is fine
21:33 emersion: hm
21:33 emersion: would need to make sure to skip already allocated IDs though
21:34 pinchartl: that may lead to log(n) operations
21:34 pinchartl: sorry, O(n)
21:35 pinchartl: too late to type
21:35 pinchartl: or think :)
22:51 DemiMarie: not if one uses a range tracking data structure that makes this fast