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]
<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
<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
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
<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
<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?