ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<mareko> have any srcs, and the dominance algorithm would have to insert a dummy node that dominates all such loads while building the dom tree to compensate. Also, nir_instr would need 6 new dom variables for dominance including 2 set data structures. (there are ways to store those variables outside of nir_instr) In a nutshell, there is no true instruction-level dominance in NIR and it would be very expensive
<mareko> to use it everywhere, but there are a few niche cases where instructinn-level dominance is the only solution to the problem.
ngcortes_ has quit [Ping timeout: 480 seconds]
<mareko> and I also need post-dominance, so I'll add both
stuarts has quit []
<mareko> and post-dominance would be a separate dom tree
Fijxu has quit []
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
ngcortes has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
schaeffer has quit [Quit: well, bye]
ngcortes has quit [Quit: Leaving]
schaeffer has joined #dri-devel
ngcortes has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
khfeng has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
cmtayyyyyyyyyy^ has joined #dri-devel
mbrost has joined #dri-devel
<cwabbott> mareko: first off, unless you're actually running into perf issues, that's very much premature optimization
<cwabbott> second off, adding the full dominance info per instruction is very much overkill - instructions are linear, just use the nir_instr::index if you're going to be making a lot of those queries
kzd has quit [Quit: kzd]
kzd has joined #dri-devel
rmckeever has joined #dri-devel
kzd has quit []
kzd has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
bbrezill1 has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
bbrezillon has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
mbrost has joined #dri-devel
bmodem has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
Danct12 has joined #dri-devel
kts has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
heat has quit [Remote host closed the connection]
Company has quit [Quit: Leaving]
heat has joined #dri-devel
cmtayyyyyyyyyy^ has quit [Remote host closed the connection]
<mareko> cwabbott: this is not for any existing NIR pass; also, I need the exact SSA graph of instructions because I'll be moving it between shaders, as well as be able to analyze whether it's legal to move them, which is highly dependent on which instruction are in the SSA graph
<cwabbott> all of that is irrelevant to what I just said
<mareko> cwabbott: what did you say then?
<cwabbott> that you shouldn't reinvent nir dominance for your new pass
<mareko> cwabbott: consider this shader that's complex, but has this one line that's simple: "output = input0 + input1;" - the goal is to find such an expression and move "input0 + input1" into the previous shader and replace the line with "output = new_input;" - how am I going to do with the current dominance?
<cwabbott> use the existing thing, or if it's too slow then use the instruction index or build your own
<mareko> *do it with
<cwabbott> umm, you don't need dominance at all for that
<cwabbott> you're way over complicating it, if that's your goal
<mareko> and I need to prove that "+" is legal to move across interpolation instructions
<mareko> cwabbott: I could do DFS starting from all outputs, but the time complexity would be much worse than just creating a dom tree and doing a bunch of LCA queries for every pair of output components
<mareko> and every pair of output components is already O(n^2)
bmodem has quit [Ping timeout: 480 seconds]
<cwabbott> find the addition, find the store_output instruction, add a new output that uses the source of those
<cwabbott> uhh, no
<mareko> I mean input components
<mareko> so DFS would start from all inputs, looking for a post-dominator, and that would be the replacement input for everything preceding the post-dominator
<cwabbott> it's literally just searching the shader for an add with two inputs as sources, why on earth would you have to do anything with dominance or whatnot
<cwabbott> you're way over-complicating it
<mareko> cwabbott: it can be an arbitrarily complex expression consisting of ALUs, uniform loads, UBO loads, constants, and multiple input loads
<mareko> the goal is to find the farthest post-dominator of inputs and then prove that all instructions being post-dominated are movable across interpolation
<cwabbott> if you want something more fancy, look at what opt_preamble is doing
<cwabbott> it also moves an arbitrarily complex expression into the preamble
<cwabbott> still, no dominance or whatever is necessary
<HdkR> It's the ideal problem where some application is doing a wackload of work in the fragment shader but it can be moved to a prior stage. The big win of whole program optimization :)
<mareko> I already have that for expressions with uniform loads, UBO loads, constants, and ALUs
<mareko> I only need post-dominance if there are also input loads
<cwabbott> uhh, no you don't
<cwabbott> whether you can move some instruction has nothing to do with whether it post-dominates an input
<cwabbott> it sounds like you have some assumption you're not telling me or you're going about it wrong
<mareko> cwabbott: I see, the assumption is that the number of inputs should always decrease if I move some code into the previous shader, so a path 2 input load should always lead to the same SSA node
<mareko> *path from 2 input loads
<mareko> in theory, a path from 3 input loads could also lead into 2 independent SSA nodes and that would be OK too
<cwabbott> you could just as easily have 3 different linear combinations of 2 different inputs
<cwabbott> again, post dominance has nothing to do with whether you increase or decrease the number of inputs
<mareko> if there are 3 different linear combinations of 2 different inputs, that would lead to 3 replacement inputs, which is what I'm trying to prevent
<cwabbott> yes, and that could happen regardless of whether those uses post-dominate the inputs
<cwabbott> so, again, what do you need post-dominance for?
<mareko> only 0 or 1 SSA node post-dominates a set of inputs
<mareko> cwabbott: a query for: given a pair of inputs, find an SSA node that, if I were to remove that SSA node, it would also remove the inputs
<mareko> it's not: find an arbitrary number of instructions that can be moved across between shaders
dviola has joined #dri-devel
<cwabbott> for that specific query, you can only remove both inputs if both have one use
<cwabbott> so, it's simple: check if it has one use, find that use and check if the other source is also an input with one use
Zopolis4_ has joined #dri-devel
<mareko> cwabbott: they can have multiple uses (it can be a branching graph), but eventually the graph should converge into 1 SSA node
<cwabbott> that can only happen if there's a tree/graph of additions
<mareko> cwabbott: for example: https://imgur.com/a/zttXND4 ; for FS, there are limits on which ALUs can be present, but other shaders don't have any limits
<mareko> also flat inputs don't have any limits either
<mareko> Mul2 wouldn't be movable for FS, but it would be movable for other shader types
YuGiOhJCJ has joined #dri-devel
jewins has quit [Read error: Connection reset by peer]
<mareko> the initial idea was to start DFS/BFS from inputs and record what's movable, but post-dominance just gives me the right answer and it's less code
<cwabbott> mareko: for something that involved, I'd do something similar to what opt_preamble does and scan each instruction and store whether it's moveable
<cwabbott> and no, post dominance has absolutely nothing to do with it
<mareko> except that it gives the right answer
<cwabbott> no it does not
<mareko> why not?
<cwabbott> the position of the instruction has nothing to do with whether removing it removes both inputs
<mareko> cwabbott: if I remove Mul2 from that graph, it removes the inputs; do you a graph where that wouldn't work?
<cwabbott> also, if everything except the input is inside an if, nothing postdominates the inputs and yet that shouldn't affect whether you can move it
<mareko> cwabbott: I need to decrease the number of inputs, or at minimum, keep the number of inputs the same, I can't move everything that's movable
<mareko> yes, there are cases where a post-dom tree wouldn't find movable code
bmodem has joined #dri-devel
<cwabbott> mareko: what exactly are you claiming? that the LCA of all the inputs in the post-dominance graph is Mul2? because it's not
<mareko> cwabbott: there are 3 exits, and Mul2 is the only node that all paths from input nodes must go through to reach one of the exits
<mareko> yes, Mul2 post-dominates all inputs
<cwabbott> no, Add1 does
<cwabbott> for any schedule of those instructions
<cwabbott> and ofc this all may be dependent on the way instructions are scheduled
<cwabbott> but for that particular case? only Add1 does
<cwabbott> *only Add1 can be the LCA of the post dominance tree
<cwabbott> assuming that these are all in the same basic block, ofc
<mareko> cwabbott: you're thinking in terms of the instruction index in NIR, not in terms of the graph, scheduling has no effect
<cwabbott> mareko: if that's what you're doing, then don't call it post-dominance
itoral has joined #dri-devel
bgs has joined #dri-devel
<mareko> cwabbott: "a node z is said to post-dominate a node n if all paths to the exit node of the graph starting at n must go through z" - not all paths from Input0 must go through Add1 in the graph, thus Add1 doesn't postdominate Input0
<mareko> again, there are no basic blocks here, just the graph
<mareko> cwabbott: ssa_def_dominates() is CFG graph dominance with an instruction index within a block, good for control flow and CSE, but it's not instruction graph dominance
<mareko> ssa_def_dominates() is really scheduling-dependent instruction dominance, which is not graph dominance
OftenTimeConsuming is now known as Guest10596
OftenTimeConsuming has joined #dri-devel
<mareko> post-dominance is not the ideal tool for the problem (what nir_opt_preamble does might be better), but it would work
aravind has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
Guest10596 has quit [Ping timeout: 480 seconds]
<mareko> think of srcs being the graph edges, not the linked list of instructions
<cwabbott> yes, now I see what you're doing
<cwabbott> dominance usually means "scheduling-dependent" dominance
<cwabbott> tbh I've never heard of using dominance but on the def-use graph
<mareko> if I decide to use, I might put it in nir_instr_dominance.c, or we can call it dataflow graph dominance or whatever
<mareko> *use it
bgs has quit [Remote host closed the connection]
<tomeu> daniels: thanks for the investigation!
MajorBiscuit has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
heat has quit [Read error: No route to host]
i509vcb has quit [Quit: Connection closed for inactivity]
heat has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
Duke`` has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
JPEW has quit [Read error: Connection reset by peer]
ADS_Sr has quit [Remote host closed the connection]
JPEW has joined #dri-devel
vjaquez has quit [Quit: ¡hasta luego!]
ADS_Sr has joined #dri-devel
vjaquez has joined #dri-devel
Znullptr has joined #dri-devel
ZeZu has quit [Ping timeout: 480 seconds]
a-865 has quit [Ping timeout: 480 seconds]
rmckeever has quit [Quit: Leaving]
a-865 has joined #dri-devel
frieder has joined #dri-devel
lynxeye has joined #dri-devel
danvet has joined #dri-devel
jkrzyszt has joined #dri-devel
iive has joined #dri-devel
jfalempe has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest10609
swalker__ has joined #dri-devel
junaid has joined #dri-devel
rasterman has joined #dri-devel
junaid has quit [Remote host closed the connection]
Guest10609 has quit [Ping timeout: 480 seconds]
elongbug has joined #dri-devel
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
bmodem1 has joined #dri-devel
bmodem has quit [Read error: Connection reset by peer]
bbrezill1 has quit []
sgruszka has joined #dri-devel
bbrezillon has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
godvino has joined #dri-devel
TMM has joined #dri-devel
<kusma> Today is CI appreciation day for me! I tend to mostly talk about our CI when I'm annoyed with it, but today I started a Zink CI pipeline, and there's *no* "needless" jobs in my pipeline! That makes me very happy, thanks everyone who helped with that :)
bmodem has joined #dri-devel
bmodem1 has quit [Read error: Connection reset by peer]
<ccr> all hail our CI overlords
<HdkR> CI is good
<ccr> CI extends life. CI expands consciousness. CI is vital to Mesa development.
jaganteki has joined #dri-devel
<DavidHeidelberg[m]> ccr: "CI extends life." - not mine :D
<DavidHeidelberg[m]> agree with the rest :D
<ccr> :P
devilhorns has joined #dri-devel
tanty has quit [Remote host closed the connection]
tanty has joined #dri-devel
vliaskov has joined #dri-devel
<dolphin> danvet: "Merge tag 'drm-misc-next-2023-04-06' of git://anongit.freedesktop.org/drm/drm-misc into drm-next" <- I assume that means drm-misc-next is now in and we can proceed with backmerge (I see Rodrigo's drm-intel-next PR is there too)?
<danvet> dolphin, yeah I pinged you before easter
<danvet> or at least wanted to
<danvet> maybe triple check with ci that drm-tip is all fine
<dolphin> you pinged about not to backmerge yet, but if you also said it's good to go I did miss that indeed
<danvet> all the -next pulls before easter should be in
<danvet> dolphin, it was fairly late on Thu, I guess you were gone already
<danvet> also -fixes is on -rc6 for anyone who needs that, just pushed that out
<dolphin> doesn't seem any more broken than before at : https://intel-gfx-ci.01.org/tree/drm-next/combined-alt.html
<danvet> dolphin, btw 2 kerneldoc warnings from -gt-next I think, see sfr mails
godvino has quit [Read error: Connection reset by peer]
sgruszka has quit [Remote host closed the connection]
djbw has quit [Read error: Connection reset by peer]
sgruszka has joined #dri-devel
godvino has joined #dri-devel
Zopolis4_ has quit []
godvino has quit [Read error: Connection reset by peer]
_xav_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
_xav_ has joined #dri-devel
thenemesis has joined #dri-devel
Danct12 has quit [Read error: Connection reset by peer]
devilhorns has quit []
Danct12 has joined #dri-devel
thenemesis has quit []
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
vliaskov has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
Company has joined #dri-devel
jaganteki has quit [Remote host closed the connection]
Danct12 is now known as Guest10619
Danct12 has joined #dri-devel
Guest10619 has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
aravind has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
itoral has quit [Remote host closed the connection]
<DavidHeidelberg[m]> we have new flake since yesterday: dEQP-VK.draw.dynamic_rendering.complete_secondary_cmd_buff.linear_interpolation.no_offset_4_samples any idea who could be the offender (6x times since yesterday)
<daniels> DavidHeidelberg[m]: which hw?
<DavidHeidelberg[m]> daniels: right.. also Raven: radv-raven-vkcts:amd64
<hakzsam> it's a known flake
<DavidHeidelberg[m]> kk, thanks
<DavidHeidelberg[m]> adding into flakes
thenemesis has joined #dri-devel
<DavidHeidelberg[m]> thx
fxkamd has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
bmodem has joined #dri-devel
Danct12 has quit [Quit: WeeChat 3.8]
i509vcb has joined #dri-devel
stuarts has joined #dri-devel
<danvet> in general for any rh patches really :-)
<danvet> also I guess tom rix should get drm-misc commit rights?
<karolherbst> mhh dunno
<karolherbst> maybe
<danvet> there's been a pile of patches and I see more all over
<karolherbst> but most patches are mostly about fixing compiler warnings
<danvet> yeah still you can push those
<karolherbst> but yeah, I have a list I need to go through
<danvet> sucking away other maintainer time isn't great even for this kind of stuff :-)
<karolherbst> right
<danvet> my take at least
<danvet> like same for doc patches or whatever (but I'm still hoping on some good editor magically showing up for dri-devel docs)
<karolherbst> heh
<karolherbst> yeah, let me collect Toms patches today, I wanted to do that anyway
<danvet> the amd ones need to go through agd5f but everything else should be fine for -misc
<danvet> didn't yet see an i915 one
mbrost has joined #dri-devel
kts has joined #dri-devel
<javierm> danvet: how was the struct fb_var_screeninfo .activate set to FB_ACTIVATE_KD_TEXT issue found ooi? It was by fuzzing?
<danvet> javierm, I wanted to validate ->activate in the drm fb helpers and realized I couldn't
<danvet> it's fundamentally control flow that the top-level callers need to get right
<karolherbst> uhh.. what's the best way to fetch patches if patchwork is annoying?
<danvet> lore
<javierm> danvet: I see
<danvet> doens't add the tags
<karolherbst> lore doesn't have it either
<danvet> then it never went to the list
<danvet> most likely at least
<karolherbst> ahh, there it is
The_Company has joined #dri-devel
The_Company has quit [Read error: Connection reset by peer]
The_Company has joined #dri-devel
<javierm> hmm, you are right that some are missing. Strange
<karolherbst> yeah.. so I oversaw two patches (but there were older versions of the same thing, so I picked those)
<karolherbst> most of the other are either pushed or have review pending
<karolherbst> also.. I really have to CI my patchwork update script stuff
<karolherbst> now the patch in pwclient I relied on is even upstreamed
Company has quit [Ping timeout: 480 seconds]
<dolphin> danvet: did the backmerge of drm-next to drm-intel-gt-next
fxkamd has quit []
Danct12 has joined #dri-devel
jewins has joined #dri-devel
tleydxdy has joined #dri-devel
<tleydxdy> I'm prototyping some kernel patches, and I want to have a test to interact with drm ioctls directly (not throught libdrm), right now I'm getting EPERM even though the ioctl call is allowed on the render node, any ideas?
<tleydxdy> I just put toghether the struct and call ioctl() on the fd
<danvet> javierm, since thomas isn't around, did you see https://lore.kernel.org/dri-devel/4Psm6B6Lqkz1QXM@panix3.panix.com/ ?
<tleydxdy> not sure if there's anything additional I need to do
<danvet> sounds like it's about legacy bios fun
<danvet> mlankhorst, mripard drm-misc-fixes still stuck on -rc2, maybe backmerge?
<danvet> it already has more patches so ff isn't an option
<danvet> mairacanal, yeah running composition tests in kunit is maybe too much work, since it'd require porting a pile of the igt infrastructure for rendering
<danvet> my idea was to essentially do exactly what igt does, but in a kunit
<danvet> and driving vkms directly
yuq825 has quit []
<danvet> it has the upside that you could compare raw buffers instead of just crc
aravind has quit [Ping timeout: 480 seconds]
thenemesis has quit []
pcercuei has joined #dri-devel
<javierm> danvet: yeah, I had in my TODO but didn't dig on it yet. Let me take a look
<danvet> javierm, yeah nw, just pinging things I see fly by :-)
<javierm> danvet: hmm, it seems the BIOS is reporting a wrong LFB and was relying on bpp always being set to lfb_depth
<javierm> VESA is the gift that keeps on giving :)
<danvet> robclark, I'm kinda assume you're lockdep-testing locking changes :-P
Duke`` has quit [Ping timeout: 480 seconds]
<danvet> but I've had cases where people acked/tested-by stuff without that ...
<robclark> I guess I should double check.. but I _assume_ we have lockdep enabled in the CI build that gets igt run on it..
<robclark> if we don't, that is an obvious oversight to fix
<robclark> but yeah, I do have lockdep enabled when making locking changes ;-)
Duke`` has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
thenemesis has joined #dri-devel
The_Company is now known as Company
bmodem has quit [Ping timeout: 480 seconds]
<javierm> danvet: dunno what's going on, it seems the kernel and grub don't agreed on the passed video mode. I asked the reporter for more info
<javierm> but can't spot anything wrong in Thomas' patch...
jkrzyszt has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
Duke`` has quit []
<eric_engestrom> Mesa 23.1 branchpoint in 24h; ping me early if this is an issue for you :)
swalker__ has quit [Remote host closed the connection]
kzd_ has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<mairacanal> danvet, i don't know exactly how this could work, as kunit is more of a unit testing framework than a full-scope testing framework
<mairacanal> also, it might be hard to port the whole igt rendering infrastructure to kunit
<mairacanal> on the other hand, it would be nice to see unit tests for vkms formats for example, as format conversion is not tested on igt afaik
<mairacanal> i believe that kunit tests go better with this type of isolated function testing
<danvet> yeah ...
<danvet> plus it sounds like emersion is going to type some userspace for this
<emersion> do we want CRTC background, or plane background for vkms?
<emersion> plane background would be a bit more useful, but may not reflect how some hw works
chipxxx has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
chipxxx has joined #dri-devel
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #dri-devel
gouchi has joined #dri-devel
kzd_ has quit []
kzd has joined #dri-devel
<javierm> mairacanal: agreed
frieder has quit [Ping timeout: 480 seconds]
<mairacanal> emersion, we were targeting CRTC background
<emersion> i'd prefer to have the other one, is what i'm saying
fe_sch[m] has quit []
mbrost has quit [Ping timeout: 480 seconds]
jaganteki has joined #dri-devel
<melissawen> emersion, looking drmdb, it seems there are drivers using something as a downstream CRTC background property here (?) https://drmdb.emersion.fr/properties?object-type=3435973836
<melissawen> but if plane bkg is more relevant for userspace
<melissawen> I'd also prefer a plane bkg so
<emersion> hm i don't think this driver is upstream
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
gouchi has quit [Remote host closed the connection]
thenemesis has quit []
Daanct12 has joined #dri-devel
Haaninjo has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
Daaanct12 has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Daanct12 has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
<karolherbst> anybody experience with kernels warning about interrupt handler enabling interrupts?
<karolherbst> a user posted an issue and it has a warning like "irq 127 handler nvkm_intr+0x0/0x240 [nouveau] enabled interrupts"
<karolherbst> but somehow none of this makes much sense to me
xep0 has joined #dri-devel
<karolherbst> but we also never call local_irq_enable
a-865 has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
a-865 has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
alarumbe has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
elongbug has quit [Remote host closed the connection]
gouchi has joined #dri-devel
Duke`` has joined #dri-devel
<jenatali> Hm, why didn't https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22428 get a label automatically applied?
<jenatali> Not a draft, not already labeled...
<jenatali> And I see a rule for '^src/gallium/frontends/va/'
<jenatali> Hm, is mr-label-maker working at all?
<javierm> karolherbst: is weird indeed, I'm looking at https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/nouveau/nvkm/core/intr.c#L164 and AFAICT the function always call to the _locked variants
<javierm> that never do spin_lock_irq{save,restore}
<javierm> and all the function handlers executed are just writing to registers, nothing more
MajorBiscuit has quit [Quit: WeeChat 3.6]
<karolherbst> yeah.. it's weird
<karolherbst> maybe some function call somewhere, but...
<karolherbst> there is a lot of indirection going on
<karolherbst> but yeah...
<karolherbst> here is the bug report btw https://gitlab.freedesktop.org/drm/nouveau/-/issues/206
<karolherbst> jenatali: yeah.. looks dead
<karolherbst> daniels: MR Label Marker seems to be dead
alarumbe has joined #dri-devel
<DemiMarie> Would it be safe for Qubes OS to replace the old Mesa package in its dom0 with a newer one?
<karolherbst> I doubt anybody here would know
<karolherbst> 1. what is considered safe, 2. what's the version currently shipped 3. what's the version considered as a replacement
<psykose> yes. ship it
<karolherbst> if 1 is about safe as in backwards/forwards compatible, then yes
<karolherbst> if it's about security? no idea
<javierm> karolherbst: I think that followed all the call paths and couldn't find any place where IRQs would be re-enabled... I wonder what we are missing
<karolherbst> maybe some funky downstream patch, no idea
<karolherbst> I never seen this error in my life
<javierm> karolherbst: maybe ask them if they have a kernel with debug symbols to do: ./scripts/faddr2line drivers/gpu/drm/nouveau/nouveau.ko nvkm_intr+0x0/0x240
<javierm> or something like that, it might give more info that the current traces
<karolherbst> well, it's just the address of the function
<karolherbst> nah
<javierm> karolherbst: ah
<karolherbst> the kernel just prints the address of the handler
<karolherbst> and does so after the call
<karolherbst> I'd like to know what or where IRQs were reenabled, but I doubt there is a cheap way of figuring that out
<javierm> not that useful then :(
<karolherbst> could dump_stacktrace in each enablement of IRQs :D
<karolherbst> but...
<javierm> karolherbst: or ftrace using the graph and filter irq_enable() ?
<DemiMarie> karolherbst: Safe as in it won’t pull in a huge swath of dependencies (other than LLVM) and won’t break apps
gouchi has quit [Remote host closed the connection]
kugel has quit [Quit: Lost terminal]
tanty has quit [Quit: Ciao!]
chipxxx has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
<karolherbst> in this case mesa is always safe
kugel has joined #dri-devel
kugel has quit []
kugel has joined #dri-devel
pcercuei has quit [Quit: dodo]
tanty has joined #dri-devel
tanty has quit []
Duke`` has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]
<daniels> karolherbst: give me an MR which it didn't tag?
tanty has joined #dri-devel
<karolherbst> but all the newest ones aren't taged
<karolherbst> by it at least
<daniels> karolherbst: yeah, seems like
kugel has quit [Quit: Lost terminal]
<daniels> {"error":null,"exit_code":0,"id":"b7f60a7a-20b8-41d1-a975-8f2b1a2d6be8","name":"process webhook","stderr":"","stdout":"https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22428 | frontends/va: disable skip_frame_enable in vaapi interface.\nunable to determine labels\n"}
<daniels> so just missing a regex by the looks
iive has quit [Quit: They came for me...]
<daniels> (whot is better to ping for that btw)
kugel has joined #dri-devel
kugel has quit []
kugel has joined #dri-devel
kugel has quit [Quit: Lost terminal]
kugel has joined #dri-devel
kugel has quit []
kugel has joined #dri-devel
xep0 has quit [Remote host closed the connection]
<karolherbst> mhh, jenatali said there was one already, but I didn't double check
<jenatali> I don't see why that wouldn't apply...
danvet has quit [Ping timeout: 480 seconds]
<daniels> I’d ping whot and check if he can debug
<jenatali> whot: ^^
elongbug has joined #dri-devel
<jenatali> Hm, looks like he's not here?
<daniels> it’s now part of the webhook spam-fighting skynet
<daniels> try #freedesktop
<jenatali> 👍
stuarts has quit []
sarnex_ has joined #dri-devel
sarnex has quit [Ping timeout: 480 seconds]
sarnex_ has quit []
sarnex has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]