02:47grandarchitect: they are talking alot of crap, this anal whore only cheated and consumed baby pills from the very first day also hormone treatments for stis. thats a monster trash, now the surgery was indeed done to my throat where jews hijacked my penis along with stem for all major hepatitis and aids vaccines etc. but this was just wrong diagnosis by jews with my terror family actual happening was a
02:47grandarchitect: focused beam was trabsferred at me when i was 9years to 11 or so and i got brain injured badly i also fell to the floor like they joked nicely somewhere there i had issues and andrus murumets same as i never broke his chestmuscle to weight either it was beamed just like my armrestling hand, cause i have toughest bones possible, and terror such as hostaging was organized by my dad and
02:47grandarchitect: rest of the family with many estonians involved who denied my approaches to get also any devices, those chips are all jewish ways and traditions to vampire or and leech others resources against active laws, but others bragged and whitnessed this all up i am the toughest man I n the planet almost cause i am the most conspired and terrored person but still active, lance armstrong had
02:47grandarchitect: these same setup as i had, cancer was result on genitals and brain. but i was the hugest star but valued as nothing by estonian and jew scammers i would not had this luxury to get any proper surgery however i did not develop cancer but just tissue that was not functional, i saw live on video how i got butchered second time from muscle, first time on bone. name is mart martin ex sports
02:47grandarchitect: hero. never did nor spoke bad to jews, they just took with estonians the most loved person to hostage, they get all the needed terror back.
02:48grandarchitect: first mention about jews doing this was 2021
03:00mattst88: https://bugs.gentoo.org/948591
03:00mattst88: does nouveau require -Dlegacy-x11=dri2?
03:01mattst88: I didn't see anything in the MR that added it (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29969) indicating that it was expected to break anything
08:41karolherbst: mattst88: only when the xorg driver doesn't support dri3
08:42karolherbst: which is the case with the nouveau ddx
08:42karolherbst: well.. it does support dri3, but it's not enabled by default
08:48pochu: zmike: hi, if you have any ideas or pointers on how to debug https://gitlab.freedesktop.org/mesa/mesa/-/issues/12452, that'd be much appreciated
10:01chewitt: Morning all .. I am a platform maintainer for the LibreELEC distro focussed on Kodi mediacentre
10:02chewitt: I'm looking for some help investigating a mesa/nouveau issue
10:02chewitt: Software environment is Linux 6.12.10 with mesa 24.3.3 and most other OS packages in a current/latest state
10:02chewitt: Hardware is Intel x86-64 with an nVidia GeForce 6100 card using nouveau
10:02chewitt: Kodi runs in GBM mode, so there's no windowing environment like Wayland/Xorg involved
10:02chewitt: Kodi starts, initiates an EGL context, then does a mode change/reset which appears to invoke a dri_flush
10:03chewitt: at this point the nouveau driver reports errors in the system log, and Kodi segfaults
10:03chewitt: Kodi log with backtrace (at the top of the file): https://paste.libreelec.tv/proper-rat.log
10:03chewitt: System log with some debug output (search on 'ERROR'): https://paste.kodi.tv/utikokoyic
10:03chewitt: Kodi has been started with NOUVEAU_LIBDRM_DEBUG=1, NOUVEAU_DEBUG=1, EGL_LOG_LEVEL=debug enabled
10:04chewitt: I'm not experienced with mesa debugging so no idea if those are the correct options to set ??
10:05chewitt: I'm also not the person with the hardware to test, so looking for guidance on what (more) info would be helpful ??
10:05chewitt: (so that I can pass instructions to someone with the hardware)
10:19chewitt: for experimentation purposes I've also tested with Linux 6.6.70 and mesa 24.0.9 and the issue is present there too
10:21chewitt: i've also tested a distro image that does use X11
10:21chewitt: this generated "kodi.sh[1126]: libEGL warning: egl: failed to create dri2 screen" and "kodi.sh[1126]: glx: failed to create drisw screen"
10:22chewitt: then "kodi.sh[1126]: ERROR: Can not initialize OpenGL context. Exiting"
10:23karolherbst: chewitt: you need the legacy-x11 option in mesa or have to stop using the nouveau X driver
10:23karolherbst: or well...
10:24karolherbst: support dri3 generally
10:24karolherbst: if kodi is the windowing environment it should probably move away from dri2
10:25chewitt: we run without a windowing environment using GBM (I might not be describing this properly..)
10:26chewitt: and dri3 is currently disabled in the mesa config
10:26chewitt: we enable it for X11, but not for wayland or 'none' (GBM) images
10:28chewitt: our general goal is to avoid using X11
10:30karolherbst: well.. if you use glx, you also use dri
10:31karolherbst: and for EGL it kinda depends how you use it
10:32chewitt: we use GLES not GL in the GBM image
10:32karolherbst: doesn't make a difference
10:32chewitt: the X11 image uses GLX
10:32karolherbst: right.. so with the X11 image you'd need to use dri2 with the nouveau ddx (or enable dri3 there)
10:33karolherbst: dri2 meaning the x11-legacy option
10:33karolherbst: ehh legacy-x11
10:33karolherbst: with EGL it depends what windowing system is used
10:33chewitt: none :)
10:34lynxeye: chewitt: Seems like the GPU doesn't like the pushbuf due to an invalid render target format. I would guess the framebuffer isn't properly set at the time of the flush and the userspace driver just flushes the current (invalid) state, which has the GPU grumpy.
10:35karolherbst: lynxeye: yeah.. but that's the vaapi/vdpau side of things
10:35chewitt: the distro boots fast, but I can see that drivers have probed/loaded before Kodi runs
10:35chewitt: we do have mesa built with libva support
10:35karolherbst: mhhh maybe not
10:35karolherbst: 4497 is 3d...
10:35lynxeye: yep...
10:37chewitt: if the render target format is invalid, what would a valid one (or ones) be?
10:40karolherbst: maybe I shouldn't work while getting sick :'(
10:41sima: Lyude, I guess we should move vkms to subsys_virtual_register?
10:42sima: imre, also just noticed that dev_set_uevent_suppress() is a thing, I guess we could/should use that to fix the connector registration races we've discussed?
10:43sima: Lyude, doesn't look like too much typing at least on the C side to put vkms devices into a vkms virtual bus
10:45karolherbst: chewitt: so yeah anyway.. my answers were more related to the later errors, like with mesa-24.3.3 we require dri3 by default, and distros running X11 with the nouveau ddx won't provide that, so that explains the "create dri2 screen" warnings
10:47chewitt: so X11 with legacy-x11 (which brings dri2) should work?
10:48chewitt: or nouveau needs to evolve support for dri3?
10:48karolherbst: ahhh
10:48karolherbst: okay..
10:48karolherbst: I see what's going on
10:48karolherbst: chewitt: you can't use a linear frontbuffer with depth
10:49karolherbst: so you'd either have to use modifiers to use a nvidia specific layout
10:49karolherbst: or don't use depth
10:50karolherbst: yeah.. mesa compiled with legacy-x11 should work _when_ using the nouveau X11 driver, one can also use the modesetting one, but then it's using OpenGL and it might be too much of an overhead on those older GPUs
10:50karolherbst: there is a `DRI3` option tho
10:50karolherbst: and it should work in general
10:50karolherbst: `Option "DRI" "3"` if one has a xorg config
10:50karolherbst: but might be better to just patch it
10:51chewitt: dri3 is dependent on X11? or not?
10:51karolherbst: yeah
10:51karolherbst: it's only relevant for a x11 windowing system
10:51karolherbst: be it GLX, or EGL on X11
10:51karolherbst: the latter also includes xwayland, but that should always support dri3
10:52chewitt: the goal would be to not use X11 but that might need a tweak to how Kodi renders things
10:52karolherbst: anyway... I don't know _that_ much about EGL so I can't really tell what it makes nouveau using a linear image with depth, but the hw doesn't support that
10:52karolherbst: so if you scanout into a linear image with depth, that won't work
10:53karolherbst: can't render into it either
10:53chewitt: if there a way to understand that from querying EGL properties or such?
10:53karolherbst: if you don't use modifiers and it's a shareable resource, it's gotta be linear
10:54karolherbst: again, don't know exactly how that looks on the EGL side, but if the renderer and the scanout side don't handshake on modifiers, then the common fallback is linear (e.g. because in multi GPU scenarios it's the only thing always working)
10:55chewitt: gotcha
10:55karolherbst: I think gbm has some APIs related to that
10:55chewitt: I'm not sure what Kodi is doing here (not my area of expertise and I don't really code) .. but I will shanghai people that do :)
10:56karolherbst: and dma-buf and kms and ...
11:13MrCooper: AFAIK the EGL GBM platform uses optimal tiling by default, sounds like Kodi forces linear for some reason
11:15MrCooper: (side note, this is one of the silliest and most painful HW limitations I know of)
11:19karolherbst: yeah.. but there was a reason why nvidia was working on the buffer allocation stuff so many years ago, because they need it solved for tegra and stuff 🙃
11:20karolherbst: but yeah.. no rendering into linear depth images
11:37MrCooper: except it works fine without depth/stencil (and other non-linear colour buffers)
11:37MrCooper: I hope the few transistors they saved for this were worth the pain
11:43karolherbst: it probably was...
11:44karolherbst: there is quite a lot of special hardware in regards to depth buffers, so... wouldn't surprise me
11:45daniels: you parse the IN_FORMATS KMS property on the plane to get the acceptable list of modifiers for that format+plane, then pass the modifier list to gbm_surface_create_with_modifiers(), then that gets passed as the modifier list to DRI createImage
11:49MrCooper: karolherbst: I understand it's not specific to depth, mixing linear & tiled colour buffers doesn't work either
11:50karolherbst: mhhhhh, not sure if that's a hardware limitation
11:51karolherbst: but could be
12:08mairacanal: Hey, I’d like to push a patch that will fix a commit in drm-misc-fixes (drm-misc-fixes-2025-01-15). This commit landed in torvalds/master on 6.13. I’m having some doubts about where I should apply it, as the patch doesn’t apply to drm-misc-next-fixes or drm-misc-next. From the “Where Do I Apply My Patch?”, I’m not sure either, as the
12:08mairacanal: offending commit isn’t in drm-next as well. sima, mripard, tzimmermann, could you give me an idea about where I should apply it?
12:09sima: mairacanal, drm-next has a backmerge of v6.13, so if that gets backmerged into drm-misc-next-fixes it should apply there
12:09sima: tzimmermann, mlankhorst ^^
12:10lumag: sima, tzimmermann: any additional thoughts on https://lore.kernel.org/dri-devel/20241222-drm-dirty-modeset-v1-0-0e76a53eceb9@linaro.org/ ? Do you think that we should abandon the idea of a generic checker? If that's fine with you, I'd like to push a documentation patch to the drm-misc, split msm-specific changes into a separate serties targeting msm/next tree. Then we can continue discussing the helper-related changes separately.
12:11sima: lumag, yeah I'm worried about false positives, we already struggle with some of those in e.g. drm unit tests sometimes
12:11mairacanal: sima, I might be looking in the wrong place, I couldn't find my commit here: https://gitlab.freedesktop.org/drm/kernel/-/commits/drm-next?search=v3d
12:11sima: lumag, so for now I guess just try to improve docs until we get better ideas
12:11sima: mairacanal, oh right, airlied only backmerge v6.13
12:12lumag: sima, I see. But then we have almost-legit usecases as mgag200 pointed out by tzimmermann.
12:13sima: lumag, yeah that's kinda what I'm worried about
12:13sima: and similar patterns
12:13lumag: What would you think about adding atomic_needs_modeset()-like callback to be executed in the beginning of while evaluating connectors/CRTCs/planes drm_atomic_check_modeset()?
12:13lumag: in other words clearly documenting - this is the place where you can reevaluate your state.
12:14sima: lumag, not sure that helps, the idea very much was that it's all split up, so that drivers can stuff their own code in between
12:14sima: or run multiple times
12:14sima: if we only designate one place it's probably too strict
12:14sima: and more drivers would be forced to entirely hand-roll the entire mess
12:15mlankhorst: mairacanal: what is the exact commit you want to merge into next-fixes?
12:15mlankhorst: so I can provide it as justification for backmerge
12:15lumag: well, we can document that callback as a recommended place. Then at least mgag200-like drivers won't have to loop the call.
12:16mairacanal: The commit (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e4b5ccd392b92300a2b341705cc4805681094e49) and the patch that fixes the commit (https://lore.kernel.org/dri-devel/20250123012403.20447-1-mcanal@igalia.com/T/)
12:17lumag: But more complicated drivers still might do whatever is necessary. Basically that's what I had to implement for the msm driver - check it before calling into helpers.
12:17sima: lumag, maybe I don't get what you're proposing ...
12:19mlankhorst: mairacanal: good enough, feel free to push to next-fixes now :)
12:19mairacanal: Thanks mlankhorst!
12:19lumag: add a callback to CRTC / plane / connector helper_funcs, that will be called from drm_atomic_check_modeset() before adding 'affected' objects to the state. This way simple usecases (mgag200, msm) can be handled by such callbacks.
12:21sima: mlankhorst, did you check that your merge matches the one linus has done?
12:21sima: lumag, oh yeah now I get it
12:21sima: yeah I guess we could add that if there's a few drivers that would benefit
12:21sima: but if it's just one then I think looping is fine
12:24mairacanal: mlankhorst, drm-next doesn't have the commit as well
12:25mairacanal: I pull drm-misc-next-fixes and still it doesn't have the commit
12:25lumag: well, I gave you two :-D I think meson_encoder_hdmi and dw-hdmi should also be able to move drm_connector_atomic_hdr_metadata_equal() call to such a callback (and to a generic helper). The nwl-dsi upgrades active_changed to mode_changed (ugh), but it might also be better documented in a separate callback.
12:26lumag: cdns-mhdp upgrades HDCP events to mode_changed
12:27lumag: malidp does a proper job of calling helper_check if gamma-related props changed.
12:28lumag: and on the other side, drm_atomic_helper_connector_hdmi_check() does a bad job, it sets mode_changed w/o second thought.
12:29lumag: sima, anyway, is it fine to land the docs patch from that patchset?
12:30sima: lumag, yeah sure, I think I already put an r-b onto that?
12:30lumag: yep, just making sure :-D
12:30sima: lumag, and yeah I guess if we have a bunch of these and some more that get it wrong, then that sounds like a good addition
12:31sima: especially when that hook helps fix some existing issues
12:43tzimmermann: lumag, sima, mgag200 sets mode_changed specifically in the plane's atomic check because the crtc's atomic check runs later. that works in practice for such a simple hardware (i.e., 1 crtc + 1 primary plane)
12:43tzimmermann: but likely not for more complex setups
12:44lumag: tzimmermann, yes. almost-legit. For the reviewer it's hard to distinguish if the driver has only one plane or multiple planes (in which case they have to be added to the state and then atomic_check()'ed)
12:45tzimmermann: lumag, IIRC your patchset doesn't intentionally break any driver. it only tightens the rules and warns about it, right?
12:45lumag: yes
12:45sima: tzimmermann, you still need to re-run check_modeset() for that case though, which is what lumag's new hook would fix
12:46tzimmermann: lumag, that should be good enough for mgag200 for now.
12:47tzimmermann: sima, i haven't followed the series in detail. it would be good to have an auto-restart
12:47sima: tzimmermann, auto-restart is kinda hard since drivers might have their own stuff in there
12:48sima: between calls to helpers I mean
12:48sima: I did ponder auto-restart but hw that needs this is so varied it seemed like it would hurt more than it would help
12:49tzimmermann: sima, lumag, can't you restart the whole drm_atomic_helper_check() ?
12:49lumag: tzimmermann, well... malidp restarts it on its own.
12:49lumag: So I'd rather not
12:53tzimmermann: lumag, your patch already tests if mode_changed changes. why not flag the drm_atomic_state instance for a retest? why does that interfere with malidp?
12:54sima: tzimmermann, the implementation would need to be idempotent
12:54sima: which they are not necessarily
12:54tzimmermann: ok
12:54sima: by forcing driver writes to do the restart I'm hoping they're thinking about whether this is ok with all their callbacks
12:55tzimmermann: for now, i don't have a problem with updateing mgag200. it's not very large
12:56tzimmermann: but what is the long-term perspective of this?
12:56tzimmermann: what's the hook you mentioned?
12:57lumag: tzimmermann, I'm thinking of adding an extra hook that sets crtc_state->mode_changed early enough.
12:58lumag: Or rather makes drm_atomic_helper_check_modeset() set crtc_state->mode_changed
13:01tzimmermann: lumag, sima, could we have something like struct drm_mode_config_funcs.atomic_prepare that runs exactly once before atomic_check. it would allow to modify incoming atomic state. drivers could implement such tests there and set such flags before running the actual check
13:02lumag: tzimmermann, that's the point
13:02tzimmermann: well, ok.
13:07chewitt: lumag if you have any changes that cleanup meson/Amlogic DRM code feel free to ping/cc me for testing
13:07tzimmermann: lumag, ah! i see you have check_mode_changed in one of the patches. yeah, i think that's what i've been thinking of; but as part of the DRM framework instead of a single driver
13:09lumag: chewitt, no, not yet. I tried looking at meson for the CEC series, but I think I got stuck under the pile of changes there.
13:23mlankhorst: sima: oh, isn't post origin/master inside drm-next yet?
13:35sima: mlankhorst, oh did you backmerge origin/master?
13:35sima: that's no good, random in the middle of the merge window is no-go
13:36sima: mlankhorst, and yeah I haven't backmerged v6.13 yet, you jumped the gun
13:36sima: mlankhorst, want to force unpush that merge?
13:43sima: mlankhorst, build-testing now the merge that exactly matches what Linus' had
13:43sima: once I pushed it I think would be best if you drop your current backmerge and redo
14:04sima: mlankhorst, pushed
15:18sima: mairacanal, since the backmerge is kinda stuck (I guess mlankhorst is gone already) you can push it into drm-misc-fixes
15:18sima: since there's other stuff in there already anyway
16:10mattst88: karolherbst: ah, okay. thanks
16:13sima: mlankhorst, tursulin was just wondering whether we should require (and then with just docs or enforcement) that the dmem names agree with what fdinfo uses?
16:13sima: for drm drivers
16:14sima: since it's not yet shipping this is something we can still rectify
16:14sima: and if we go with that, would need links from fdinfo to dmem and the other way round I think in the main docs
16:38mlankhorst: Just a sec
16:39mlankhorst: I'm back now
16:40mlankhorst: should I undo previous merge or add it?
17:05mlankhorst: mairacanal: I overwrite my previous merge, you can do it now
17:15sima: mlankhorst, yup that's what I meant, thanks a lot
17:35tursulin: sima, mlankhorst: yep names should definitely match otherwise it will be a mess
17:36sima: tursulin, I guess this needs a doc patch then at least?
17:36sima: not sure how we can enforce this except maybe with helpers that take care of both
17:38tursulin: I am not up to speed with how dmem ended up in terms of uapi so don't know
17:38tursulin: can look at it tomorrow or so
17:47sima: tursulin, yeah it's not a rush, merge window only just started
17:47sima: just thought that this is something we better figure out and document before we ship dmem in the first release in 2 months
17:48tursulin: to be clear I don't propose I send a patch, just that I will look at how the dmem controller ended up looking
17:48tursulin: since I kind of missed it is happening in the mailing list noise
18:08sima: tursulin, could also volunteer mlankhorst for the patch I guess, but yeah first need to look at what should be there
18:29mlankhorst: tursulin: https://patchwork.freedesktop.org/patch/632661/?series=143593&rev=1 if you want to look at the api a bit
19:18mairacanal: Thanks mlankhorst and sima for the help! I just pushed the patch
21:56zmike: tarceri: not sure how busy you are these days, but https://gitlab.freedesktop.org/mesa/mesa/-/issues/12510 is very in your wheelhouse in case you have some time