07:26 MrCooper: DemiMarie: RHEL generally updates to current upstream kernel DRM drivers and Mesa release for every minor RHEL release, which happens every six months
07:27 MrCooper: (up until around x.10, i.e. for ~5 years per major release)
07:41 eric_engestrom: quick reminder: mesa 24.1 branchpoint is in 2.5 days, Wed 24 @ 18:00 UTC :)
08:06 dj-death: how do people run CTS with Angle?
08:07 dj-death: do you need to build CTS in a particular way?
09:06 eric_engestrom: dj-death: I have no experience with it, but looking at the CI it builds it like this: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/.gitlab-ci/container/build-angle.sh and then `export LD_LIBRARY_PATH=/angle:$LD_LIBRARY_PATH` before running deqp-runner; perhaps that last step is what you were missing?
09:07 dj-death: eric_engestrom: no, I have that
09:07 dj-death: eric_engestrom: my problem is that CTS/dEQP picks up libGL.so
09:07 dj-death: which angle doesn't provide
09:07 dj-death: so it always loads my system/dev mesa build instead of angle
09:08 dj-death: if CTS was loading libGLESv2 instead, then that would be okay I guess
09:09 eric_engestrom: is it a glvnd/non-glvnd mismatch?
09:09 dj-death: not sure :)
09:10 eric_engestrom: are you running through `meson devenv` or manually setting up variables?
09:10 dj-death: manual setup
09:10 eric_engestrom: try devenv? ^^
09:11 eric_engestrom: https://docs.mesa3d.org/install.html#running-against-a-local-build-easy-way
09:28 dj-death: eric_engestrom: not helping unfortunately
09:28 eric_engestrom: nothing else I can offer, except "good luck" 🙃
10:37 lumag: robclark, DavidHeidelberg I've looked for a place to install lxml for drm/msm build, but I couldn't find a suitable place for it, I don't see pip installs in drivers/gpu/drm/ci. Whould you have any suggestions or points that I could have missed?
11:31 tomeu: lumag: iirc, CI uses the debian package for it
11:31 tomeu: not the wheel
11:32 lumag: tomeu, so I can just add apt insall python3-lxml to drivers/gpu/drm/ci/build.sh? That's nice, thank you!
11:38 tomeu: I think so, yes
12:23 mwalle: airlied: through which tree should bridge changes go? i.e. https://lore.kernel.org/r/D09FZ0P0ARBE.1YPEPPM160VJK@kernel.org/ there was no reponse for months now :/
12:49 mairacanal: sima, mripard, airlied, tzimmermann, I have this V3D series (https://lore.kernel.org/dri-devel/20240420213632.339941-2-mcanal@igalia.com/T/) that has a fix for a GPU stats series that already landed on mainline, but the fix is quite large (like 5 patches large). Currently, I'm in doubt if I would push this series to drm-misc-next or drm-misc-fixes.
12:49 mairacanal: I believe it is a bit large to drm-misc-fixes, right?
13:01 sima: mairacanal, I'm assuming the issue is small enough in practice to not matter that much? if that's the case I'd skip -fixes since it's just perf data not being entirely perfect
13:01 sima: for more serious stuff pushing to -fixes is fine, even if it's kinda big
13:01 sima: as long as it's not unnecessarily big
13:47 mairacanal: thanks sima
13:50 sima: mairacanal, I think if you have some perf tool that crashes because stats go backwards, that's different and would definitely be a good enough reason to include the patch set in -fixes
14:23 mairacanal: i see, yeah, this issue is mostly a theoretical issue that we didn't see happening, so it is okay to push it to -next
14:34 DavidHeidelberg: lumag: as tomeu said 😉
14:39 vignesh: lumag, DavidHeidelberg, tomeu : I added in mesa https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27088 and upreved mesa in drm-ci
14:46 mairacanal: sima, btw do you know when drm-misc-fixes will be backported to drm-misc-next? just noticed that i need only commit from -fixes to apply my patches
14:47 sima: mairacanal, ask drm-misc maintainers for a backemerge with the reason/commit you need
14:47 sima: it's a bit a on-demand thing, since linus doesn't like backmerges without reasons
14:49 mairacanal: actually, it is a commit that i pushed to -fixes last week
14:52 sima: mairacanal, it needs to be in an -rc release first
14:52 mairacanal: okay, thanks!
14:52 karolherbst: Plagman: yeah.. so I get 10 fps on my intel GPU vs 70 on my i7-10850H.. so might not even be a problem with discrete GPUs
14:54 cmichael: I have a couple of small patches for broadcom-rpi4-fails.txt , but gitlab is not allowing me to create a new MR for some reason :/ (does not even provide the option in the WebUI)
14:56 karolherbst: Plagman: getting 70 with the official intel driver
14:56 karolherbst: and almost no CPU usage
14:56 karolherbst: well.. "almost"
14:56 karolherbst: less then with CPU
14:58 karolherbst: only using one core instead of... a lot
14:58 karolherbst: anyway, will do a release build and see what I can do
17:03 Plagman: yeah - there's small sections with tons of parallelism on CPU, then small GPU compute sections, then a giant long-running CPU thread that barely does anything holding everything up
17:24 Plagman: wait how do you get 70 on your i7? :thonk:
17:25 Plagman: maybe the avx stuff is tuned for intel too? :/
17:26 karolherbst: maybe?
17:26 karolherbst: it uses like 30% of my CPU only even
17:26 Plagman: mine was literally using 40 cores to get 40fps
17:26 Plagman: maybe too much paralllism
17:26 karolherbst: maybe :D
17:38 karolherbst: it seems like it's constantly creating kernel objects or something.....
17:38 karolherbst: I should let it run for a couple of minutes and see what silly stuff it's doing
17:51 karolherbst: 6% time is spend in releasing cl_kernel objects.. oof
17:51 karolherbst: and 22% in creating them
17:51 karolherbst: I have questions...
17:53 karolherbst: it sounds like the application/library is indeed written in a very very trashy way
17:53 karolherbst: why...
17:53 karolherbst: but maybe those APIs are supposed to be cheap
18:08 karolherbst: okay anyway... I think I have two spots I should reduce the CPU overhead first and see what that will give me
18:12 Plagman: i think bnieuwenhuizen was also looking as possibly improving the app-side, attacking it from both ends seems great if possible
18:13 Plagman: although i remember now he was looking at their vulkan backend and not the CL one, nvm..
18:13 bnieuwenhuizen: yeah, sorry, it was kinda predictable what I would get nerdsniped by :P
18:14 bnieuwenhuizen: karolherbst: looks like they invented their own ONNX runtime in opencv
18:15 bnieuwenhuizen: on the CL side it may have been some flag weirdness as both clvk and rusticl had the slow readback
18:16 karolherbst: yeah...
18:16 karolherbst: I'll deal with the CPU overhead nonsense first, because it's just API validation being.. annoying and it's not hard to fix, but if I have to do something different on a gallium level that would also help to know