mbrost has quit [Remote host closed the connection]
kts_ has joined #dri-devel
mbrost has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
konstantin_ has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
konstantin has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
kts has joined #dri-devel
AlexisHernndezGuzmn[m] has quit []
kts has quit [Quit: Konversation terminated!]
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
JohnnyonF has quit []
fab has quit [Quit: fab]
benjaminl has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
jsa has joined #dri-devel
sima has joined #dri-devel
macslayer has quit [Ping timeout: 480 seconds]
i509vcb has quit [Quit: Connection closed for inactivity]
fab has joined #dri-devel
MrCooper_ is now known as MrCooper
rgallaispou has joined #dri-devel
sghuge has quit [Remote host closed the connection]
rasterman has joined #dri-devel
sghuge has joined #dri-devel
sgruszka has joined #dri-devel
frieder has joined #dri-devel
apinheiro has joined #dri-devel
yrlf has quit [Read error: Connection reset by peer]
yrlf has joined #dri-devel
glennk has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
yrlf is now known as Guest9497
yrlf has joined #dri-devel
Guest9497 has quit [Ping timeout: 480 seconds]
<mripard>
lumag: you had a r-b already?
jsa has joined #dri-devel
lynxeye has joined #dri-devel
vliaskov has joined #dri-devel
qyliss has quit [Read error: Connection reset by peer]
neniagh has quit []
tzimmermann has joined #dri-devel
jsa has quit []
qyliss has joined #dri-devel
pochu_ has left #dri-devel [#dri-devel]
maxzor has joined #dri-devel
pcercuei has joined #dri-devel
tristianc6704 has quit []
alatiera has joined #dri-devel
donaldrobson has joined #dri-devel
jsa has joined #dri-devel
jsa has quit []
hansg has joined #dri-devel
heat has joined #dri-devel
KetilJohnsen has joined #dri-devel
<lumag>
mripard, but doesn't this need an ack from the core team? I should go, reread the drm-misc docs.
mvlad has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<mripard>
lumag: a-b then
<lumag>
already pushed :-(
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
neniagh has joined #dri-devel
donaldrobson has quit [Remote host closed the connection]
f11f12 has joined #dri-devel
cuolvar^ has quit [Remote host closed the connection]
maxzor has quit [Ping timeout: 480 seconds]
vliaskov has quit [Read error: No route to host]
donaldrobson has joined #dri-devel
mandelstays has quit [Quit: Leaving]
<DavidHeidelberg>
lumag: quick check, can your Mesa patch backfire for anything outside of rusticl usage?
yyds has quit [Remote host closed the connection]
<DavidHeidelberg>
s/Mesa/Mesa rusticl/
<lumag>
DavidHeidelberg, which one? fdo rusticl? It might as I have been changing ir3. But it is far from being complete.
<lumag>
Or do you mean the BO patchset?
<DavidHeidelberg>
it's not about OpenCL functionality, if it's about interference with other loads
<lumag>
Yes. OpenCL jobs might take a while, so we might be hitting the hangcheck.
<DavidHeidelberg>
lumag: when Marge will be free, I'll re-run pipeline on A***; I was testing your MR + my fix on Alpine gitlab and they kinda quickly merged it. The CL is guarded by RUSTICL_ENABLE, so that's safe, but if it alter stuff outside rusticl that would be tricky (and I would send rather revert then)
bmodem has quit [Ping timeout: 480 seconds]
<lumag>
DavidHeidelberg, !25840 it is a draft on purpose, it should not be merged
<DavidHeidelberg>
kk, I'll send revert asap :)
<lumag>
There are generic fixes there, but it should be more complete. I never tested it against full GL/VK testsuite
<lumag>
So those fixes might break something else.
maxzor has joined #dri-devel
maxzor has quit []
dos1 has quit [Ping timeout: 480 seconds]
<tzimmermann>
if a PCI device is disabled, it's child devices are implicitly disabled as well. right?
<tzimmermann>
'its'
dos1 has joined #dri-devel
bmodem has joined #dri-devel
kts has joined #dri-devel
alyssa has joined #dri-devel
Company has joined #dri-devel
<mripard>
jani: that discussion seems to be going around in circles. We agreed here on what the solution was, it's what you were arguing for the whole time, but somehow it's not enough?
kts has quit [Quit: Konversation terminated!]
Daanct12 has quit [Quit: WeeChat 4.1.2]
qyliss has quit [Quit: bye]
qyliss has joined #dri-devel
FireBurn has joined #dri-devel
yuq825 has quit [Remote host closed the connection]
AnuthaDev has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
macslayer has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
mandelstays has joined #dri-devel
cphealy has joined #dri-devel
<jani>
mripard: we agreed? I certainly didn't agree on BUG/BUG_ON, and the direction in kernel is to remove all of them
<emersion>
the tl;dr is indeed that WARN is preferred over BUG, it seems
<mripard>
emersion: Linus' PoV is that the kernel should never really panic for debugging stuff
<jani>
mripard: my preference is not to do anything, but if you insist on adding something, then if (WARN_ON(foo)) return -EINVAL;
yyds has joined #dri-devel
<jani>
the reason for this opinion is not to be lax about error checking
<jani>
it's because people really do cargo cult and copy-paste stuff all over the place
<jani>
they see this pattern, and soon you'll have a bunch of functions doing this. it's just how it is
<jani>
you really do want to be careful about the examples you set
a-865 has joined #dri-devel
<jani>
imo not every function needs to check the input *iff* that input does not come from the user or and can't be impacted by the user
<emersion>
i've seen the WARN_ON pattern a lot in core DRM
<vsyrjala>
i found quite a lot of spurious null check cargo-cult when i was playing around with the __attribute__((nonnull))
<vsyrjala>
maybe i should make proper patches to nuke some of it
<jani>
emersion: a lot of places you can't get to with NULL drm_device anyway
<jani>
emersion: so why do you need to check it?
<emersion>
i don't think it makes sense to go and add NULL checks for drm_device everywhere
<jani>
that's pretty much the point I'm trying to make here
<emersion>
but e.g. when the driver provides something, maybe it makes sense to check
donaldrobson has joined #dri-devel
<emersion>
like for instance, when the driver creates the IN_FORMATS blob
<emersion>
we have a WARN_ON for zero formats
<emersion>
and this makes a lot of sense to me
fab has quit [Quit: fab]
<jani>
also drm_connector_init() checks if (drm_WARN_ON(dev, !(funcs && funcs->destroy))) and I also think that makes sense. it can lead to hard to debug errors down the line
<mripard>
jani: and the point I'm trying to make is that doing that implicitly, inconsistently, and without it being documented is bad.
<mripard>
I've suggested the warn_on approach too, but vsyrjala was against it
<mripard>
so here I am, trying to fix something that looks super consensual to me, but with everyone pulling in different directions
<jani>
wrt consistency, the question remains: where do you draw the line?
<jani>
say, strcmp will happily null deref its arguments
<mripard>
I don't care at this point, you tell me. But it should be the same everywhere.
<jani>
my argument has been that if it can actually be NULL, check it. if it's a programming error to pass NULL to the function, just NULL deref it
<mripard>
can funcs be null or not?
<pq>
maybe "the same everywhere" is the problem - not everything is the same
<emersion>
i think it's pretty hard to come up with a generic rule that works everywhere
<jani>
mripard: no
<mripard>
jani: ok, so the code you pasted above that was making sense to you is wrong then?
<emersion>
in the end it's subjective, and IMHO boils down to "is the driver likely to get this wrong? if it gets it wrong, will this silently succeed and then blow up later on?"
<jani>
mripard: you could drop the funcs != NULL part out
<mripard>
emersion: funcs are mandatory for planes, CRTC and connectors, not for encoders
<jani>
mripard: point was about managed having destroy callback
<mripard>
can a driver author get it wrong?
donaldrobson has quit [Ping timeout: 480 seconds]
<jani>
if it oopses on first try, no :p
<mripard>
an oops is effectively a panic on all the systems I have, it's equivalent to BUG_ON you were against
<jani>
one of the reasons I'm a bit sensitive to this is the GEM_BUG_ON macro in i915 gem. it's a kind of assertion that behaves different depending on a kconfig. people aren't sure about stuff, so they throw in a check. and another. and another. and now we have 1.2k instances of GEM_BUG_ON in the driver. you don't want to go there.
<mripard>
anyway, I'm dropping all those patches
<mripard>
I'll just ignore the issue going forward
<mripard>
and hope for the entire thing to be rewritten in Rust so we can stop discussing it to no end
kzd has joined #dri-devel
<emersion>
you still get the same issues with Rust :o
<emersion>
well, maybe less issues, but still some
<mripard>
no, because you don't get to have an opinion over whether a pointer is valid or not
<mripard>
and whether you should check your values or not
<jani>
mripard: I'm sorry I got us into this loop
<emersion>
but you get the zero format listy length issue still, for instance
<mripard>
sure
<mripard>
I'm not sure that one was controversial though
<jani>
mripard: idk I've been told by akpm et al that there's no point in BUG_ON checks if it hits a null deref anyway
kts has joined #dri-devel
<emersion>
yeah, i would agree
<emersion>
except if the deref is delayed, for instance
<emersion>
then failing earlier is better
<mripard>
again, we would disagree on that one, but it doesn't matter
<emersion>
otherwise all functions grow a preamble with null checks for each arg and it's messy with no real gain
<mripard>
it's super user-hostile to chase down what you did wrong
<mripard>
especially when it's like 5 levels down
<mripard>
when it could have been an error message and an error returned
<mripard>
from a functional PoV, it might be better, but it's terrible from an ergonomics one
frankbinns has quit [Remote host closed the connection]
<pq>
mripard, I'm curious; if you have an arbitrary function returning an error somewhere in the kernel, how do you figure out where the error came from? I mean for things that are unrelated to userspace; I've seen DRM debug prints telling what userspace did wrong.
aravind has quit [Ping timeout: 480 seconds]
<emersion>
in general, logging
<emersion>
often times it's missing though
<pq>
yeah, wouldn't that also be totally flooding the kernel logs if it was done everywhere?
<emersion>
there are scopes
<jani>
I think dmesg logging of invalid user input is frowned on
<jani>
DoS?
<emersion>
jani: oh no it's not
<vsyrjala>
tracking down a silent 'return -EINVAL' can be super painful imo. null deref is trivial to see from the oops
<emersion>
it's just disabled by default
<calebccff>
lumag: added prepare_prev_first flag to the oneplus 6 panel driver, as of 6.7-rc3 the fbdev console always fails (after like 5 tries). We have a framebuffer app called unl0kr for handling full disk encryption and it seems there's a <50% chance that when it starts it kicks the display into life
<emersion>
drm_dbg_atomic(), for instance
<lumag>
calebccff, anything in the logs?
<lumag>
also please use #freedreno
<calebccff>
lumag: when i was debugging before I noticed that the IRQ (frame done? or maybe vsync?) would not be firing, so it isnt' pushing data to the panel at all
<calebccff>
ah will move there
<pq>
As a userspace dev, I can well imagine a function returning an error, and then realise there are 3 different calls in it that could fail, and it branches out 5 levels deep. That's painful to debug even with gdb. I guess rr could make it easy though. But if it segfaults 15 levels deep in the call stack, I can immediately see the stack of what lead to the failure.
pa has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
diego has quit []
f11f12 has quit [Quit: Leaving]
sgruszka has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
Duke`` has joined #dri-devel
Kayden has quit [Quit: -> JF]
macslayer has joined #dri-devel
Duke`` has quit []
Duke`` has joined #dri-devel
donaldrobson has quit [Read error: Connection reset by peer]
leo60228 has joined #dri-devel
Kayden has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
yshui` has quit []
idr has joined #dri-devel
i509vcb has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
idr has quit [Remote host closed the connection]
idr has joined #dri-devel
pa- has joined #dri-devel
agd5f_ has joined #dri-devel
kxkamil has quit []
agd5f has quit [Ping timeout: 480 seconds]
ayaka_ has joined #dri-devel
AnuthaDev has quit [singleton.oftc.net coherence.oftc.net]
RAOF has quit [singleton.oftc.net coherence.oftc.net]
MoeIcenowy has quit [singleton.oftc.net coherence.oftc.net]
ayaka has quit [singleton.oftc.net coherence.oftc.net]
wens has quit [singleton.oftc.net coherence.oftc.net]
lina_ has quit [singleton.oftc.net coherence.oftc.net]
ayaka_ is now known as ayaka
AnuthaDev has joined #dri-devel
MoeIcenowy has joined #dri-devel
wens has joined #dri-devel
lina has joined #dri-devel
kxkamil has joined #dri-devel
RAOF has joined #dri-devel
<mandelstays>
the procedure without bit shifting or multiply as well as divide and without over nor underflow and not even signed arithmetic nor control flow, only with sub/add and lookup tables is already pretty complex variation of the presented..you add two times index and values if that overflows its maximum number as result, hence the indexes need to be taken for the first 4bits of 32bit value , as there are 16 combinations in 4 bit, the indexes need to be
<mandelstays>
taken from bits 5 to 21 so twice the size of those need to be added to the original value, now if it overflows to one, situation is clear all indexes were either all out and all other bits were in, or the low order bits were X and all higher bits were in, so we could hence safely work on bits 23 to 27 cause 28 to 32 are too big , the former 23-27 are always unchanged of the indexes , so we add sum of 6to22 and remove 5 to 22, anyways now you
<mandelstays>
understand where i am aiming already, 5 to 21 is index and is subtract from 23-27 as value, after the bits of 23-27 is found out its possible to find out low order bits, and highest bits are all revealed after this and inverted and added to compressed format and reverted back
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
AnuthaDev has quit []
<mandelstays>
i am working on this, but i think it's not innovative, it is known stuff in cryptography though it appears. so reinvented, but i can see a way to handle overflow and underflow and all the flags like this too
mandelstays was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
mripard has quit [Quit: mripard]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
frieder has quit [Remote host closed the connection]
cheako has quit [Quit: Connection closed for inactivity]
simon-perretta-img has quit [Read error: Connection reset by peer]
mvlad has quit [Remote host closed the connection]
gouchi has joined #dri-devel
Kayden has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
<gfxstrand>
rodrigovivi: When you do the Xe PR, are you planning to maintain any development history or squash everything?
<rodrigovivi>
gfxstrand: I'm planing to send a regular PR of what we have on drm-xe-next... unless sima or airlied tells me the extra squash is better...
<gfxstrand>
rodrigovivi: Where does that branch live? I'm not seeing it in drm-intel
<rodrigovivi>
there's the mega initial squash on the bottom from when we went public and the history on top... that we maintained so far with rebases and fixup patches
<rodrigovivi>
and also to get rid of 2 ugly i915/display FIXME patches...
<gfxstrand>
I'm not planning a full review or anything. Just really excited to see it finally land.
<rodrigovivi>
oh, and 2 uapi changes coming... 1 around vm_bind and another around wait_user_fence...
<gfxstrand>
It's been a looooong time coming. :)
<rodrigovivi>
yeap, a long time indeed
<rodrigovivi>
I'm also glad that everything is aligning right now... it is getting harder and harder to work with all the drm stuff like drm-scheduler, gpuvm, drm-exec and be out of the tree rebasing and doing fixup patches
<gfxstrand>
Yeah
<airlied>
in hindsight we probably should have merged a non-functional driver earlier :-P
<airlied>
but then we'd just have distros trying to enable it all the time
<gfxstrand>
airlied: Oh, like the Fedora people are trying to do with NVK?
<airlied>
yes, but at least there I can smack ppl
<airlied>
considering merging non-functional rust driver bits early so we can grow something in-tree
fab has quit [Quit: fab]
<rodrigovivi>
yeap, but then we would have a bigger discussion around that STAGING vs drm again
<daniels>
airlied: haters will say we have at least three non-functional DRM drivers in tree
tjaalton has quit [Ping timeout: 480 seconds]
urja has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
urja has joined #dri-devel
tjaalton has joined #dri-devel
hansg has quit [Quit: Leaving]
<airlied>
daniels: three just mean they haven't searched enough :-P
crabbedhaloablut has quit []
<emersion>
the better question probably is, how many functional drivers do we have in-tree?
<airlied>
if Intel had a track record of working on making code common I'd probably have been a bit more flexible, but after realising how much common code we've managed to pull out since xe started, it was probably all godo
<airlied>
would be nice if we could get hostptr support more common, and I'm sure there are other areas
<kchibisov>
what is the irc channel for intel support stuff?
tlwoerner_ has quit []
<emersion>
#intel-gfx
tlwoerner has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<DemiMarie>
mareko: I did not know that Android proprietary drivers supported virtio-GPU native contexts. If so, that is great (though obviously open drivers would still be better).
gouchi has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
<DemiMarie>
airlied: Rust for GPU drivers would be a nice win for Qubes
<HdkR>
Oh, is xe-drm getting close to merging?
<HdkR>
I see, two uapi changes still incoming. I'll run it through my struct layout verifier when that occurs
sima has quit [Ping timeout: 480 seconds]
tango_ has quit [Remote host closed the connection]
tango_ has joined #dri-devel
<Company>
gfxstrand: what's the ETA on nvk in Fedora you think? A year?
<Company>
I need to somehow ensure RH's desktop team has at least some people with nvidia when that happens - we have a somewhat serious problem with everyone having Intel and not testing on anything else
<Company>
there's sooo much experimental code currently that falls over with the AMD 256 stride already and I'd like to avoid similar issues when the 3rd big driver lands
Duke`` has quit [Ping timeout: 480 seconds]
<Company>
("desktop team" meaning the application developers, could also call it "Gnome")
gouchi has quit [Remote host closed the connection]
i509vcb has quit [Quit: Connection closed for inactivity]
<airlied>
Company: rawhide in January
<airlied>
maybe February if things slip
<airlied>
so probably f40, maybe with f39 backports if things line up
<Company>
that's earlier than I thought
<Company>
should start on nudging people towards getting nvidia gpus then
zackr has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
<DavidHeidelberg>
CI migrated from Linux 6.4.x to 6.6.4, it's pretty tested, but id you see some suspicious fail somewhere feel free to throw link at me
<gfxstrand>
Company: I would normally say that airlied is being optimistic and signing me up for too much but I really think his prediction is about accurate.
<gfxstrand>
I don't know that we're going to get Vulkan 1.3 conformance for Christmas but things are moving FAST now that the new compiler has landed.
<Company>
that's nice
<gfxstrand>
Like, 120+ patches in the last week fast.
<gfxstrand>
(Some of those are because I make mistakes and have no code review and then have to fix them.)
<Company>
how's performance coming along?
<gfxstrand>
Lots of stuff is very playable. Older games are often 60 FPS+.
<gfxstrand>
There's still a couple of major performance improvements that need to happen. Then it's a lot of analysis.
<gfxstrand>
I have no idea where we're at compared to the blob right now. I'm kind-of hoping Michael decides to benchmark again soon.
<gfxstrand>
I'm a bit surprised he hasn't been benchmarking monthly, TBH.
<Company>
hehe
<Company>
nvk landing should be a good enough reason for him I guess
<gfxstrand>
He did run a bunch right after we landed but he didn't have GSP so it was shit perf.
<gfxstrand>
Like < 1% of blob in a bunch of cases
<Company>
yeah, I enjoyed that post a lot
<gfxstrand>
But between GSP and making UBOs not entirely stupid, we're in okay(ish) shape right now.
<gfxstrand>
It's still early days but I don't think I look like a total clown.
<Company>
I'm mostly trying to convince enough Gnome and RH desktop developers to get GPUs that aren't Intel
<gfxstrand>
Yeah....
<gfxstrand>
I really need to get a new laptop this next year.
<Company>
so that now that we use GPUs more than just blitting cairo-drawn stuff together, we actually have a somewhat wider test coverage