10:57 naughtyfreiko: those pdf's are miracle feed. Bounding limit means the number can go up or down from distribution when rounding the entry. But it has a formula, as to whether you go up or down to get to the fastest uniform distribution. Otherwise there are lower and upper bounds whiches meaning you just google. upper bounds vs lower bounds, google has some ai results engine too. Naughty boyz and gals
10:57 naughtyfreiko: that would lead to the distribution i gave yesterday. But there are other possible formulas however the paper is ridiculously well done, it's also compact enough. There is also a quantum one https://arxiv.org/pdf/2410.13559 , but i am not a quantum guy, i understand the theory though there too, classical computers are better.
13:18 gingerfromthebest: Now we've gotten to the point where there actually isn't something expectedly enough to talk about based that i was always enough correct, but having been basing on science that it's not possible that science did not reach to those ideas that i pondered on, and i was relying on more skill and goodness than as opposed to, so it's kind of positive mindset there needed to have , to be
13:18 gingerfromthebest: enough certain that things are developed as in a childhood dream at the max possible, of course this also happens to be a case too. But i do not know if you lack positive mindset, whether you needed my ruling or domination or help, either way now you have it. Why i never knew, cause you never spoke about anything practical, i do not have psychic skills, i do not know if you use
13:18 gingerfromthebest: generators tools to make that code, but in both cases, code has been decently elegant to be turned into something useful easily. Let's pretend that you are not entirely googowoogo, than you'd had realised already that my work is done too already :D:D .
13:26 gingerfromthebest: As to how i calculate of course even the easiest sport with possible overstretching at highest level is a risk to take, considering the intentional crack up or non intentional mistakes during surgeries, but science is a possible fallback there! And i have many fallbacks i am at least that much talented, and at the moment it's by far that all fallbacks are taken, i have reserves yet
13:26 gingerfromthebest: greatly above the medium of those.
13:31 alyssa: for a patch that's reviewed on-list, how long do I wait before applying to drm-misc-next?
13:31 alyssa: (I assume since I pushed adp, I also get to push the fix to adp someone sent :p)
13:33 javierm: alyssa: since you already have a r-b, no need to wait: https://drm.pages.freedesktop.org/maintainer-tools/committer/committer-drm-misc.html#merge-criteria
13:33 alyssa: javierm: ack, thanks
13:53 alyssa: tangentially, `dim b4-shazam + b4 ty -S` ... I legitimately cannot tell whether I should be more impressed at how good the tooling is these days, or terrified of email workflows going so far as to require said toolings XD
13:53 javierm: alyssa: why not both? :D
13:53 alyssa: javierm: extremely true
13:54 alyssa: like I am so impressed by this. but also,,, :p
13:57 K900: Hey folks, if anyone here's interested, I got back to cutting out libgbm: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33890
13:57 K900: This is all kinda WIP and jank but I'll clean it up in a bit
14:10 zmike: nowrep: is vdpau still actively developed?
14:12 K900: Kill it
14:12 K900: With fire
14:12 nowrep: i think there were plans by nvidia to add wayland support
14:13 zmike: they still don't use vaapi?
14:13 nowrep: but there really isn't a reason to use vdpau nowadays, every app will also support vaapi and some also vulkan
14:13 zmike: right
14:13 K900: Nvidia has their own even-more-proprietary APIs now
14:14 K900: In NVENC/NVDEC
14:14 nowrep: yeah there is no official vaapi nvidia driver
14:14 nowrep: but there is a driver to translate vaapi to nvdec
14:14 K900: As a Distros, I really hope everyone converges on Vulkan Video eventually
14:15 K900: So we can stop shipping a bunch of weird old drivers
14:18 Ermine: is vaapi old
14:18 K900: Yes
14:18 K900: Surprisingly so
14:39 zmike: mareko: under what conditions can a pipe_surface be used between contexts?
16:34 TurtleHat: Hey folks, I'm one of the foolish people who has an Intel Arc B580 on Linux and I've been trying to do my best to track the progress of the mesa support for various games I'm interested in. For a while I was following a specific merge request that seemed to be the start of Unreal Engine support (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32676) and it now means that I can boot (but never successfully load to gameplay) Unreal Games or
16:34 TurtleHat: Monster Hunter Wilds. I'm curious if any of you here have suggestions on a way for a person to track the progress of Battlemage Mesa support so I don't just keep updating git and building and trying to run games. Thanks all
16:58 mlankhorst: tzimmermann: if we push the fbdev patch series, would it regress i915 without vmap patch?
16:58 mlankhorst: Or would it just stay broken like it is now
17:33 tzimmermann: mlankhorst, the vmap patch is not required for the fbdev series
17:33 tzimmermann: vmap is only required for the drm_log client
17:34 tzimmermann: which currently doesn't work on i915 because of this
18:32 zmike: mareko: better question: I'm debating whether to make pipe_surface more strongly per-context or give up and make it per-screen. do you have a strong opinion either way?
20:21 linkmauve: Hi, did anyone start working on a video-only Vulkan driver targetting V4L2 decoders yet? And how feasable to you estimate it to be?
20:25 mareko: zmike: no
20:25 mareko: zmike: pipe_surface can't be used between contects
20:25 mareko: contexts
20:25 zmike: seems like it can
20:26 mareko: I guess it works, but it's not intentional
20:26 zmike: or at least it can be destroyed by contexts other than the one which created it
20:26 zmike: since there's a hacky workaround for that case
20:26 zmike: I'm thinking maybe store an array of pipe_surface onto the renderbuffer and then access that per-context or something
20:27 zmike: either that or make it fully a per-screen object? it's an annoying object type
20:32 mareko: per-screen is fine
20:33 mareko: svga folks might disagree
20:33 zmike: not sure they care as long as it's consistent and functional
20:51 alyssa: zmike: i'm terrified of hte idea of retroactively making something per-screen
20:51 alyssa: because of the multithreading implications
20:52 alyssa: do you want to audit&fix every gallium driver in tree to see if it's pipe_surface code is thread safe? I don't.
21:23 mareko: that's a good point
21:24 mareko: nowhere does it say that the private fields have to be immutable