ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
haaninjo has quit [Quit: Ex-Chat]
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
nirmoy has joined #dri-devel
glennk has joined #dri-devel
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
orbea has joined #dri-devel
heat is now known as Guest6714
heat has joined #dri-devel
Guest6714 has quit [Read error: Connection reset by peer]
CME has quit [Ping timeout: 480 seconds]
heat is now known as Guest6716
Guest6716 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
iive has quit [Quit: They came for me...]
CME has joined #dri-devel
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
oneforall2 has joined #dri-devel
ryanneph has quit [Ping timeout: 480 seconds]
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
heat is now known as Guest6722
Guest6722 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
sguddati has joined #dri-devel
grandarchitect has joined #dri-devel
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
The_Company has joined #dri-devel
u-amarsh04 has quit []
Company has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
amarsh04 has joined #dri-devel
grandarchitect has quit [Remote host closed the connection]
grandarchitect has joined #dri-devel
nirmoy has quit []
<grandarchitect>
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
<grandarchitect>
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
<grandarchitect>
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
<grandarchitect>
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
<grandarchitect>
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.
<grandarchitect>
first mention about jews doing this was 2021
grandarchitect has quit [Remote host closed the connection]
grandarchitect has joined #dri-devel
grandarchitect has quit [Remote host closed the connection]
<chewitt>
Kodi has been started with NOUVEAU_LIBDRM_DEBUG=1, NOUVEAU_DEBUG=1, EGL_LOG_LEVEL=debug enabled
<chewitt>
I'm not experienced with mesa debugging so no idea if those are the correct options to set ??
<chewitt>
I'm also not the person with the hardware to test, so looking for guidance on what (more) info would be helpful ??
<chewitt>
(so that I can pass instructions to someone with the hardware)
<chewitt>
for experimentation purposes I've also tested with Linux 6.6.70 and mesa 24.0.9 and the issue is present there too
<chewitt>
i've also tested a distro image that does use X11
<chewitt>
this generated "kodi.sh[1126]: libEGL warning: egl: failed to create dri2 screen" and "kodi.sh[1126]: glx: failed to create drisw screen"
<chewitt>
then "kodi.sh[1126]: ERROR: Can not initialize OpenGL context. Exiting"
<karolherbst>
chewitt: you need the legacy-x11 option in mesa or have to stop using the nouveau X driver
<karolherbst>
or well...
<karolherbst>
support dri3 generally
<karolherbst>
if kodi is the windowing environment it should probably move away from dri2
<chewitt>
we run without a windowing environment using GBM (I might not be describing this properly..)
<chewitt>
and dri3 is currently disabled in the mesa config
<chewitt>
we enable it for X11, but not for wayland or 'none' (GBM) images
lplc has quit [Quit: WeeChat 4.0.4]
<chewitt>
our general goal is to avoid using X11
lplc has joined #dri-devel
lplc has quit []
lplc has joined #dri-devel
<karolherbst>
well.. if you use glx, you also use dri
<karolherbst>
and for EGL it kinda depends how you use it
<chewitt>
we use GLES not GL in the GBM image
<karolherbst>
doesn't make a difference
<chewitt>
the X11 image uses GLX
<karolherbst>
right.. so with the X11 image you'd need to use dri2 with the nouveau ddx (or enable dri3 there)
<karolherbst>
dri2 meaning the x11-legacy option
<karolherbst>
ehh legacy-x11
<karolherbst>
with EGL it depends what windowing system is used
<chewitt>
none :)
<lynxeye>
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.
<karolherbst>
lynxeye: yeah.. but that's the vaapi/vdpau side of things
<chewitt>
the distro boots fast, but I can see that drivers have probed/loaded before Kodi runs
<chewitt>
we do have mesa built with libva support
<karolherbst>
mhhh maybe not
<karolherbst>
4497 is 3d...
<lynxeye>
yep...
lplc has quit [Quit: WeeChat 4.0.4]
<chewitt>
if the render target format is invalid, what would a valid one (or ones) be?
<karolherbst>
maybe I shouldn't work while getting sick :'(
lplc has joined #dri-devel
<sima>
Lyude, I guess we should move vkms to subsys_virtual_register?
<sima>
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?
<sima>
Lyude, doesn't look like too much typing at least on the C side to put vkms devices into a vkms virtual bus
<karolherbst>
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
<chewitt>
so X11 with legacy-x11 (which brings dri2) should work?
<chewitt>
or nouveau needs to evolve support for dri3?
<karolherbst>
ahhh
<karolherbst>
okay..
<karolherbst>
I see what's going on
<karolherbst>
chewitt: you can't use a linear frontbuffer with depth
<karolherbst>
so you'd either have to use modifiers to use a nvidia specific layout
<karolherbst>
or don't use depth
<karolherbst>
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
<karolherbst>
there is a `DRI3` option tho
<karolherbst>
and it should work in general
<karolherbst>
`Option "DRI" "3"` if one has a xorg config
<karolherbst>
but might be better to just patch it
<chewitt>
dri3 is dependent on X11? or not?
<karolherbst>
yeah
<karolherbst>
it's only relevant for a x11 windowing system
<karolherbst>
be it GLX, or EGL on X11
<karolherbst>
the latter also includes xwayland, but that should always support dri3
<chewitt>
the goal would be to not use X11 but that might need a tweak to how Kodi renders things
<karolherbst>
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
<karolherbst>
so if you scanout into a linear image with depth, that won't work
<karolherbst>
can't render into it either
<chewitt>
if there a way to understand that from querying EGL properties or such?
<karolherbst>
if you don't use modifiers and it's a shareable resource, it's gotta be linear
<karolherbst>
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)
<chewitt>
gotcha
haaninjo has joined #dri-devel
<karolherbst>
I think gbm has some APIs related to that
<chewitt>
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 :)
<karolherbst>
and dma-buf and kms and ...
lemonesque has quit [Ping timeout: 480 seconds]
lemonesque has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
apinheiro has joined #dri-devel
guludo has joined #dri-devel
<MrCooper>
AFAIK the EGL GBM platform uses optimal tiling by default, sounds like Kodi forces linear for some reason
<MrCooper>
(side note, this is one of the silliest and most painful HW limitations I know of)
fab has quit [Read error: Connection reset by peer]
<karolherbst>
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 🙃
<karolherbst>
but yeah.. no rendering into linear depth images
nirmoy has joined #dri-devel
feaneron has joined #dri-devel
kts has joined #dri-devel
<MrCooper>
except it works fine without depth/stencil (and other non-linear colour buffers)
<MrCooper>
I hope the few transistors they saved for this were worth the pain
JRepin has quit []
JRepin has joined #dri-devel
karolherbst is now known as karolherbst[i]
karolherbst[i] has quit []
karolherbst has joined #dri-devel
<karolherbst>
it probably was...
<karolherbst>
there is quite a lot of special hardware in regards to depth buffers, so... wouldn't surprise me
<daniels>
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
fab has joined #dri-devel
<MrCooper>
karolherbst: I understand it's not specific to depth, mixing linear & tiled colour buffers doesn't work either
<karolherbst>
mhhhhh, not sure if that's a hardware limitation
<karolherbst>
but could be
mvlad has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
paulk-bis has quit []
paulk has joined #dri-devel
fab has joined #dri-devel
<mairacanal>
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
<mairacanal>
offending commit isn’t in drm-next as well. sima, mripard, tzimmermann, could you give me an idea about where I should apply it?
kts has quit [Read error: No route to host]
<sima>
mairacanal, drm-next has a backmerge of v6.13, so if that gets backmerged into drm-misc-next-fixes it should apply there
<sima>
tzimmermann, mlankhorst ^^
<lumag>
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.
<sima>
lumag, yeah I'm worried about false positives, we already struggle with some of those in e.g. drm unit tests sometimes
<sima>
lumag, so for now I guess just try to improve docs until we get better ideas
<sima>
mairacanal, oh right, airlied only backmerge v6.13
<lumag>
sima, I see. But then we have almost-legit usecases as mgag200 pointed out by tzimmermann.
fab has quit [Read error: No route to host]
<sima>
lumag, yeah that's kinda what I'm worried about
fab has joined #dri-devel
<sima>
and similar patterns
<lumag>
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()?
<lumag>
in other words clearly documenting - this is the place where you can reevaluate your state.
<sima>
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
<sima>
or run multiple times
<sima>
if we only designate one place it's probably too strict
<sima>
and more drivers would be forced to entirely hand-roll the entire mess
<mlankhorst>
mairacanal: what is the exact commit you want to merge into next-fixes?
<mlankhorst>
so I can provide it as justification for backmerge
<lumag>
well, we can document that callback as a recommended place. Then at least mgag200-like drivers won't have to loop the call.
<lumag>
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.
<sima>
lumag, maybe I don't get what you're proposing ...
<mlankhorst>
mairacanal: good enough, feel free to push to next-fixes now :)
fab has quit [Read error: No route to host]
<mairacanal>
Thanks mlankhorst!
<lumag>
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.
<sima>
mlankhorst, did you check that your merge matches the one linus has done?
<sima>
lumag, oh yeah now I get it
pcercuei has joined #dri-devel
<sima>
yeah I guess we could add that if there's a few drivers that would benefit
<sima>
but if it's just one then I think looping is fine
fab has joined #dri-devel
<mairacanal>
mlankhorst, drm-next doesn't have the commit as well
<mairacanal>
I pull drm-misc-next-fixes and still it doesn't have the commit
<lumag>
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.
fab has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
<lumag>
cdns-mhdp upgrades HDCP events to mode_changed
<lumag>
malidp does a proper job of calling helper_check if gamma-related props changed.
<lumag>
and on the other side, drm_atomic_helper_connector_hdmi_check() does a bad job, it sets mode_changed w/o second thought.
<lumag>
sima, anyway, is it fine to land the docs patch from that patchset?
<sima>
lumag, yeah sure, I think I already put an r-b onto that?
<lumag>
yep, just making sure :-D
<sima>
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
<sima>
especially when that hook helps fix some existing issues
fab has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
<tzimmermann>
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)
<tzimmermann>
but likely not for more complex setups
<lumag>
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)
<tzimmermann>
lumag, IIRC your patchset doesn't intentionally break any driver. it only tightens the rules and warns about it, right?
<lumag>
yes
<sima>
tzimmermann, you still need to re-run check_modeset() for that case though, which is what lumag's new hook would fix
<tzimmermann>
lumag, that should be good enough for mgag200 for now.
<tzimmermann>
sima, i haven't followed the series in detail. it would be good to have an auto-restart
<sima>
tzimmermann, auto-restart is kinda hard since drivers might have their own stuff in there
<sima>
between calls to helpers I mean
<sima>
I did ponder auto-restart but hw that needs this is so varied it seemed like it would hurt more than it would help
<tzimmermann>
sima, lumag, can't you restart the whole drm_atomic_helper_check() ?
<lumag>
tzimmermann, well... malidp restarts it on its own.
<lumag>
So I'd rather not
<tzimmermann>
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?
<sima>
tzimmermann, the implementation would need to be idempotent
<sima>
which they are not necessarily
<tzimmermann>
ok
<sima>
by forcing driver writes to do the restart I'm hoping they're thinking about whether this is ok with all their callbacks
<tzimmermann>
for now, i don't have a problem with updateing mgag200. it's not very large
<tzimmermann>
but what is the long-term perspective of this?
<tzimmermann>
what's the hook you mentioned?
guludo has quit [Ping timeout: 480 seconds]
<lumag>
tzimmermann, I'm thinking of adding an extra hook that sets crtc_state->mode_changed early enough.
<lumag>
Or rather makes drm_atomic_helper_check_modeset() set crtc_state->mode_changed
guludo has joined #dri-devel
<tzimmermann>
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
<lumag>
tzimmermann, that's the point
<tzimmermann>
well, ok.
<chewitt>
lumag if you have any changes that cleanup meson/Amlogic DRM code feel free to ping/cc me for testing
<tzimmermann>
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
<lumag>
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.
fab has quit [Quit: fab]
kts has joined #dri-devel
fab has joined #dri-devel
kts has quit []
<mlankhorst>
sima: oh, isn't post origin/master inside drm-next yet?
<sima>
mlankhorst, oh did you backmerge origin/master?
<sima>
that's no good, random in the middle of the merge window is no-go
<sima>
mlankhorst, and yeah I haven't backmerged v6.13 yet, you jumped the gun
<sima>
mlankhorst, want to force unpush that merge?
<sima>
mlankhorst, build-testing now the merge that exactly matches what Linus' had
<sima>
once I pushed it I think would be best if you drop your current backmerge and redo
LeviYun has quit [Remote host closed the connection]
<sima>
mairacanal, since the backmerge is kinda stuck (I guess mlankhorst is gone already) you can push it into drm-misc-fixes
<sima>
since there's other stuff in there already anyway
kzd has joined #dri-devel
rgallaispou has joined #dri-devel
jsa1 has joined #dri-devel
hansg has joined #dri-devel
jsa2 has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
phasta has quit [Quit: Leaving]
cascardo has quit [Ping timeout: 480 seconds]
cascardo has joined #dri-devel
<mattst88>
karolherbst: ah, okay. thanks
<sima>
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?
<sima>
for drm drivers
<sima>
since it's not yet shipping this is something we can still rectify
heat has joined #dri-devel
<sima>
and if we go with that, would need links from fdinfo to dmem and the other way round I think in the main docs
f_ is now known as funderscore
dolphin has quit [Quit: Leaving]
<mlankhorst>
Just a sec
<mlankhorst>
I'm back now
<mlankhorst>
should I undo previous merge or add it?
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
fab has joined #dri-devel
ryanneph has joined #dri-devel
<mlankhorst>
mairacanal: I overwrite my previous merge, you can do it now
kts has quit [Quit: Leaving]
guludo has quit [Quit: WeeChat 4.5.1]
hansg has quit [Quit: Leaving]
jsa2 has quit [Ping timeout: 480 seconds]
<sima>
mlankhorst, yup that's what I meant, thanks a lot
tzimmermann has quit [Quit: Leaving]
Duke`` has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
<tursulin>
sima, mlankhorst: yep names should definitely match otherwise it will be a mess
<sima>
tursulin, I guess this needs a doc patch then at least?
<sima>
not sure how we can enforce this except maybe with helpers that take care of both
<tursulin>
I am not up to speed with how dmem ended up in terms of uapi so don't know
<tursulin>
can look at it tomorrow or so
mriesch has quit [Quit: No Ping reply in 180 seconds.]
mriesch has joined #dri-devel
<sima>
tursulin, yeah it's not a rush, merge window only just started
chaos_princess has quit [Quit: chaos_princess]
<sima>
just thought that this is something we better figure out and document before we ship dmem in the first release in 2 months
funderscore is now known as f_
<tursulin>
to be clear I don't propose I send a patch, just that I will look at how the dmem controller ended up looking
chaos_princess has joined #dri-devel
lplc has quit [Quit: WeeChat 4.0.4]
<tursulin>
since I kind of missed it is happening in the mailing list noise
lplc has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
ryanneph_ has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
chewitt has quit [Quit: Zzz..]
<sima>
tursulin, could also volunteer mlankhorst for the patch I guess, but yeah first need to look at what should be there
tlwoerner_ has joined #dri-devel
Kayden has quit [Quit: -> JF]
ryanneph has quit [Ping timeout: 480 seconds]
tlwoerner has quit [Ping timeout: 480 seconds]
linkmauve has left #dri-devel [Error from remote client]