08:52 jfalempe: tzimmermann: I plan to push the G200_eh5 patch to drm-misc-next this morning.
09:38 tzimmermann: jfalempe, was there an update on the limit.h thing?
09:38 tzimmermann: jfalempe, i'm ok with either, but would prefer your suggeestion
09:38 jfalempe: tzimmermann: Yes he sent a version with #include <linux/limits.h>
09:39 tzimmermann: great
09:39 tzimmermann: i must have missed it
09:39 tzimmermann: please go ahead
09:39 jfalempe: tzimmermann: ok thanks
09:40 tzimmermann: thanks a lot
09:45 tzimmermann: sima, airlied, mripard, mlankhorst, hi. can we discuss moving accel/ out of drm-misc ?
09:46 tzimmermann: i'm preparing the drm-misc-next PR and get series like https://patchwork.freedesktop.org/series/143182/
09:47 tzimmermann: i have no idea what this is or what is important
09:47 tzimmermann: it's just "patches for 6.14"
09:49 tzimmermann: hence, i'd like to move accel out of drm-misc. it would still go through drm, but be handled by the accel devs. they would know what the PR should contain
10:17 tzimmermann: and then i got https://patchwork.freedesktop.org/series/144101/ which is "patches for 6.15"
11:44 mripard: tzimmermann: I don't necessarily disagree, but I don't see why it's called for either. It looks to me that what you're saying is that they don't really follow the software practices the rest of the kernel follows and it makes it harder for you
11:44 mripard: I'm not disputing that, I also struggle with it
11:44 tzimmermann: mripard, indeed
11:44 mripard: but the solution could also be that they just stop?
11:45 mripard: I mean, even if they do get their own tree it's going to be problematic :)
11:45 tzimmermann: but it's their problem then
11:45 tzimmermann: now i got https://patchwork.freedesktop.org/patch/635256/
11:45 tzimmermann: again for ivpu
11:47 tzimmermann: mripard, i don't see why i/we should figure this out. let someone with accel/ expertie write the PRs. airlied and sima will then receive more meaningful RPs
11:47 mripard: we shouldn't, but we could try to tell them it's an issue for us
11:48 mripard: but also, I'm pretty sure I don't understand 50% of the patches I need to write a description for (accel excluded), you can't really understand all of them anyway
11:48 tzimmermann: mripard, honest question: why do we want to keep accel in drm-misc? what's the benefit?
11:50 mripard: to us? not much I guess. We do share the mm handling code though iirc
11:50 mripard: but I'm not sure it's the right way to frame it
11:51 tzimmermann: in the current drm-misc-next PR of ~200 patches ~20% are in accel
11:51 mripard: what's the benefit in keeping rcar-du, or omapdss, or most other drivers in drm-misc?
11:51 tzimmermann: that seems enought for a separate tree
11:53 tzimmermann: the benefit of keeping small graphics drivers (rcar-du, omap, etc) is that they have a significant overlap with the DRM core/helpers we keep in drm-misc. that's not the case for accel/ AFAICT
11:55 tzimmermann: another issue is the apparently missing review process for these patches. https://patchwork.freedesktop.org/series/144289/ is just pathces with r-bs. there's not even a public r-b email reply
11:57 sima: tzimmermann, it's mostly that we don't have a pile of surplus maintainers, so everything lands into drm-misc
11:57 sima: I'm also hoping that more collaboration with other small render drivers can happen, which are in drm-misc
11:57 sima: but yeah display side it's not relevant
11:58 sima: tzimmermann, and yes currently accel is a bit a disaster, I'm hoping for influence through osmosis. if we wall of accel into it's own thing it's pretty much guaranteed to stay a mess
11:59 sima: tzimmermann, I guess you could reply to that patch series that you need more meaningful cover letters and commit messages, I think that's a fair demand
11:59 tzimmermann: sima, don't get me wrong. i don't complain about my workload in drm-misc-next. if maintainers of small drivers need a git tree, i'm happy to offer them drm-misc. my complaint is the low effort that goes into making the kernel's processes work for accel/
11:59 sima: what do you mean with low effort?
12:00 tzimmermann: sima, it's not like i didnt complain to them before
12:00 sima: hm I guess time for me to follow up?
12:00 tzimmermann: 'low effort' in the sense that there's no public review process, no cover letters, not meaningful patch series
12:00 sima: yeah that's not great
12:01 sima: can you drop that again onto their latest patch set, and I'll reply with support?
12:01 sima: like I said, I think it's fair to expect committers to write meaningful enough commit messages and cover letters that writing reasonable summaries is doable
12:01 tzimmermann: sima, i'll send out something
12:02 sima: thx
12:07 javierm: sima, tzimmermann: their patch series are really PRs in disguise AFAICT
12:07 javierm: as tzimmermann said, a bunch of patches with existing r-b that were not given in public MLs
12:08 sima: javierm, yeah I know. the entire accel adventure is an exercise in lowering standards to the basement and then trying to lift them all up
12:09 javierm: sima: got it
12:09 sima: we might just pile up our next dri1 here, but the chance that there's something good long term is imo worth it
12:09 javierm: yeah, agreed
12:09 tzimmermann: javierm, sort of. it would be acceptable if these cover letters would clearly state what they contain. i could then copy them into the actual PR. if there's been a public review of any of these patches, i'd like to have an indication of where to look
12:11 sima: plus with amd's accel driver there's now actual chance for cross-driver peer review, so I think it's time to start pushing for that
12:14 sima: it took a while to get the drm-misc review tit-for-tat economy for kms&render drivers going too, with quite some pain too
14:51 mlankhorst: lumag: should be ok, or do you need an ack?
16:43 DemiMarie: Is one of the problems with accel the lack of cross-vendor userspace? I know that for at least some drives the open source userspace is not meant to actually be used, and what gets used in production is the blobby version.
16:44 sima: DemiMarie, that's part, but it's kinda way down the list of issues we need to start with
16:44 sima: just some collab in the kernel would be great to start I think
16:44 DemiMarie: sima: what is at the top?
16:49 sima: DemiMarie, the next line about better collab in upstream kernel I think, that's probably the easiest place to start
16:56 sima: mlankhorst, [PATCH 00/12] drm/{i915,xe}: Convert to DRM client setup <- maybe for you?
17:05 sima: tzimmermann, I didn't see a ivpu reply from you where I can double down?
18:04 mlankhorst: sima: lets see
20:50 fufexan: Hi! I'm trying to run Hyprland headless in a QEMU VM with only /dev/dri/card0. By default, Hyprland scans /dev/dri for a card to render on, but I'm not sure the card it finds works as an accelerated 3D renderer. I get the following message in journalctl when I try to run Hyprland, and I'm wondering if it hints at an issue: `libEGL warning: Not allowed to force software rendering when API explicitly selects a hardware device.`
20:51 fufexan: FWIW, I've already set `LIBGL_ALWAYS_SOFTWARE=1`, hoping it would help.
20:52 fufexan: Oh and Hyprland crashes. Not sure what else to try or if my setup is wrong. Would appreciate any help.
20:52 soreau: I think if there's no render node, you have to use some buffer creation other than the usuals, like udmabuf
20:54 soreau: wlroots recently has the bits needed for a udmabuf allocator and it can be used to run e.g. wayfire headless without a render node, while the compositor uses (gles) llvmpipe software rendering
20:58 fufexan: oh, interesting. so I guess there's no way to fake a card using llvmpipe? (apologies if I've just said an atrocity, still learning about how llvmpipe compares to physical cards)
20:58 fufexan: also /dev/dri/renderD128 does exist (along with card0)
21:01 soreau: I think vgem exists but YMMV