ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<Kayden>
yeah, I think that would break compatibility with super legacy drivers that never transitioned
<Kayden>
all of mesa switched over long ago and should be fine
jfalempe has quit [Ping timeout: 480 seconds]
<illwieckz>
For the Unvanquished game we noticed GLVND ABI broke compatibility with legacy Nvidia drivers and current AMD oglp drivers (it's the proprietary OpenGL driver in amdgpu-pro, though discouraged, it is still shipped today)
<illwieckz>
so, I assume the good thing to know for a developper is: don't use GLVND ABI unless you know why you need it
<illwieckz>
Maybe we may report to CMake that setting the GLVND ABI the default is probably a mistake.
<Kayden>
interesting, hadn't heard of a bug there, but sounds believable. looks like pepp has a fix in progress in that issue
<illwieckz>
that patch was not enough for some user though
<illwieckz>
anyway, if glvnd allows to install multiple GL libraries, I guess we can select a specific library at runtime, a bit like OpenCL or Vulkan ICD? How does that work? (I mean what can I do to test it)
<illwieckz>
I currently have a setup with Mesa radeonsi and amdgpupro oglp installed so I can test.
DavidHeidelberg has quit [Remote host closed the connection]
Manas has quit [Read error: Connection reset by peer]
flynnjiang has quit [Remote host closed the connection]
flynnjiang has joined #dri-devel
<tzimmermann>
javierm, thanks for reviewing. there's still screen_info code at the end of efifb.c.
jsa has joined #dri-devel
<tzimmermann>
it tries to find the framebuffer's device on the pci bus, so that efifb can avoid power management
<tzimmermann>
on the framebuffer
<tzimmermann>
as a quick fix, maybe we can move that code into sysfb.c and use the pci device as parent for the platform device ?
flynnjiang has quit [Read error: Connection reset by peer]
DemiMarie has joined #dri-devel
DemiMarie is now known as Guest8747
ungeskriptet has joined #dri-devel
<javierm>
tzimmermann: you mean efifb_fixup_resources() ? Yes, that makes sense. Is something that simpledrm would need or not because doesn't do PM ?
<javierm>
there's already sysfb_apply_efi_quirks() in drivers/firmware/efi/sysfb_efi.c so makes sense to have other fixups in sysfb
<tzimmermann>
javierm, our platform devices don't support PM. that should mean that if we set the pci dev as parent, the parent won't do PM as well
<tzimmermann>
maybe that's a bug with the current simpledrm
<tzimmermann>
i have to verify that DECLARE_PCI_FIXUP_CLASS_HEADER runs at the right time
<tzimmermann>
after screen_info setup, but before sysb
<tzimmermann>
sysfb
<javierm>
tzimmermann: that's what I thought. Hence my comment that efifb_fixup_resources() would also be beneficial for simpledrm
<javierm>
in other words, it makes sense to move that logic to sysfb_efi
<javierm>
tzimmermann: btw, did you ever post the patch to move sysfb to a different initcall level ?
<javierm>
I remember we discussed something about that
<tzimmermann>
BTW, i tried to figure out how to limit screen_info exposure within the graphics code. i don't quite know where to start. so i only have few more patches to get screen_info removed from regular device drivers
<javierm>
tzimmermann: yes, I like to limit the exposure to that global variable
aradhya7[m] has joined #dri-devel
<javierm>
tzimmermann: if I'm reading the code correctly the pci fixups happen at fs_initcall_sync()
<tzimmermann>
urg, that's too late
<tzimmermann>
maybe we should move sysfb back to device_initcall
<javierm>
tzimmermann: yeah... I think we discussed about moving sysfb_init() to device_initcall_sync(), which is what we agreed IIRC
<javierm>
let me look at my irc logs
<tzimmermann>
i dont remember TBH
<tzimmermann>
but the drivers use module_init(), which resolves to device_initcall() IIRC
<javierm>
10:24 < javierm> | tzimmermann: can you mention in the thread and propose a patch? And also update the comment that should not only happen after PCI but after all the devices have been registered
<javierm>
10:25 < tzimmermann>| well, it's just an idea for now. i'd like them to first debug this further
<tzimmermann>
so we won't get any output sooner than that
<javierm>
10:25 < javierm> | tzimmermann: Ok
<javierm>
10:26 < javierm> | tzimmermann: regardless, I think that you are correct that should happen after device_initcall()
<tzimmermann>
indeed
<tzimmermann>
and for now, we can sync with native drivers via sysfb_disable() as a workaround
<javierm>
tzimmermann: yeah
<javierm>
which reminds me that I need to answer to that OF/EFI thread. I'll do that now
<tzimmermann>
thanks
cmichael has joined #dri-devel
kunal10710[m] has joined #dri-devel
ohadsharabi[m] has joined #dri-devel
<pq>
emersion, I almost asked if a driver needs to pull in a CRTC into an atomic commit even when userspace made absolutely no reference to it, will that also trigger a VRR scanout cycle on the unexpected CRTC. :-p
<emersion>
pq, yes, this can happen!
Kayden has quit [Read error: Connection reset by peer]
<pq>
yeah...
<emersion>
i've seen several of these in the wild
<pq>
but was that gated by needing ALLOW_MODESET?
Kayden has joined #dri-devel
<emersion>
hm, i'm not sure…
<pq>
I decided not to mention it, because things were getting hairy enough already
YHNdnzj[moz] has joined #dri-devel
neniagh has quit []
rasterman has joined #dri-devel
samueldr has joined #dri-devel
kusma has joined #dri-devel
Anson[m] has joined #dri-devel
cmichael has quit [Remote host closed the connection]
cmichael has joined #dri-devel
cmichael has quit [Remote host closed the connection]
kts has joined #dri-devel
<MrCooper>
pq: my understanding is that pulling in additional CRTCs must happen only with ALLOW_MODESET
cmichael has joined #dri-devel
apinheiro has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
MrCooper has quit [Remote host closed the connection]
<emersion>
hm i remember something about a patch adding WARN_ON w/ affected_crtc checks…
<emersion>
not sure it got merged
libv has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
mvlad has quit [Remote host closed the connection]
libv has joined #dri-devel
ascent12_ has joined #dri-devel
ascent12 has quit [Ping timeout: 480 seconds]
DodoGTA has quit [Read error: Connection reset by peer]
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
tzimmermann has quit [Remote host closed the connection]
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
fab has quit [Quit: fab]
jfalempe has quit [Read error: Connection reset by peer]
jfalempe has joined #dri-devel
yuq8251 has joined #dri-devel
yuq825 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
glennk has joined #dri-devel
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
Net147 has quit [Remote host closed the connection]
Net147 has joined #dri-devel
jfalempe_ has joined #dri-devel
fab has joined #dri-devel
jfalempe has quit [Remote host closed the connection]
mareko_ has joined #dri-devel
dri-logger has quit [Ping timeout: 480 seconds]
mareko has quit [Ping timeout: 480 seconds]
glisse has quit [Ping timeout: 480 seconds]
FloGrauper[m] has joined #dri-devel
glisse has joined #dri-devel
dri-logger has joined #dri-devel
yyds has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
shoffmeister[m] has joined #dri-devel
yuq8251 has left #dri-devel [#dri-devel]
jfalempe_ has quit [Ping timeout: 480 seconds]
JosExpsito[m]1 has joined #dri-devel
fkassabri[m] has joined #dri-devel
jfalempe has joined #dri-devel
dabrain34[m] has joined #dri-devel
glennk has joined #dri-devel
jfalempe_ has joined #dri-devel
jfalempe has quit [Read error: No route to host]
camus has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
bubblethink[m] has joined #dri-devel
dhirschfeld2[m] has joined #dri-devel
egalli has joined #dri-devel
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
Daanct12 has quit [Quit: WeeChat 4.1.1]
DodoGTA has joined #dri-devel
csbaur^ has quit [Ping timeout: 480 seconds]
sigmoidfunc[m] has joined #dri-devel
Guest8747 is now known as DemiMarie
bmodem has quit [Quit: bmodem]
bmodem has joined #dri-devel
kts has joined #dri-devel
tleydxdy has joined #dri-devel
<sima>
jani, I guess I should forward your pr?
<jani>
sima: up to you, otherwise it'll be next week
i509vcb has joined #dri-devel
csbaur^ has joined #dri-devel
nicofee[m] has joined #dri-devel
AlaaEmad[m] has joined #dri-devel
tak2hu[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
csbaur^ has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
tomba1 has joined #dri-devel
Haaninjo has joined #dri-devel
kzd has joined #dri-devel
<vsyrjala>
jani: sorry about that. i did realize the dependency when i tagged the patch, but figured i'd come up some sane way to highlight it before pushing. but then promptly forgot the whole thing and pushed anyway
<kisak>
from memory, I think it's fine because the trouble around that started with llvm 16 and I'm stuck on llvm 15 for the time being.
<karolherbst>
yeah.. it's probably fine... I just know that there was a bindgen bug some hit
<karolherbst>
or something
<kisak>
okay, thanks
<kisak>
If the libtcmalloc drama around llvm 16+ gets fixed, I'll probably need to prioritize radeonsi/llvm over rusticl/opencl, but that's a future me problem
<kisak>
tjaalton: the rust / bindgen packaging is extremely painful. Good luck with that. If you happen to figure out a procedure to take care of that in the course of your routine maintenence, I'd appreciate a copy of your notes, but I don't expect anything. I'm not going to do that heavy lifting on my own.
<kisak>
^take care of backporting for mesa updates
<tjaalton>
kisak: I'm not backporting rusticl to 22.04
<tjaalton>
because of that
<kisak>
the applies to all current ubuntu releases, not just 22.04
<kisak>
*the note
<tjaalton>
well, 22.04 is the only one I backport to..
<kisak>
oh, okay
<tjaalton>
because there are others doing that ;)
macslayer has joined #dri-devel
<sima>
pq, emersion I think it's roughly the same in practice: there's a few things that have documented side effects (like a crtc generates and even if it's otherwise a no-op and a plane generates a full damage even if it's otherwise a no-op)
<sima>
but drivers do not add random state updates that have an observable impact, like just always change the full resource/scaler assignment, which on some hw would mean more modesets than you've asked for
<sima>
also there's some stuff like if you add a plane/connector, that pulls in any crtc it's connected to
<sima>
pq, emersion I guess what could clarify if you do s/try to avoid no-operation changes/try to avoid _expensive_ no-operation changes/
<sima>
since just always blasting the usual registers really doesn't matter, but unconditionally uploading the ctm/gamma tables does tend to matter
<emersion>
but drivers check whether the blob ID changed before updating the LUTs?
kunal_10185[m] has joined #dri-devel
rgallaispou has left #dri-devel [#dri-devel]
<sima>
emersion, yeah they should
frankbinns has quit [Ping timeout: 480 seconds]
<ptrc>
hey, did anyone here try testing the new Imagination DRM driver with a GX6250 GPU? i'm trying to do just that on an MT8713, and in the initial patch they say they tested it on an Acer Chromebook R13, but i can't find the right GPU device tree node for it
<vsyrjala>
luts are a special case. for those we have one of these ad-hoc _changed booleans
<vsyrjala>
though that's not super optimal either since it covers both luts and ctm, and on i915 changing the ctm is generally fairly cheap vs. chaging luts is expensive. so currently if you change the ctm we also reprogram the luts which is not the best thing to do
<vsyrjala>
i suppose we could stop blindly trusting that flag and instead checking if the blobs changed or not. but we'd also have to make sure we don't need to change the format in which they are being fed to the hardware
<zamundaaa[m]>
vsyrjala: how expensive is programming luts in general? As in, how long does it take?
doras has joined #dri-devel
<vsyrjala>
some dozends of microseconds. but we also have to do it during the vblank, so we spin up a high priority thread in an effort to make it in time, and we have to try to make sure the cpu is fully awake to handle the interrupt asap to schedule the thread. otherwise you are pretty much guranteed to spill over into the next frame
<vsyrjala>
even that isn't 100% guaranteed to work unfortunately
<vsyrjala>
anywyas, i think psr/etc. is where the main problems are due to the implied damage requiring us to wake up the hardware. otherwise we can let it sleep and save a ton of power
<vsyrjala>
having to invalidate the compressed buffer for fbc is also not very optimal, but relatively not as expensive as waking from psr
alanc has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
alanc has joined #dri-devel
Anorelsan has joined #dri-devel
heat has joined #dri-devel
<gfxstrand>
daniels: Something wrong with the Windows runners?
<gfxstrand>
Uh... That's a bug and a pretty bad one at that.
<JoshuaAshton>
Yeah... Happy to help debug stuff there. I peeked at the code and my IDE said "last edited 12 years ago" so now I'm more scared :P
<gfxstrand>
A repro IGT test would probably help
<gfxstrand>
But if I had to take a stab, I'd say it was a reference counting bug or something where we're supposed to be removing ourselves from the epoll but aren't.
<JoshuaAshton>
I'll look at doing that
airlied has joined #dri-devel
<gfxstrand>
Yeah, turning it into a dma-buf FD and passing that into epoll should hold a reference at least until it signals. Someone is dropping a reference early.
<gfxstrand>
That or it's supposed to auto-delete on close. I'm not sure exactly what epoll's semantics are there.
<JoshuaAshton>
It's supposed to auto-delete from the epoll on fd close
<JoshuaAshton>
I'm guessing the order something is happening there is wrong
Targetball[m] has joined #dri-devel
<gfxstrand>
Yeah, then someone hasn't hooked that up for dma-buf properly
<JoshuaAshton>
such a shame, epoll is such a great mechanism for buffer latching
<gfxstrand>
Which is believable because dma-bufs are weird
<DPA>
My man pages say it's to be removed on fd close only if there are no more references to the file description of the file descriptor.
<JoshuaAshton>
FWIW this is also a dup'ed fence
<JoshuaAshton>
so maybe there's even more schenanigans there :-P