sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
vliaskov__ has joined #dri-devel
fab has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
sguddati has joined #dri-devel
sguddati1 has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
jkrzyszt has joined #dri-devel
root____ has joined #dri-devel
root____ has left #dri-devel [#dri-devel]
haaninjo has joined #dri-devel
rasterman has joined #dri-devel
siak has joined #dri-devel
siak has quit []
siak has joined #dri-devel
apinheiro has joined #dri-devel
<mwalle>
hi, how is devm_drm_bridge_alloc() supposed to work if the bridge is part of an encoder struct which is in turn allocated (and initialzed) by drmm_simple_encoder_alloc()?
<mwalle>
lucaceresoli: see drivers/gpu/drm/tidss/tidss_encoder.c
kts has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
haaninjo has quit [Quit: Ex-Chat]
MrCooper_ has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
<sima>
rodrigovivi, imre said that your rerere commit 5dd2d660323d78890f92809be3413a77f8e41f07 has apparently a wrong interim conflict resolution for "drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to TRAINING_PATTERN_SET" in -fixes vs -next, and imre's in 7f2bb7f564c4c is the right one
<sima>
can you pls try to sort this out with imre?
<sima>
airlied, ^^ also heads-up so we make sure we don't accidentally land this, or send a bogus example conflict resolution to linus in the main merge window pr
<sima>
imre, did you see a mail from sfr about the conflict in linux-next fly by on dri-devel?
<sima>
you should get cc'ed if you've authored/committed one of the involved commits
rasterman has quit [Remote host closed the connection]
rasterman has joined #dri-devel
<lucaceresoli>
mwalle: this topic has been discussed between jani and mripard w.r.t. panels for devm_drm_panel_alloc(), but for bridges it's the same
<lucaceresoli>
mwalle: TL;DR: the bridge will have to be allocated dynamically (yes, that's a bit of annoyance for drivers which currently embed it, but not quite avoidable)
<imre>
sima, rodrigovivi, yes rodrigo asked me if that resolution was ok and I acked it, so my fault. The correct resolution is 'ret = drm_dp_dpcd_probe(aux, DP_TRAINING_PATTERN_SET);' in the result not 'ret = drm_dp_dpcd_probe(aux, DP_LANE0_1_STATUS);'. Sorry for that.
<lucaceresoli>
mwalle: and you can either have a wrapper struct that embeds the bridge, and devm_drm_bridge_alloc() that struct, if it makes sense
sguddati has quit [Ping timeout: 480 seconds]
<sima>
imre, rodrigovivi ah ok, then revert of that drm-rerere commit and retrying with dim rebuild-tip should be enough
<imre>
sima, rodrigovivi, I suppose reverting 5dd2d660323d from drm-rerere and perhaps also doing a 'dim rebuild-tip' would fix this.
<sima>
yeah that should usually do the trick
<imre>
sima, ok
<sima>
it's even documented as the procedure
<imre>
I'll answer now to sft as well
<imre>
sfr
<sima>
oh, do you have the link for that one for here?
<mwalle>
lucaceresoli: thanks for the pointers, i'll have a look later. right now i'm getting a refcnt overflow warning with the latest next (as it is expected i'd guess if the bridge isn't initialzed)
<imre>
it's the correct resolution, so no need for me to answer
jfalempe has joined #dri-devel
siak_ has joined #dri-devel
sguddati has joined #dri-devel
<mwalle>
lucaceresoli: I'd probably need a wrapper to get a reference the private struct of the driver (within the bridge_functs), right? Ie. struct tidss_encoder_bridge { struct drm_bridge bridge; struct tidss_encoder *encoder}. Then go from drm_bridge to tidss_encoder_brigde and use the pointer to get the original private struct
siak has quit [Ping timeout: 480 seconds]
MrCooper_ is now known as MrCooper
<sima>
imre, ah yeah that's just standard adjacent line changes stuff, standard fare for linus to sort out
<sima>
just need to get drm-tip fixed
<lucaceresoli>
mwalle: indeed the refcnt warning is expected with current -next, because kmalloc or any other "classic" allocation process won't initialize the refcnt, thus it will start from 0 hence the warning
<lucaceresoli>
mwalle: and yes, your code snippet looks like a good solution
<eric_engestrom>
yeah I just saw that, cancelled it
<eric_engestrom>
it's because it picked the MR, then got unassigned while it was rebasing it, and then pushed it
<eric_engestrom>
bad timing
MrCooper_ has joined #dri-devel
MrCooper is now known as Guest22083
MrCooper_ is now known as MrCooper
Guest22083 has quit [Ping timeout: 480 seconds]
warpme is now known as Guest22084
sguddati has quit [Ping timeout: 480 seconds]
K900 has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
K900 has joined #dri-devel
sguddati has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
sguddati has joined #dri-devel
rasterman has quit [Remote host closed the connection]
rasterman has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
MrCooper_ has joined #dri-devel
karolherbst0 has joined #dri-devel
karolherbst has quit [Read error: Connection reset by peer]
MrCooper has quit [Ping timeout: 480 seconds]
karolherbst0 has quit []
karolherbst has joined #dri-devel
coldfeet has joined #dri-devel
sguddati has joined #dri-devel
Guest22084 has quit []
warpme has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
itoral has quit [Remote host closed the connection]
flto_ has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
<alyssa>
do we have a "reversed" version of nir_dominance_lca?
<alyssa>
query returning "first block that dominates both input blocks"
epoch101 has joined #dri-devel
<alyssa>
to solve the problem of "what's the highest place in the program we can insert an instruction with given sources"
<alyssa>
hmm nir_opt_sink must do that..
<alyssa>
hmm it uses nir_dominance_lca, maybe I'm confused
YuGiOhJCJ has quit []
* alyssa
does local version first
warpme has quit []
siak_ has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
guludo has joined #dri-devel
feaneron has joined #dri-devel
nerdopolis has joined #dri-devel
sguddati has quit [Remote host closed the connection]
siak has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
sgerhold has quit [Quit: :/]
minecrell has quit [Quit: :/]
MrCooper_ is now known as MrCooper
<MrCooper>
zmike: just bisected GALLIUM_HUD not working anymore to "gallium: de-pointerize pipe_surface"
<zmike>
uhh
<zmike>
you're welcome?
* zmike
panics
sgerhold has joined #dri-devel
<rodrigovivi>
airlied sima, on drm_netlink for ras, what do you envision as a standard user space consumer?
Matombo has quit [Remote host closed the connection]
Matombo has joined #dri-devel
SquareWinter68_ has joined #dri-devel
SquareWinter68 has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
fab has quit [Quit: fab]
mvlad is now known as Guest22102
Guest22102 has quit [Read error: Connection reset by peer]
mvlad has joined #dri-devel
kzd has joined #dri-devel
yshui_ has quit [Remote host closed the connection]
yshui has joined #dri-devel
<gfxstrand>
dcbaker: How do you feel about adding a src/python?
<gfxstrand>
And is there a good way we could make that land in the import path of every script in the tree?
rsalvaterra has quit [Ping timeout: 480 seconds]
<gfxstrand>
Like, I would love it if we had a src/python that just showed up as a mesabuild module so you just do `import mesabuild` at the top of your script and you get stuff
rsalvaterra has joined #dri-devel
bolson has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
minecrell has joined #dri-devel
siak has quit []
phasta has quit [Quit: WeeChat 4.6.2]
<eric_engestrom>
gfxstrand: there's the sys.path.insert() thing, it's ugly but it's reliable
<gfxstrand>
Yeah
<eric_engestrom>
(grep for that in the tree for plenty of examples)
kts has joined #dri-devel
<gfxstrand>
Yeah, I found a few
<eric_engestrom>
gfxstrand: what kind of thing are you looking to put in there?
fab has joined #dri-devel
sarnex has quit []
Duke`` has joined #dri-devel
Company has joined #dri-devel
<karolherbst>
alyssa: 276501755364d72b55de810e728981e78c6ee0e0 is regression some CL stuff on radeonsi
<karolherbst>
maybe some weirdo spirv handling missing...
<glehmann>
is it the splitting or the fusing that breaks it?
<karolherbst>
wished I'd knew
<karolherbst>
okay so disabling those 4 opts fixes it...
<sima>
rodrigovivi, tried to not think about that, maybe airlied has an idea
<gfxstrand>
eric_engestrom: We've got some utils in nouveau for rust generators
<sima>
or perhaps agd5f or someone else from amd thought about it
<alyssa>
karolherbst: CL should be setting `exact` everywhere
<alyssa>
not my bg
<alyssa>
bug
<eric_engestrom>
gfxstrand: ack; I'd be curious to see the MR when you post it :)
<karolherbst>
at least on the fma...
<karolherbst>
but yeah.. in CL the fma can't be split.. guess I'll write a patch
<gfxstrand>
eric_engestrom: I gave up and I'm doing something dumb now
<agd5f>
sima, rodrigovivi I vaguely remember looking at it. I think Hawking and Lijo provided some comments at the time. Our RAS stack doesn't currently make use of it.
<sima>
agd5f, it's more what should the minimal open userspace for it look like, as in how much yolo
dsimic is now known as Guest22109
dsimic has joined #dri-devel
Guest22109 has quit [Ping timeout: 480 seconds]
<karolherbst>
alyssa: exact doesn't help?
<karolherbst>
like I need the fma to stay a fma for like forever
<gfxstrand>
exact should prevent it from being split
<gfxstrand>
exact means "don't do any transform on this that isn't bit-for-bit the same output"
<gfxstrand>
So splitting fma is definitely out
<karolherbst>
yeah... maybe it's something else going on, but it's kinda weird..
<karolherbst>
mhhhhh
<karolherbst>
nope it's defo those...
<karolherbst>
but it's only an issue with radeonsi
<alyssa>
ok but the patterns you linked are gated on the exact bit not being set so
<alyssa>
can you send me the NIR_DEBUG=print output please?
<karolherbst>
something nukes the exact flags...
<karolherbst>
or dunno.. mhh
<alyssa>
can you send me the NIR_DEBUG=print output please?
<alyssa>
karolherbst: vtn is failing to set on the exact bit on fadd/fmul instructions
<karolherbst>
it's legal to merge those into ffma
<alyssa>
..right, I wrote that patch didn't I.
<karolherbst>
but..
<karolherbst>
all the ffma! get cf_dceed
<karolherbst>
so...
<karolherbst>
no idea what's going on...
frieder has quit [Remote host closed the connection]
<karolherbst>
maybe just something very unfortunate
<karolherbst>
maybe it's just libclc being wrong
<dcbaker>
gfxstrand: I've wanted to do that for a long time but never gotten to it.
<alyssa>
karolherbst: can you comment out those four lines, then send me NIR_PRINT for that too?
<dcbaker>
The options other than what eric_engestrom mentioned are: 1) use the `PYTHONPATH` environment variable, 2) use a small python wrapper script instead of `prog_python` that does the path insertion automatically, and then does the python equivalent of `exec $?`
<dcbaker>
I've kinda wanted to do that approach because I have this clever idea of letting that script check your python imports and generate a depfile
<eric_engestrom>
ooh, depfile for python would be neat
<alyssa>
karolherbst: oh that's all kinds of screwed up
<alyssa>
i see the problem, gimme a minute
<karolherbst>
but I should send a patch to set exact on all fmas anyway
<karolherbst>
though the SPIR-V might already flag them...
<karolherbst>
well CL spir-v env spec says "Correctly rounded"
<alyssa>
I would like to understand why b.exact is not set
<karolherbst>
if it helps, I don't see any ContractionOff
<alyssa>
so..
<alyssa>
so why is b.exact not set?
<karolherbst>
why should it be set for everything?
<alyssa>
it's OpenCL, that's the default.
<alyssa>
...apparently it is not
<karolherbst>
yeah, but the spir-v should tell us, because how would we know what the frontend expects
<alyssa>
/ The DEFAULT value is ON.
<alyssa>
#pragma OPENCL FP_CONTRACT on-off-switch
<alyssa>
you have got to be kidding me
<alyssa>
this feels like a libclc bug.
tzimmermann has quit [Quit: Leaving]
<karolherbst>
not unlikely
<karolherbst>
cos requires <= 4 ulp, but with that change we go around 5
<karolherbst>
most of the code was written to be "good enough" for whatever hardware was targeted
<karolherbst>
(AMD)
<alyssa>
I strongly suspect the real bug here then is the libclc code explicitly asking for mad's when it should be explicitly asking for ffma's or something
<alyssa>
but also I don't care we can merge your patch I want to go back to reassociating fmuls which will break CL again (:
<karolherbst>
:D
<karolherbst>
sounds good
<karolherbst>
but anyway, on fedora the libclc spirv is at /usr/lib64/clc/spirv64-mesa3d-.spv
<karolherbst>
I kinda hope we can move to the LLVM SPIR-V target at some point and deal with all sorts of breakage :)
kts has quit [Ping timeout: 480 seconds]
<dcbaker>
gfxstrand, eric_engestrom: I threw together a really quick and probably full of corners runner script, but does work and allows loading modules from `src/python`, it's the `wip/2025-07/src-python` branch on my gitlab
kts has joined #dri-devel
sarnex has joined #dri-devel
OftenTimeConsuming is now known as Guest22117
OftenTimeConsuming has joined #dri-devel
Guest22117 has quit [Remote host closed the connection]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
smaeul_ has joined #dri-devel
smaeul has quit [Ping timeout: 480 seconds]
smaeul_ has quit []
smaeul has joined #dri-devel
chewitt has quit [Quit: Zzz..]
jkrzyszt has quit [Quit: Konversation terminated!]
swfrd_ has joined #dri-devel
sravn has quit []
mvlad has quit [Remote host closed the connection]
kts has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
kts has joined #dri-devel
sravn has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit []
sarnex has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<glehmann>
alyssa: do you have a branch with the insert change you tried
<alyssa>
glehmann: the cursor one?
<glehmann>
yes
<alyssa>
let me dig thru reflog
<glehmann>
there are some shaders where the new pass does really badly, like farcry5/0195cf650255e8c2/vs
<sarbes>
Hi. I would like to implement "normalize(vec3(xyz))" for Utgard/Lima, since there is direct HW support. Unfortunately, it seems that normalize gets lowered in NIR, so it is not entirely straight forward.
<sarbes>
It seems to me that I could go three different ways. 1) Undo the lowering in lima_nir_algebraic.py. 2) Introduce a normalize() op in NIR, with optional lowering. 3) Undo the lowering in a C pass.
<sarbes>
1) Seems to require some tinkering with the search code, as swizzles are not supported. Without some hacking, I'm not able to match the NIR pattern.
<sarbes>
2) I don't think that introducing such a "legacy" op would be accepted.
<sarbes>
3) Seems to be the best solution overall, but I would like to get some confirmation.
<alyssa>
sarbes: I'm not seeing why you can't use an algebraic rule for that?
<alyssa>
oh because of the broadcast behaviour... bah
<alyssa>
vec4 hw was a mistake
<sarbes>
Yeah. The pattern is something like "('fmul', 'a', ('frsq', ('fdot3', 'a', 'a')))"
<sarbes>
But I would need "('fmul', 'a', ('frsq.xxx', ('fdot3', 'a', 'a')))"
<alyssa>
yeah I see what you mean
<alyssa>
this is for PP?
<sarbes>
Yeah.
sima has quit [Ping timeout: 480 seconds]
<alyssa>
I guess #3 is my prefernce if it's all the same to you
<alyssa>
I wouldn't mind plumbing the op through as long as it's not invasive to other drivers, tho
<alyssa>
modifying nir_search for this is a hard no