08:49linkmauve: MrCooper, hmm, why can I build a Lima-only Mesa without LLVM at all then?
08:51MrCooper: presumably you disabled LLVM completely for the build
08:51linkmauve: Yes.
08:51linkmauve: -Dllvm=false or something.
08:51MrCooper: my point is that just disabling drivers which use LLVM isn't enough
08:51linkmauve: What is gallium draw used for?
08:53MrCooper: some vertex processing fallbacks, e.g. with GL_SELECT
08:54MrCooper: or all vertex processing for HW without vertex shaders
08:56linkmauve: Ah, so if I don’t build desktop GL support I don’t need that fallback for Lima?
08:57linkmauve: And if I enable desktop GL support, it will lack these features if I don’t also enable LLVM?
09:19MrCooper: the latter won't lack any features, it'll just be slower when hitting any draw module functionality
09:30mareko: GL_SELECT is fully accelerated if you have GS, SSBOs, and indirect temp indexing
10:23dliviu: hello, what's the etiquette for updating the DRI wiki, specifically the WhosWho page? I'm using a different handle nowadays
10:24mareko: deleting it?
10:24emersion: feel free to edit
10:24emersion: or ask me to make a change, if you don't have edit access
10:25dliviu: Oh, you mean on the web page? I see that the page is actually generated from a git tree, so I was wondering if I need to send patches
10:25dliviu: emersion: can you please s/nashpa/dliviu/g ?
10:26emersion: sure
10:26dliviu: thanks. It doesn't look like I have edit permissions on the wiki pages
10:26emersion: done
10:27dliviu: Oh, and if that matters, Ayan Kumar Halder has moved out, so unlikely to come to this channel again
10:30enunes: linkmauve: you should be able to build it without llvm, I do most of my development on it with a -Dllvm=disabled build, mostly to save some build time on the A53 socs
10:52linkmauve: enunes, I build on a much more powerful CPU, but not including LLVM also wins some 100 ms on each launch in the dynamic linker.
10:52linkmauve: But since I also usually avoid including GL support, since GLES 2.0 is generally enough for what I run, it shouldn’t really matter.
12:29tzimmermann: jani, is there a reason that the connector->force checks are in drm_edid_read_ddc() and not in drm_edid_read_custom() ? https://elixir.bootlin.com/linux/v6.8/source/drivers/gpu/drm/drm_edid.c#L2715
12:31jani: tzimmermann: yes. drm_edid_read_custom() can't probe ddc.
12:32tzimmermann: jani, sure. i'd like to call drm_edid_read_custom() but also want these checks
12:32jani: so it's pretty much up to the caller to handle that (which is probably haphazard at best across drivers)
12:32tzimmermann: could the result of drm_probe_ddc() be passed to _custom() ?
12:33jani: I guess we could add another function ptr for probe in _custom()
12:37jani: tzimmermann: along the lines of http://paste.debian.net/1312923/
12:37tzimmermann: jani, yeah something like that
12:38jani: plus changes to all callers, first passing NULL for probe, and probably having a wrapper for drm_probe_ddc() to get the types right
12:39tzimmermann: jani, how about calling drm_helper_probe_detect_ctx() ? https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_probe_helper.c#L338
12:39tzimmermann: not sure if that epoch_counter makes a difference
12:40jani: a lot of ->detect hooks will need to call drm_edid_read() and friends
12:41jani: it might be that checking for connector forcing originally in drm_get_edid() is a historical mistake
12:42jani: looks like it was added by yours truly :D
12:43tzimmermann: ha :)
12:45tzimmermann: i want to rewrite udl's get_modes and detect_ctx handling with the new edid functions. i guess for now, i can simply duplicate those few tests on ->force in udl
12:45tzimmermann: seems easiest
12:45jani: right
12:45tzimmermann: can the ->force checks be moved to .detect() easily?
12:46jani: I don't follow
12:46jani: ah, with connector forcing I don't think your detect will get called
12:46jani: iirc
12:46tzimmermann: instead of edid_read_ddc(), it seems to me that connector->force should be tested in the detect code paths
12:47tzimmermann: and changing that is a larger patch, i guess
12:48jani: I guess ->force and probe ddc do go hand in hand, serve the same-ish pupose
12:48jani: *purpose
12:48jani: "is something there"
12:48tzimmermann: i see
12:49jani: and it's intentionally different from just reading the EDID because the lower layers might return the EDID from debugfs override EDID or firmware loader, which will work regardless of the real connector state
12:50jani: if you have a broken EDID, but ddc works, you can use ddc probe to check for connected, and use the EDID from firmware loader
12:51jani: if ddc is completely dead, you can use connector forcing and EDID from firmware loader
12:54jani: I guess you could also just add http://paste.debian.net/1312925/ to handle force off in _custom(), and assume "unspecified" means connected, and have the custom read block function fail if it's not connected
12:54jani: maybe the easiest, tbh
14:19melissawen: n
14:19melissawen: y \
15:04epoch101_: Hi everyone! I was trying to understand how the radeon kernel module works, and this (https://dri.freedesktop.org/wiki/RadeonArchitecture/) was the closest resource I could find that would explain what I wanted, but its incomplete. Any idea where I could find more information about the same?
15:06epoch101_: I'm trying to find out what part of the code exactly writes to the display output when I write to /dev/fb0
15:06epoch101_: And initialize the display before writing as well
22:13dok: hi, bit offtopic but do you know a way to put a time bound on a drawcall (ie a shader taking too much time to render) ? some kind of watchdog.
22:17HdkR: The kernel has one but its response to something taking too long is usually killing the process
22:20HdkR: The only option that userspace has is the context priorities, which gives you some ability to preempt (Or have async compute?) but that's not really the same thing
22:23dok: yeah i want to avoid the kernel from killing the process
22:23dok: but if the drawcall never runs then who's gonna do it except the kernel :/