00:04 riteo: what
00:05 riteo: sorry, seriously no offence, is this wall of text procedural? I have some trouble following the sentences at all
00:10 Calandracas: They're doing the same in #llvm too
00:21 DemiMarie: Time for IP-based bans, or would that just cause a bunch of VPNs and Tor exit nodes to be blocked?
00:21 dcbaker: This person is not well and is very determined. This has been going on for years
00:22 DemiMarie: Same person?
00:22 DemiMarie: That’s why I was wondering if IP-based bans would be more effective.
00:22 DemiMarie: Since they can be harder to bypass, at least once all the VPNs and Tor exit nodes have been blocked.
00:24 Calandracas: but that harms everybody who uses tor and vpns
00:25 DemiMarie: True
00:26 DemiMarie: Generally, abuse prevention requires either some way to identify a person that is in some way expensive to change
00:27 DemiMarie: This could be an IP address with good reputation, an account with significant amounts of history, or something else.
00:27 DemiMarie: The purpose is to ensure that bans actually mean something.
00:27 Ristovski: I instantly recognized the same person, despite the nickname being different. And indeed, this has been going on for years
00:27 Calandracas: This person doesn't seem malicious, they seem mentally ill
00:28 DemiMarie: yes, and unless there is a way to get this person help, I don’t see how this is fundamentally different than dealing with a spammer.
00:28 bl4ckb0ne: is it me or the text is getting worst each time
00:29 bl4ckb0ne: before it kind of made sense and now its looks half generated
00:34 Ristovski: heh, even that random ass reference they mentioned is real - https://dataconomy.com/2024/02/14/what-is-universal-memory-and-gst467/
08:21 mandavoska: DemiMarie: I am feeling much better, channels that were once occupied by serious minds all turned backs on you, and that a mentally and genetically ill pig like you who should worry about what children do when you jump into the pool (look at shallow hal from imdb) but resort into talking and harassing intelligence, is not something that bothers me much anymore, how much harm a pig can do before it goes onto a pan? You are a full
08:21 mandavoska: blown idiots anyways, search for the IPs and do not eat all the food , there is global hunger. I look at you albeit mentally and genetically ill, but there is 150kg of meat possibly still to people in hunger who do not have to know about your mental and genetic inconsistency lol.
08:31 mandavoska: I wonder if DemiMarie is part of the united states fat forces, what a hero, likely next news is that she ate herself with bunji eating off, guts exploded.
08:34 mandavoska: it's an embarrassing remark for all the nation i assume, to let a person who should not be close to thinkers trying to code, but it's still not my problem.
09:10 dolphin: airlied, sima: shall you pull in last drm-intel-fixes as is or shall I just force push a rebase on top of -rc7?
09:15 sima: I think airlied planned to just merge the one that was missed for this week's -fixes
09:15 sima: so if you rebase might result in a bit a chaos
09:18 dolphin: yeah, that's why wanted to confirm
09:18 dolphin: so I'll let it be as it is
10:05 jani: istr having arrays on stack with dynamic size is frowned on, maybe existing ones were even being removed. is that right? just stumbled on https://lore.kernel.org/r/20240303081330.61091-1-duoming@zju.edu.cn
10:05 jani: in kernel context, that is
10:48 dolphin: jani: the code isn't definitely looking too good, probably should have a return value
12:42 jani: dolphin: yeah looked it up, VLAs are forbidden now, and we have -Wvla
12:57 alyssa: is it intended that mesa drivers don't support indirect VS outputs?
12:58 alyssa: seems to always get lowered to scratch mem by io_to_temps, and lower_io seems to rely on that
12:58 alyssa: even though indirect store_output is perfectly expressible in NIR
13:02 CounterPillow: jani: that is such a bad patch, and coming from a university e-mail, it makes me wonder whether it's intentionally bad.
13:03 jani: CounterPillow: hanlon's razor says no ;)
13:04 alyssa: mareko: ^ you probably know this piece of mesa archeology
13:04 alyssa: I guess indirect VS outputs are wholly uncommon so it isn't worth the complexity to plumb through?
13:58 grillo_0: hi, does anyone know when DRM_IOCTL_MODE_ATOMIC returns EMFILE? I'm getting this when running a benchmark that I'm writing that does a lot of atomic commits. I don't know what's causing it, maybe it's some resource I'm not releasing on each commit?
14:04 emersion: grillo_0: "EMFILE 24 Too many open files"
14:04 emersion: seems like your process is running out of FDs?
14:05 emersion: that would indicate a FD leak, rather than something wrong with the atomic API
14:05 emersion: you can system("ls -l /proc/self/fd") when you get this error is troubleshoot
14:05 emersion: maybe you're leaking OUT_FENCE_PTR, for instance?
14:06 emersion: to troubleshoot*
14:09 grillo_0: emersion: I think that I'm freeing all the FD's, but I'll recheck that with /proc/self/fd. I didn't know about OUT_FENCE_PTR, I take a look at that, thanks
14:10 emersion: i mentionned OUT_FENCE_PTR because it creates a new FD on atomic commit
14:11 emersion: maybe there is something more internal to KMS that creates new FDs on atomic commit, i don't know
14:12 emersion: maybe the sync file's file description is initialized even if OUT_FENCE_PTR is not set? i don't know
14:16 grillo_0: emersion: Interesting, I noticed that IGT is setting a "WRITEBACK_OUT_FENCE_PTR", maybe it's related to that. I'm using writeback, maybe I'm not handling it well.
14:16 emersion: ah yeah
14:16 emersion: the IGT framework might be doing stuff behind your back
14:20 grillo_0: emersion: Yeah, I suppose so. I will read more the other tests to see if they do something that I don't.
14:20 emersion: right. there is probably _something_ taking care of closing the FDs
14:20 emersion: in the IGT framework
14:21 emersion: well, let me know if you get stuck ;)
14:22 emersion: (it's also possible that the IGT framework is buggy is leaks FDs and nobody noticed until now)
14:27 pq: emersion, wouldn't 'self' be the wrong process in system("ls -l /proc/self/fd")?
14:28 grillo_0: emersion: There is: igt_remove_fb(). But I'm starting to think that the writeback part it's not that well integrated somehow.
14:28 pq: fd, not fb
14:29 emersion: pq, why would it be the wrong process?
14:29 pq: emersion, because it is 'ls' that opens /proc/self
14:29 emersion: hm
14:30 emersion: yeah that's probably not correct…
14:30 emersion: would need "/proc/%d/fd", getpid()
14:30 pq: yup
15:01 imre: airlied, sima: would it be ok to add https://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git/log/?h=next as a drm-tip topic branch for testing dp tunnels until 6.9-rc1 ?
16:08 Company: Now that more and more apps are starting to use GTK4, people have changed their hobby of running top to running nvtop and friends, and then they see big numbers appear for vram usage and then open angry bug reports
16:09 Company: (what makes me write this is https://gitlab.gnome.org/GNOME/vte/-/issues/2754 though that's about nvidia drivers)
16:09 Company: I have no idea why that happens and I know that the apps aren't using that much memory, but it looks bad
16:10 Company: so what do I do in situations like this where a nvtop claims a terminal window takes 100s of megabytes of vram?
16:33 Lynne: oh no, regression which causes all CS to be rejected when video decoding is enabled
16:38 DemiMarie: Company: I wonder if some GPU drivers are not optimized for the case of a huge number of programs using the GPU.
16:39 Company: I have no idea
16:40 Company: it could just be that they do a large mmap but the GPU doesn't back that allocation with pages until it's needed
16:40 Company: kinda how it usually works with ram
16:42 Lynne: f3ab454f074938ec89b245ad3166c69e0330ca8c breaks radv video decode
16:43 Lynne: airlied: seems to be related to more than 1 queue now being used for decoding video
16:49 grillo_0: emersion: I solved the issue! Thanks! IGT was creating sync files on every commit due to setting the IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR. I just needed to close them on every commit to fix the problem.
16:49 emersion: good to hear :)
16:50 Lynne: airlied: confirmed, when using more than a single queue to decode, the GPU rejects the CS
17:42 gfxstrand: How does one run deqp totally headless? I've got it built surfaceless but it's still erroring
17:42 gfxstrand: FATAL ERROR: Got EGL_NOT_INITIALIZED: initialize(m_eglDisplay, &eglMajorVersion, &eglMinorVersion) at tcuSurfacelessPlatform.cpp:275
17:42 gfxstrand: I know there's a magic incantation, I just don't know what it is. :'(
17:43 gfxstrand: Ah, EGL_PLATFORM=surfaceless
18:01 jenatali: gfxstrand: I need to come back to !22298 (WSI surface dedupe) I think. I don't think I'm the right person to try to a broader re-arch of WSI, but I do need Win32 surface deduping
18:54 Company: jenatali: I recently realized that Linux has similar issues
18:55 jenatali: Awesome
18:55 Company: jenatali: when I imported the same dmabuf multiple times as VkImages, things didn't work out too well
18:55 jenatali: That's... not quite the same?
18:55 Company: that's why I said "similar"
18:56 Company: was more that I wanted to point out that deduping is something that theres issues with
18:56 jenatali: FWIW Windows/D3D have the same problems there
18:57 Company: I think I've tried multiple VkSurfaces on the same wl_surface once in 2017 or so but I don't remember how it failed
18:58 Company: GTK has a design where you can have multiple renderers per surface (GL/Vk/whatever) and that design never worked in reality
18:59 Company: I'm not even sure what happens when you create a VkSurface and an EGLSurface for the same wl_surface
19:00 Company: but I would be very much in favor of things liek that being explicitly forbidden instead of it not working in practice
19:01 Company: because on the application level there's always a fight over resources when multiple libraries/frameworks want to use them
19:02 Company: and it'd help nudging code towards surfaceless APIs
19:19 DemiMarie: surfaceless APIs?
19:20 Sachiel: render into the ether
19:25 Company: DemiMarie: you can create VkImages without VkSurfaces just fine
19:26 Company: but many codebases are evolved from GL, and the various MakeCurrent() APIs usually want a surface
19:26 Company: I know for example that GStreamer has a tendency to randomly create a wl_surface when rendering with GL (no idea if that also happens with Vulkan)
21:57 colonization: such thing as frame rate issues does not exist under this computational model, and to be fair it never existed in any sensical form anyway
21:58 colonization: but i am going back to adolf hitlers documentary
22:03 colonization: Me i can not believe what those people sell, those products are at such a brilliancy , where have we reached is nuts, you actually buy yourself a robot friend from the shop, that is so advanced and complex science , and it offers every opportunity when you can calculate numbers.
22:04 colonization: you open this thing as a laptop it's entirely psycho as to what they sell as products and develop as profession.
22:13 colonization: i lived all this life, why i should be stupid, i saw in 10years turnaround time where everyone begun to have a smartphone , there is no way i can be stupid, when i was young we did not have facilities to play soccer, and with 20years the picture of the whole world so rapidly and drastically changed, that you buy such products where you open the case and say ou lord, my dear god.
22:21 DavidHeidelberg: dropped mine transition of nine frontend to SPDX licensing format, anyone else wants to follow with other, not-yet-converted, parts of mesa :P
22:28 colonization: the biggest part is explaining anyway, as yes science is complex, but the code is pretty primitive tricks, those are only well developed short sequences or bit twiddlings and not even bit, you only manipulate the number theory stuff in units, i find it very easy, as the explaining part is the biggest heroic, where some people are hard set mislead about what we actually have, and what they actually sell.
22:51 alyssa: DavidHeidelberg: I can dig up my script if you want
22:53 alyssa: https://rosenzweig.io/mit-to-spdx.py
22:53 alyssa: may help automate some tedium
22:53 alyssa: see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22062