01:34 Company: so F38's current kernel doesn't get me Wayland, but the original 6.2.9 does
01:34 Company: seems like rpi is way more of an adventure than I had hoped
01:35 Company: also, gtk-widget-factory has rendering glitches
01:35 Company: https://i.imgur.com/Zy6SJ2J.png
01:51 Company: gsettings list-recursively | grep a11y
01:51 Company: wrong keyboard
04:10 luc: hi
04:18 luc: Hi! wonder if these two #define ( https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm.h#L845) should need an #include <fcntl.h> from a self-contained perspective.
06:10 Kayden: hi! so I've been looking into some cases where folks are using wayland with two GPUs, and a monitor plugged into each of them. I realized I'm not that familiar with how that is supposed to work
06:10 airlied: depends on the compositor
06:11 airlied: currently not sure compositors handle it properly, I think mutter has some plans to do it properly
06:11 Kayden: figured that was the case, I've been using mutter
06:11 Kayden: it appears to be working on my machine, but not on someone else's
06:12 Kayden: I wasn't sure which GPU was used to do rendering in that case. Does each GPU render the scene for their own monitor's output? Or does one of them take point, and use...PRIME?...to ship it off to the other one?
06:12 airlied: I think currently one GPU does it all and ships it to the other
06:13 Kayden: ah, interesting, that's not what I expected
06:13 Kayden: sounds reasonable though
06:13 Kayden: any clue how it picks? wondering if my working setup is going one way and the broken one is going the other direction, or something
06:14 Kayden: normally I'd say one has the display outputs connected to it, but with thunderbolt it's like...well, I guess both are valid
06:14 airlied: it should pick whatever the bios picked
06:14 airlied: boot vga
06:14 Kayden: aha
06:15 Kayden: makes sense
07:12 Kayden: figured out more on that, apparently for mutter you can make a udev rule that makes it pick the preferred primary device: ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary"
07:12 Kayden: otherwise meta-renderer-native.c's choose_primary_gpu_unchecked picks the integrated GPU, then the boot VGA device, then any device
07:13 Kayden: apparently things don't work right if I set it to use my DG2 as the primary device and the integrated card as the secondary
07:13 Kayden: but if I have integrated as primary and DG2 as secondary it works fine
07:14 Kayden: sounds like in the broken case I'm probably allocating buffers wrong in iris or somewhere in the winsys code
07:15 Kayden: but for the people that got me looking at this, probably they ought to figure out why it's picking DG2 as the primary device, since that's almost assuredly not what they want.
07:16 Kayden: probably bios bugs (:
07:28 mareko: what if I told you that I have a WIP linker optimization that makes GLCTS take 30% less time on our hw
07:28 Kayden: \o/
07:28 Kayden: does it delete half the tests
07:28 mareko: it doesn't
07:29 Kayden: (some tests can be really stupid) :)
07:29 Kayden: nice work!!
07:29 mareko: what helps is moving code from FS to VS
07:29 Kayden: oh awesome
07:29 Kayden: I've always wanted to do that
07:30 Kayden: if you've got basically uniform code in your FS, running it in the VS ought to be less iterations of it running (assuming more pixels than vertices, which is mostly true)
07:30 mareko: yes
07:30 Kayden: (Civilization VI's 3 pixels wide multi-thousand-vertex polygon meshes for cows not withstanding)
07:48 mareko: Kayden: this is how it works right now, and this specific optimization (one of several) is about 85% done while passing all tests: https://gitlab.freedesktop.org/mareko/mesa/-/blob/nir-opt-varyings/src/compiler/nir/nir_opt_varyings.c?ref_type=heads#L128
08:00 airlied: sima: want to jump on the vkms locking thread before anyone gets hurt?
08:00 airlied: i think the last post might make tglx implode
08:00 sima: uh
08:11 sima: mairacanal, ^^ ok I looked a0e6a017ab56936c0405 needs to be reverted asap, can you pls push that with my acked-by and links to all the discussion?
08:11 sima: mairacanal, we can then chat here about everything else that we should do to sort this out properly
08:12 sima: mairacanal, pls make sure the revert lands in drm-misc-fixes asap, before mripard or tzimmermann (not sure who's on -fixes duties) send the drm-misc-fixes pr today
08:13 tzimmermann: mairacanal, i want to send the PR today, but I can wait a bit
08:17 austriancoder:is looking for some tests that are using >1 draw buffer. I want to test out MRTs with different use cases. Maybe someone has a tip for me?
08:24 pepp: mareko: nice!
08:32 mareko: pepp: it won't be finished this week or next week like we talked about because I have more ideas for improvements
08:57 airlied: tzimmermann: if no patch arrives just hit the rrvert if u can
09:00 javierm: airlied: I believe that mairacanal is based in Brazil? So probably too early for her
09:02 tzimmermann: airlied, javierm, i can wait with the PR for a few more hours, if that's not too late for the drm-fixes PR
09:08 dolphin: airlied, sima: any thoughts on the DRM level netlink based RAS series from Aravind? He has been iterating and addressing feedback on the series for a while now, but an in-depth review would be great to gauge if we're heading to the right direction
09:08 dolphin: aravind: can you drop the link to the latest revision here
09:10 aravind: Hi please find the series: https://lore.kernel.org/dri-devel/20230825115531.800574-1-aravind.iddamsetty@linux.intel.com/
09:11 dolphin: airlied, sima: For refresher; https://airlied.blogspot.com/2022/09/accelerators-bof-outcomes-summary.html , when we discussed the RAS / monitoring
09:16 sima: aravind, on the code itself only really bikesheds, I'd drop DRIVER_NETLINK and just gate that on the presence of the ops structure or something
09:17 sima: DRIVER_ flags just tend to get out of sync or people forget to set them, so best to avoid unless actually required
09:17 sima: and also from a quick read-through of the xe code maybe more drm_netlink helpers would be good to send the stuff out correctly?
09:18 sima: but that's all bikeshed, imo the real important part is getting acks from other drivers that they are on board
09:18 sima: ideally in the form of patches
09:18 dolphin: the biggest concern raised so far is the fact that it uses netlink, but that was already discussed back in the day :) It's currently awkward for container use-cases, but as netlink sees more use, I think that needs to be addressed at netlink level
09:19 sima: yeah I think that was the conclusion from lpc, netlink isn't perfect, but it's less shit than the other options
09:19 dolphin: however, at least according to kubernetes folks, they don't even see a problem that the container reading the RAS telemetry would have to share networking with host
09:19 dolphin: so it's not a blocker even there without any improvements, just inconvenience
09:21 sima: yeah I think the only possible issue we might have is overlap with RAS reporting from the bus level, like some pci standards
09:21 dolphin: sima: thanks for comments, if you don't mind dropping some thoughts on the mailing list, maybe that will agitate some discussion
09:21 sima: but also all I've seen there is very far still, and further from gpus, so drm_netlink sounds like a fine thing even if it might end up being somewhat interim
09:22 dolphin: the PCI error reporting is indeed one thing, but it's really tough to get working right even on vendor supplied server setup, I can't even imagine a system where random user slaps together components
09:24 sima: dolphin, there's some RAS stuff that's a lot more than pci error reporting, trying to make device ras somewhat uniform
09:25 dolphin: yeah, but the mobo and the device would have to follow the spec :)
09:25 sima: the motivation seems to be to essentially extend the cxl stuff, since there you kinda need to know if part of your coherent domain went boom
09:25 dolphin: yep
09:26 sima: there's also the entire device poison stuff, but there's also a lot that's just a pile of abstraction layers and quite far away from actual pci
09:26 sima: but also, worst case I think we'll just do some glue in drm_netlink and expose these things in both places
09:27 dolphin: yeah, if such hardware support starts to appear, some code sharing should definitely be possible
09:28 aravind: sima, the reason I had DRIVER_NETLINK flag is the driver can choose to have their own netlink callbacks so they can skip the ops structure
09:29 sima: aravind, do you need that much flexibility?
09:30 sima: like there's always a bit tension in render/accel drivers on this, but in general if the consumer is generic userspace aim for more standardization
09:31 sima: and if the consumer is the umd, then allow full driver control
09:31 sima: netlink is the form, unlike e.g. vm_bind ioctl
09:31 aravind: ok ok
09:34 sima: another example, I think drm_info started out with a bit too much driver flexibility, hence also the question whether you should have more helpers to handle things to ensure drivers are consistent
09:34 sima: but that's all much easier to figure out with another 1-2 drivers using this
09:40 daniels: sima, airlied: for CI fixes (cf. vignesh's last series), should we be pushing into -misc, or set up a separate tree in drm-tip and send you PRs for it, or?
09:40 sima: daniels, it's in now, so normal process
09:41 sima: meaning here ask for backmerge into -misc-next, land there
09:41 daniels: coolio
09:41 sima: the less topic branches the happier maintainers :-)
09:42 daniels: I guess the one annoyance is that lighting up spq8016 requires a topic patch because DT/SoC people insisted that come in separately
09:42 sima: daniels, same for the vkms/vgem stuff that iirc koike was working on
09:42 sima: daniels, yeah but then just ask -misc maintainers to merge that dt topic branch into drm-misc-next
09:42 sima: otherwise if we'd just keep piling topic branches because previous topic branches it becomes endless
09:43 daniels: sounds good!
10:14 haasn: GL_RGB16_SNORM does not survive upload/download roundtrip on my end. GL_RG16_SNORM and GL_RGBA16_SNORM work fine, so does GL_RGB8_SNORM
10:14 haasn: (mesa amdgpu GL)
10:14 haasn: Probably whatever shader mesa is using internally to emulate support for this upload path is broken in either the upload or download direction
10:15 haasn: https://0x1.st/VA.txt
10:15 haasn: it seems correct in some places and wrong in others
10:15 haasn: random parts of the downloaded buffer are simply replaced by 0
10:21 haasn: https://0x1.st/VX.txt spotted this which seems odd
10:22 haasn: especially comparing to the other 3-component formats
10:22 haasn: is there any way I can easily run a GL app against in-tree build of mesa without restarting my whole compositor?
10:23 _jannau__: hashar: meson devenv from the build dir
10:23 _jannau__: err haasn ^^^
10:23 _jannau__: sorry for the unintnded mention
10:25 hashar: _jannau__: no worries!
10:25 hashar: I merely joined when I once attempted to tweak a kernel driver, but interested has fanned out and I will revisite later. I am idling there as to not forget this channel exist :)
10:26 haasn: _jannau__: huh, is that just settling the ol. LD_LIBRARY_PATH et al?
10:26 mairacanal: sima, just sent the revert to the ml, should I push it to drm-misc-fixes?
10:27 _jannau__: hashar: no worries, my fault. typo + tab completion
10:28 _jannau__: haasn: I think it sets LIBGL_DRIVER_PATH as well but it will use mesa and drivers from the build dir
10:30 haasn: yikes, llvmpipe doesn't even handle r8s correctly
10:30 haasn: turns all negative numbers into 0 it seems
10:30 haasn: what a headache
10:30 haasn: seems like SNORM formats are just fundamentally broken in mesa in multiple places
10:31 sima: mairacanal, yes please, and then tell tzimmermann when it's done
10:41 mairacanal: sima, can I push it without the patchwork link? the e-mail hasn't appeared on lore/patchwork yet
10:43 sima: mairacanal, you can add the link yourself, it's just the message id after all from lore or patchwork
10:43 sima: mairacanal, just feed the copy you have in your own mailer into dim
10:44 sima: dim doesn't actually check whether the link exists, it just builds it from the msg-id
10:45 sima: mairacanal, wrt the actual bugfix, I think a new vkms_composer_oneshot() interface for writeback, tracked separately from enabled state that the crc code uses, and automatically cleared in the hrtimer, is probably the right fix
10:46 sima: I'm not sure yet whether it needs to be a boolean or whether it needs to be a counter, to make sure we're not losing any writeback composition
10:46 sima: but mixing up writeback and crc composer state is I think the underlying bug here
10:47 sima: or if writeback is meant to be continuous, then we need separately tracked enable requests for them
10:49 sima: hm seems to be oneshot
10:54 mairacanal: sima, tzimmermann, the revert was pushed to drm-misc-fixes
10:54 tzimmermann: mairacanal, thanks
11:03 kode54: still waiting for someone to examine how a D3D11 game can crash DG2
11:03 kode54: but only with the new kernel driver
11:42 mareko: Kayden: regarding uniform code in FS, I would just move it to the CPU instead of VS
11:47 tzimmermann: sima, airlied, can you please pull https://cgit.freedesktop.org/drm/drm-misc/tag/?h=drm-misc-fixes-2023-09-07 ?
11:47 tzimmermann: it appears to still be missing from drm-fixes
12:02 alyssa: mareko: nir opt preamble is probably a better answer for that
12:02 alyssa: or
12:02 sima: tzimmermann, it's compiling
12:02 alyssa: sgpr salu if your hardware has that
12:03 alyssa: for truly uniform work
12:03 alyssa: but
12:03 alyssa: ymmv i guess
12:05 alyssa: Kayden: ^^
12:07 sima: tzimmermann, pushed
13:41 sima: mripard, maybe for the kunit tests that are combinatorial explosions, trying to split into per-test patch (or group of tests) would be good so the overall thing isn't hung up in objections against removing a specific test?
13:41 sima: been there, done that ... :-)
14:00 mripard: yeah, that's what I wanted to do
14:01 mripard: even more so since we could come up with unit tests equivalent to the ones raising objections
14:44 mareko: alyssa: doing it on the CPU would still be much more efficient than sgpr salu
14:46 mareko: alyssa: nir_opt_preamble would only be for UBOs, but the CPU can do it better for uniforms
14:49 alyssa: fair enough
14:57 cmarcelo: for freedreeno, do we need to use the wrapdb and download code even in linux builds, or is there a way to ask it to use the system version of the libraries?
15:00 HdkR: cmarcelo: Probably want to re-ask that question once this netsplit comes back in a few minutes
15:01 cmarcelo: HdkR: tks. yeah, realized right after I sent the message (-:
15:07 cmarcelo: for freedreeno, is there a way to ask meson to use the system version of the libraries instead of downloading them with the wrapdb mechanism? (I was surprised the default build was to touching the network)
15:08 danylo: markco ^
15:10 markco: It should only do that as a fallback if meson can't find the dependency but in any case, this can be disabled with `--wrap-mode=nodownload` (as stated in https://mesonbuild.com/Subprojects.html#commandline-options)
15:11 cmarcelo: markco: thanks. that flag seems what I was looking for
15:11 markco: Great :)
16:38 robclark: hmm, with deqp (surfaceless platform).. why can't I get a (non-fbo) 565 config?
16:41 mareko: multiplications by inf are killing me, I can't move them from FS to VS across interpolation
16:42 mareko: interpolation always converts infs to nans
16:44 mareko: I need to allow "inf * anything = nan"
16:46 idr: mareko: Probably because at some point the interpolator multiplies with 0. Only 0*Inf should be NaN.
16:46 idr: Anything else /should/ be ±Inf.
16:46 mareko: idr: also inf - inf
16:46 idr: Right... I be that happens at some point during interpolation.
16:47 idr: *I bet
16:47 mareko: interp(v, i, j) = v0 + (v1-v0)*i + (v2-v0)*j
16:53 cheako: Hi, I did this thing I regret and moved firefox into flatpak... but now I have no control over what mesa is being used and can't test out git builds. Does anyone have a solution? https://gitlab.com/freedesktop-sdk/mesa-git-extension/-/issues/22 also is there any way to get information out of FF about what GL and vuapi/whatever it's using?
16:55 mareko: yes, though I don't remember how, also if google maps don't have the 3D view, you have no accel or llvmpipe
16:55 psykose: about:support has Graphics which has what you want
16:55 psykose: i think
16:56 mareko: flatpak, snap, etc. are great for losing GPU accel
16:57 cheako: about:support is it and yeah no accell for me.
16:59 robclark: so.. if mesa is avail as flatpak sdk you could use $FLATPAK_ENABLE_SDK_EXT I think.. at least I did similar to get llvm avail in vscode flatpak
17:03 Kayden: bundling drivers in app packages, what a disaster
17:15 mareko: I wonder if inexact in NIR allows "inf * anything = nan"
17:21 zmike: mareko: can I get tc acks on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25227
17:25 idr: mareko: I was going to suggest... for interpolated things that you decide not to interpolate, you could put a (x*0)+x or something else that would for Inf to NaN at the start of the fragment shader.
17:31 mareko: that's a good idea
19:34 zf: is gfxreconstruct capable of capturing traces that don't actually present anything?
19:35 zf: or, well, it seems that it is, but I'm not sure if they can be usefully analyzed?
20:40 lumag: pinchartl, Hi. Can I ping you regarding https://lore.kernel.org/dri-devel/20230817145516.5924-1-dmitry.baryshkov@linaro.org/ ? You asked regarding the drm bridges in PHY and USB drivers. We tried to explain the reasons, but haven't heard back from you.
20:44 pinchartl: lumag: thanks for the ping, I'll give it a look
20:44 lumag: pinchartl, thanks!
21:17 soreau: trying to use AMD_DEBUG=useaco with a glesv2 wlroots compositor gives these errors: ac_rtld error: !ehdr \n ELF error: invalid `Elf' handle \n LLVM failed to upload shader \n EE ../src/gallium/drivers/radeonsi/si_state_shaders.cpp:2491 si_build_shader_variant - Failed to build shader variant (type=0)
21:17 soreau: is this meant to work?
21:19 soreau: GL renderer: AMD Radeon RX 580 Series (polaris10, LLVM 15.0.7, DRM 3.49, 6.1.0)
21:25 kisak: radeonsi/aco is pretty experimental right now. I doubt yuq825 has looked at gles at all yet.
21:29 soreau: kisak: ok, thanks
21:33 lumag: konradybcio, robclark: who would be the best person to ping regarding zink? We are observing segfaults when running zink+turnip as well as zink+llvmpipe.
21:33 lumag: E.g. I can get basic gnome and gnome-terminal to work, but gnome-control-center segfaults
21:33 HdkR: I offer zmike for tribute
21:34 zmike: oh no
21:35 lumag: konradybcio, robclark: initially I suspected turnip (of course :D), but after reproducing this with llvmpipe I started looking at zink with kind of suspicion. This is on the 23.3.0-to-be branch.
21:37 zmike: what kind of crash
21:41 konradybcio: lumag if you catch strace and renderdoc you may just be the main character of the next SGC story! :D
21:42 lumag: zmike, I don't have a proper debug-enabled function trace yet. I should have it tomorrow
21:44 pinchartl: lumag: done
21:44 lumag: current valgrind trace goes into zink-dri.so, with the error being the 'read of size 8'.
21:44 lumag: pinchartl, thanks!
21:47 pinchartl: you're welcome
22:15 markco: Wanted to report a known issue with the libarchive from meson wrapdb, it seems at some point libarchive added `AC_CHECK_TYPE`/`AC_TYPE_SIZE_T` checks which were done redundantly by the meson wrap script causing them both to redefine missing types such as `id_t` twice that can cause compilation errors. I'll fix this up in Mesa tomorrow but wanted to document it in-case anyone runs into it, just stick to using system libs for now.
22:16 markco: A temporary workaround would be removing the following lines from `subprojects/libarchive-3.7.1/meson.build`: https://github.com/mesonbuild/wrapdb/blob/2db326f6a788ff4bfefe91ff53c362a4a650fc63/subprojects/packagefiles/libarchive/meson.build#L159-L175
22:47 soreau: kisak: FWIW, with MESA_SHADER_CACHE_DISABLE=1, the compositor runs correctly despite those messages (with wayland backend at least, haven't tried with drm)
22:52 soreau: but there is an intermittent bug using radeonsi with or without aco (but maybe the offending shader is still using llvm), where sometimes, one of the texture frames of a toplevel is completely transparent, causing a flicker during unminimize animation with alpha blur shader enabled. This does not seem to happen with zink+radv
22:53 soreau: I tried to trace it with apitrace but it doesn't replay with eglretrace, and renderdoc can't even get a trace
22:54 soreau: debugging the compositor, everything seems sane, there are no mesa errors, even with a mesa debug build and setting MESA_DEBUG=1
22:55 soreau: so it feels like a driver/llvm bug, but I'm not sure how to report it since it's intermittent and not reproducible by others
22:56 soreau: but I am able to reproduce it locally quite easily, with wayland and drm backends
22:58 soreau: I used GALLIUM_TRACE but I'm not sure if it shows anything since I am unsure how to read it