08:09MrCooper: DemiMarie mareko: FWIW, xf86-video-intel doesn't (always) enable DRI3 by default either
10:27phasta: Does anyone here know how amdgpu pairs up with its cards? I looked at amdgpu_drv.c's section with the PCI IDs, and it seems they haven't added new IDs in years… do they have a catch-all ID or something like that?
11:49MrCooper: phasta: indeed, it does
11:51MrCooper: and it checks the individual IP blocks of the device to determine whether or not it can actually drive it
11:59phasta: MrCooper, do you have a pointer to the code?
11:59phasta: And, in this context, what is an IP-Block?
12:10pq: Intellectual Property block, a.k.a hardware block
12:49robmur01: daniels: FWIW i.MX6S/SX still exist ;)
13:00kobboi: I have a gnome-shell > mutter > mesa crash in my VM. Backtrace at https://bpa.st/KUQA. Should I log this with mesa or with one of its users?
13:01kobboi: (it makes gnome-shell/gdm crash at startup, falling back to X iso wayland)
13:35MrCooper: phasta: not offhand, agd5f ?
13:36MrCooper: kobboi: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12467
13:36phasta: I think it's in amdgpu_drv.c line 2139 following where they set up a catch-all and then do IP magic
13:36phasta:doesn't like IP magic
13:42MrCooper: not sure what you mean by "IP magic"; this compares the HW configuration to what the driver can actually support, would you prefer it to roll a dice or something? ;)
13:48kobboi: MrCooper: awesome, I had encountered this same coredump already some weeks ago (although the side effect was different at the time) but there was no bug about it yet and I did not have the time to do anything with it (other than downgrade mesa). So I should have checked again for an existing bug. Thanks!
13:50phasta: MrCooper, just register the actual PCI device IDs. This way it becomes totally obvious what hardware the driver is actually supposed to support
13:51MrCooper: phasta: you're assuming a 1:1 mapping between PCI IDs and HW configurations, which doesn't exist for newer AMD GPUs
14:07DemiMarie: MrCooper: isn't that deprecated in favor of modesetting?
14:17Ermine: so... all new cards have the same id?
14:19Ermine: all new amd cards that is
14:34knurd: Lo! Is it possible to install mesa's vulkan drivers in a separate directory (say /usr/lib64/dri-freeworld) and then make the Linux install use those by default (e.g. instead of the ones from the distro) using just drop-in files?
14:34Mis012[m]: magic is the opposite of having self-describing hw, obviously the benefit of ugly magic where the kernel has to have everything hardcoded is that you don't need to rely on dumps from people with the hw to get the full picture
14:34knurd: Touching the distro's driver/icd files nor using the environment variables like VK_DRIVER_FILE are options for what I want to do: provide mesa-vulkan-driver add-on packages for fedora
14:35knurd: that contain vulkan drivers supporting hw video acceleration for patent encumbered codecs.
14:35knurd: I did a few experiments (https://fosstodon.org/@kernellogger/113899675657764802 ) and was able to install drivers in parallel without any problems and use the one I build with VK_DRIVER_FILE
14:35knurd: But I did not manage to make the system use it by default; to my untrained eyes it looks like libVkLayer_MESA_device_select.so reorders things and prefers the distro's vulkan driver.
15:06MrCooper: Ermine: not all the same, not all unique ones though
15:36alyssa: unrolling a loop fixes a CTS test with lavapipe
15:36alyssa: this does not spark joy (:
15:37zmike: 🤕
15:38alyssa: umm... can someone with an x86 machine try a branch for me real quick?
15:39alyssa: alyssa/mesa:gallivm-brokenness with lavapipe cts test dEQP-VK.ray_tracing_pipeline.watertightness.0.65536
15:39alyssa: it's RT pipelines which means the diff is... large..
15:39zmike: you won't believe this
15:39zmike: but I don't have you in my remotes
15:40zmike: are we even developer friends?
15:40zmike: oh no it was just on one machine
15:43zmike: alyssa: it passes before/after your branch for me
15:44alyssa: extreme clown moment
15:45alyssa: so this is breaking with my brnach.. only on arm64 then..? *melts*
15:46alyssa: konstantin: passes with your loop limiter change cherry-picked
15:46alyssa: can i go bed to sleep now
16:20stsquad: when it comes to device memory allocated for native-context is that TTM or the driver that does it? I want to try an experiment to see if improving alignment helps
16:40agd5f: phasta, amdgpu claims all devices with VID=0x1002 and VGA and Display PCI classes. Then we read the IP discovery table from the device to determine if a device is supported or not. See amdgpu_discovery.c
16:42jenatali: mareko: Re: glthread: I think the WGL frontend doesn't have glthread hooked up yet. I don't think there's a reason not to do it, it just hasn't been a priority yet. So we either need to hook that up or else just make sure we don't break non-glthread
16:42jenatali: If Linux is trending towards glthread then we should probably enable it for WGL just so we don't get divergence that makes hard-to-investigate bugs
16:42agd5f: phasta, specifically amdgpu_discovery_set_ip_blocks() for how we match ip blocks
16:51alyssa: pendingchaos: metadata validation has significantly regressed vtn_bindgen2 performance in debug builds of mesa (== dev build times), profiling shows vtn_bindgen2 is entirely nir_validate bound and reverting the metadata/dominance validation commits helps a ton
16:51alyssa: is there any low hanging optimization fruit in nir_validate for the new metadata stuff?
16:52alyssa: should we necessarily be validating everything after every pass? IDK the answers to these
17:13guludo: jani: uh-oh... Looks like dim rebuild-tip -d doesn't work as I expected (it appears I need to use -d before rebuild-tip).
17:14jani: guludo: all dim parameters go right after 'dim'
17:15guludo: I realized that now... Sorry.
17:15guludo: ah, thankfully it appears rebuild-tip doesn't use the local drm-intel-next.
17:16guludo: so I guess, hopefully, no harm was done? I just ended up pusing a new drm-tip with the same trees as the previous one?
17:19guludo: because I did not use the local branch positional arg... I guess I was lucky
17:26jani: yeah, dim is a bit dim
17:37guludo: now I used dim -d rebuild-tip drm-intel-next and build-tested locally; then used dim push.
17:39jani: I've never used dim -d myself. if the patch applied to drm-tip during CI and to an individual branch while merging, it's extremely unlikely to cause problems
17:39jani: unless there's a long time between the two
17:41vsyrjala: i usually do 'dim -d rebuild-tip + build test' after resolving a conflict
17:47jani: I avoid applying patches that conflict ;)
17:48pendingchaos: I'm not aware of any low hanging fruit
17:48pendingchaos: and I think validating after each pass is generally best, since a later pass could hide the issue before the next validation
17:56demarchi: jani: when applying a big patch series, I don't want to be caught by surprise, **after pushing**, that a merge failed
17:57demarchi: jani: so I usually do "dim -d rebuild-tip drm-xe-next"
17:57jani: demarchi: yeah I get that too
17:57demarchi: so it uses my local drm-xe-next branch just to check if it will be able to merge everything
17:59demarchi: guludo: I wouldn't say lucky... I added a check for that on purpose ;)
18:53alyssa: pixelcluster: do we have any idea for how scratch/stack works in NIR with multiple real functions?
18:53alyssa: it feels like what NIR calls scratch really should be stack, and nir->scratch_size should be per-function_impl?
18:54guludo: demarchi: thanks :-)
18:54alyssa: (and then things should "just work" with real functions)
18:54alyssa: (provided the backend maintains the sp appropriately across calls)
18:55alyssa: I'm hitting this with vtn_bindgen2 but that's just a symptom tbh
18:56alyssa: (and then I guess nir_inline_functions would need to handle sp bumps and -- and then scratch_size breaks -- oh ffs)
19:00karolherbst: yeah... it's a big topic and yeah.... a lot of things to figure out :)
19:13rodrigovivi: sima: https://lore.kernel.org/dri-devel/20241017075725.207384-1-giedriuswork@gmail.com/
19:14rodrigovivi: this one requires ack from you or dave since it touches include/drm right? or ack from drm-misc maintainers is enough?
19:15alyssa: karolherbst: definitely the current model of shader global vars for scratch is not what we want
19:15alyssa: although I don't know exactly what is
19:28karolherbst: yeah...
19:29karolherbst: from a "everything is inlined" perspective it works well enough, but once we move away from that......
19:30karolherbst: I still have to figure out CL global vars in the global address space and believe me, that's a mess on an entire different level 🙃 I honestly don't know what they were thinking with that one...
19:33alyssa: what's the problem there, other than thread safety?
19:42calligraphytest: so tbh. i am writing the compiler soon for this mode executing things in new format and i no longer describe in depth as to how that plays out. in other words i am planning on leaving you now finally. it never looked that dwfreed understood what is he arranging, i never threattened anyone before the bombs landed my way, and in depth i described to david airlie as how much “real” info
19:42calligraphytest: estonian scammers provide i.e than its lot saner to inspect mickey mouse asshole with apetite than listen to what fraud estonians have been up doing at.
19:52sima: rodrigovivi, drm-misc is enough but ack
19:52rodrigovivi: thank you
20:11yrlf: quick DMA-BUF question: if I create a DMA-BUF with gbm_bo_create, and the underlying DMA-BUF will be kept alive as long as I have a valid fd to it, right?
20:12yrlf: i.e. I can gbm_bo_destroy() it as soon as I have another fd to it and I have effectively "exported" it out of libGBM
20:13emersion: yeah
20:13emersion: GEM handles also keep a refcount
20:13yrlf: great, thanks
20:13yrlf: currently trying to clean up the mess I have in wl-mirror, finally trying to get the DMA-BUF details right
21:08mareko: alyssa: scratch is only for spilling, though if you have function calls, you need it to work like stack
21:08alyssa: mareko: I'm talking about nir's load/store_scratch intrinsics
21:09mareko: that's just for spilling
21:09alyssa: nope :(
21:09mareko: and indirect indexing emulatino
21:09alyssa: ..and function temps in OpenCL (`private`)
21:11mareko: isn't that just indirect indexing
21:16austriancoder: daniels: if you have time to talk about what's needed to land !3418 - feel free to ping me or leave a comment in the MR
23:40karolherbst: alyssa: sooooooo CL global vars are global to the _program_ not individual kernels, so it shares the content across kernel invocations and everything + it supports initializers, so you need to initialize it after compilation, not on a queue. worse, the initializer can depend on the address of the global var + any deref chain based on it
23:40karolherbst: which means... specconstantops can be derefs
23:40karolherbst: which means it's not a constant
23:40karolherbst: which means.. I need to be able to spill spec constant op chains to an initialization kernel 🙃
23:40karolherbst: it's horrible
23:41karolherbst: though...
23:41karolherbst: an alternative approach would be, that I reserve an address and pass it into spirv_to_nir, but then I'd have to do deref chain resolving in spirv_to_nir and not in lower_io 🙃
23:42karolherbst: this feature is just cursed
23:42jenatali: karolherbst: The spec says initialization can happen on first-enqueue of any kernel from the program
23:42karolherbst: and the only benefit is, that you don't have to bind a buffer containing that global state...
23:42karolherbst: jenatali: sure, but what if you have 5 enqueues on 5 threads
23:42karolherbst: on different queues
23:42jenatali: Serialize 'em
23:42karolherbst: well...
23:43karolherbst: I'd prefer not to
23:43karolherbst: but yeah.. I could
23:43karolherbst: doesn't really change much because that's not the hard problem
23:43jenatali: Heh sure
23:43karolherbst: the hard problem is the specconstantop situation
23:44jenatali: Yeah that's gnarly
23:44karolherbst: I liked my idea with passing in the address, but then later I noticed: wait... there are deref chains on top
23:44karolherbst: I have a prototype for it, but I hate it
23:44karolherbst: (spilling the constant op chains to an init kernel that is)
23:45karolherbst: it's just sad that 1. generic_address_space CTS testing _requires_ this feature
23:45karolherbst: and generic_address_space is required by adapticecpp
23:45karolherbst: it's all pain
23:47jenatali: Yeah. CL was a mistake