ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
RAOF has quit [Remote host closed the connection]
RAOF has joined #dri-devel
RAOF has quit [Read error: Connection reset by peer]
RAOF has joined #dri-devel
pcercuei has quit [Quit: dodo]
davispuh has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
alane has quit []
alane has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
vedranm_ has joined #dri-devel
Company has joined #dri-devel
vedranm has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<ishitatsuyuki> you can lateload GPU drivers, I think it's the default on arch
<ishitatsuyuki> Loading it early gets rid of one annoying flicker
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
Kayden has quit [Quit: Leaving]
Kayden has joined #dri-devel
KitsuWhooa has quit [Quit: Unable to handle kernel NULL pointer dereference at null]
KitsuWhooa has joined #dri-devel
Stary has quit [Quit: ZNC - http://znc.in]
Stary has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
Company has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
vedranm_ is now known as vedranm
mbrost has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
bolson has quit [Remote host closed the connection]
bolson has joined #dri-devel
heat is now known as Guest1123
Guest1123 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
sima has joined #dri-devel
jsa has joined #dri-devel
fab has joined #dri-devel
dumbbell has quit [Quit: WeeChat 4.3.3]
feaneron has quit [Quit: feaneron]
fab has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
i-garrison has quit []
i-garrison has joined #dri-devel
coldfeet has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
jsa has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
frieder has joined #dri-devel
warpme has joined #dri-devel
tzimmermann has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<tzimmermann> sima, airlied, hi. can you please merge last week's PR for drm-misc-next? https://lore.kernel.org/dri-devel/20240816084109.GA229316@localhost.localdomain/
<MrCooper> DemiMarie: if the improper synchronization affects data which ends up used for shader control flow, anything seems possible
<sima> tzimmermann, will do that now, was heading out for a concert yesterday evening already
<tzimmermann> sima, ok np
<tzimmermann> spare time *is* important
coldfeet has joined #dri-devel
Dark-Show has joined #dri-devel
jkrzyszt_ has joined #dri-devel
amarsh04 has quit []
amarsh04 has joined #dri-devel
mvlad has joined #dri-devel
pcercuei has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
jsa has joined #dri-devel
rcf has quit [Quit: WeeChat 3.8]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
rasterman has joined #dri-devel
<sima> tzimmermann, done
Duke`` has quit []
apinheiro has joined #dri-devel
apinheiro has quit []
Dark-Show has quit [Quit: Leaving]
apinheiro has joined #dri-devel
amarsh04 has quit [Remote host closed the connection]
amarsh04 has joined #dri-devel
amarsh04 has quit []
rasterman has quit [Quit: Gettin' stinky!]
Duke`` has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
u-amarsh04 has joined #dri-devel
chaos_princess has quit [Quit: chaos_princess]
chaos_princess has joined #dri-devel
<jfalempe> Is it still possible to get the panic QR code reviewed for v6.12 ?
<kode54> dang
<kode54> I can't build mesa 32 bit from this developer's branch because libnak fails to build
<sima> agd5f, for the fd fixes series from al viro I'm assuming you'll just land that in amdgpu.git?
<kode54> it's also building nouveau even though I disabled nouveau
<kode54> oops, I somehow disabled nouveau for gallium, but not for vulkan
jsa has joined #dri-devel
<kode54> probably a broken tree as far as libnak is concerned, though
<kode54> (not mesa/mesa?main)
guru_ has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Ping timeout: 480 seconds]
LeviYun has quit [Remote host closed the connection]
<kode54> happening on a branch based on a8a15dc5b585b99f823c2ef2f2edb7906d0b35d1
LeviYun has joined #dri-devel
Company has quit [Remote host closed the connection]
<MrCooper> kisak: efifb or simplefb only show up on displays connected to GPUs initialized by the system firmware, which may not include e.g an external monitor connected to a laptop with dGPU
coldfeet has quit [Quit: leaving]
coldfeet has joined #dri-devel
coldfeet has quit []
guludo has joined #dri-devel
davispuh has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
coldfeet has joined #dri-devel
kaiwenjon has quit [Remote host closed the connection]
kaiwenjon has joined #dri-devel
luc has joined #dri-devel
nerdopolis has joined #dri-devel
<luc> in vulkan, what does it depend on whether to normalize a varying? e.g. outUV = vec3((gl_VertexIndex << 1) & 2, gl_VertexIndex & 2, 0.0); in vs, outUV.s is supposed to range [0, 2], but it seems to range in [0, 1] when outUV is used in fs. Would varyings in vulkan be implicitly normalized?
<tzimmermann> sima, thanks. if you have a bit, could you also forward drm-next to the most recent upstream (v6.11-rc4 IIRC) ?
<sima> tzimmermann, do you have some specific commit you need?
<tzimmermann> sima, no. i just want all the fixes
<sima> (I kinda screwed that up a bit on the last backmerge)
<sima> linus doesn't like backmerges for no reason much, so we try to avoid them a bit ...
<DemiMarie> MrCooper: is it sufficient for a Wayland compositor to not have shader control flow that depends on client-provided values?
<DemiMarie> If so, is this something Mesa would be willing to guarantee?
Daanct12 has quit [Quit: WeeChat 4.4.1]
coldfeet has quit [Quit: leaving]
<DemiMarie> If not, what is sufficient?
coldfeet has joined #dri-devel
bmodem has joined #dri-devel
<tzimmermann> jfalempe, i've reviewed patches 1 to 3. can't really say much about the rust code.
<tzimmermann> jfalempe, deadline for v6.12 is -rc6, which happens end of next week
<jfalempe> tzimmermann: thanks, yes for the rust code, I already have a review by Alice Ryhl
<jfalempe> tzimmermann: and I'm on PTO next week, so thanks again for your review.
<tzimmermann> my comments are optional. your choice
<agd5f> sima, I think that makes sense.
bolson has joined #dri-devel
<daniels> eric_engestrom: do you want to take a pass on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30784
<eric_engestrom> daniels: gladly, and thank you for doing this!
<daniels> np
<eric_engestrom> daniels: nit-pick, but why are broadcom and freedreno changes in the same commit, but everything else in its own commit?
<daniels> eric_engestrom: no set reason
<daniels> would you like to separate v3d from fdno?
<daniels> or separate igalia from google from collabora?
<eric_engestrom> I think the split of the other commits makes sense, it's just src/broadcom/ and src/freedreno/ being in the same commit that looks weird
<eric_engestrom> but again, it's a nit-pick
<eric_engestrom> I reviewed all the CI commits, r-b on all of them
<eric_engestrom> looking at the script commits now
<MrCooper> DemiMarie: it would require solving the halting problem ;)
feaneron has joined #dri-devel
kzd has joined #dri-devel
epoch101 has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
<DemiMarie> MrCooper: what do you mean?
<MrCooper> what you want is Mesa deciding whether or not the shader will terminate
<DemiMarie> No
<DemiMarie> I don't want that
<MrCooper> that's what it boils down to
<DemiMarie> In the most general case, yes, but I'm not interested in the general case.
<MrCooper> both GL and Vulkan shaders are general enough that it's the halting problem
<DemiMarie> I'm not interested in arbitrary shaders
jsa has quit [Ping timeout: 480 seconds]
<DemiMarie> I'm asking for rules that are sufficient to guarantee that unsynchronized concurrent modification of an input buffer will not cause out of bounds accesses.
rasterman has joined #dri-devel
<DemiMarie> For instance, if my shader has no control flow at all (and is thus guaranteed to terminate), is this sufficient?
bmodem has quit [Quit: bmodem]
kasper93_ has joined #dri-devel
kasper93 has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest1159
dsimic has joined #dri-devel
warpme has quit []
Guest1159 has quit [Ping timeout: 480 seconds]
<emersion> any client can infinite loop in the GPU, and that might reset the compositor's context
jsa has joined #dri-devel
<mareko> karolherbst: it looks like it's more correct for OpenCL not to evaluate constant expressions for some reason, here are examples of both CUDA and ROCm not evaluating sqrt(4) at compile time: https://godbolt.org/z/sTMb1b7WK https://cuda.godbolt.org/z/Pc38jbTro
warpme has joined #dri-devel
<karolherbst> mareko: it kinda depends, but yeah.. the question is if you guarantee that constant expression evaluate to the same as done on the GPU
<karolherbst> and I think CL doesn't make such a guarantee
<karolherbst> but maybe we do have to run all of that at the GPU... I think it's implied by the C99 spec
<mareko> that may affect perf comparisons between rusticl and other drivers
<mareko> karolherbst: also, radeonsi on RDNA 3 currently destroys all other AMD drivers in clear/copy_buffer performance
<karolherbst> 🙃
<mareko> optimizations for other generations are coming
<karolherbst> I was considering filing for conformance for rusticl+radeonsi, because AMD's official one isn't 🙃
<karolherbst> but there are 2 or 3 real annoying bugs
epoch101 has quit []
<karolherbst> and apparently idiv is also broken
<karolherbst> no idea what's wrong there, but must be radeonsi specific
<mareko> radeonsi lowers idiv in NIR
<karolherbst> yeah I know
<karolherbst> and there was a fix needed for asahi as well
<karolherbst> but even with that one it's still wrong
frieder has quit [Remote host closed the connection]
<karolherbst> but maybe I've messed up...
<mareko> oh I think radeonsi implement frcp for F32 inexactly
<mareko> *FP32
<mareko> and we don't enable FP32 denormals either
<karolherbst> ahh, that might do it
warpme has quit []
jsa has quit [Ping timeout: 480 seconds]
<DemiMarie> emersion: that's excluded from my worries
<DemiMarie> emersion: what I'm concerned about is Mesa (or LLVM) generating code that assumes there are no data races, and which becomes exploitable by a malicious client.
<DemiMarie> In Qubes OS, if one client can cause another client to misrender, that is a security vulnerability.
<karolherbst> mareko: if you can throw me a quick patch to try it out that would be helpful :) reverting the fix for asahi doesn't seem to make a different in this case, so must be something else probably
<mareko> karolherbst: oh we lower fdiv in NIR, and I think "(('fdiv', a, b), ('fmul', a, ('frcp', b)), 'options->lower_fdiv')," is definitely incorrect for OpenCL, forwarding fdiv to LLVM should fix it
<karolherbst> asahi also lowers fdiv in nir and that one is fine
<karolherbst> mhhh
<karolherbst> wait
<karolherbst> this is about idiv
<karolherbst> I think fdiv is fine regardless
<karolherbst> the only fp32 related bug I have with radeonsi is nextafter
<mareko> I'm sure fdiv isn't fine, but I don't know why you're not seeing failures
<karolherbst> because I already have a thing to make it more precise for CL
<karolherbst> nir_scale_fdiv
<karolherbst> it's also needed on e.g. nvidia
<karolherbst> but CL only needs 2.5 ULP precision here, so it's good enough
<karolherbst> mhh.. radeonsi has multithreading issues I haven't noticed before .. oh well..
<karolherbst> anyway
<karolherbst> fdiv with radeonsi: 2: divide fp32 ................passed 1.97 @ {-0x1.dafff2p-53, -0x1.dfc0e6p-84}
<karolherbst> so 1.97 ULP in avarage
<karolherbst> without scale_fdiv: ERROR: divide: -nan ulp error at {-inf, -0x1.fffffep+127}: *inf vs. -nan (0xffc00000) at index: 197 :)
sukuna has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<karolherbst> mareko: but anyway, I'm more concerned about idiv atm, because that's clearly showing a bug :)
<karolherbst> also with aco it seems
<karolherbst> ehh wait
<karolherbst> aco is fine
<mareko> nir_scale_fdiv could be inefficient, the hw has dedicated v_div_scale and v_div_fixup instructions for that
<karolherbst> ahh, good to know
<karolherbst> I guess those do the same thing given it's called "scale"
<mareko> yeah
<karolherbst> could add a nir instruction and lowering for that one
<mareko> just passing unlowered fdiv to LLVM should be enough
<karolherbst> right.. but that won't work for e.g. aco
<mareko> yeah
MrCooper_ has joined #dri-devel
<karolherbst> and I think other hardware might also have somehting like that
<karolherbst> I just know that nvidia doens't
coldfeet has quit [Remote host closed the connection]
warpme has joined #dri-devel
<karolherbst> the nir is identical between aco and llvm, so that's good I guess...
MrCooper has quit [Ping timeout: 480 seconds]
<mareko> I guess we could just pass unlowered idiv to LLVM as well
<bl4ckb0ne> :q
<karolherbst> mhh oh right.. the idiv lowering is mostly folded, because it's constant divisors
<bl4ckb0ne> wait thats not my vim term
warpme has joined #dri-devel
warpme has quit [Remote host closed the connection]
sukuna has quit [Ping timeout: 480 seconds]
MrCooper_ is now known as MrCooper
gbittencourt4 has quit []
gbittencourt4 has joined #dri-devel
sukuna has joined #dri-devel
leizhou has quit [Remote host closed the connection]
rasterman has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
jkrzyszt_ has quit [Remote host closed the connection]
rasterman has joined #dri-devel
mbrost has joined #dri-devel
kts has joined #dri-devel
leizhou has joined #dri-devel
warpme has quit []
kaiwenjon has quit [Quit: WeeChat 3.8]
kts has quit [Quit: Konversation terminated!]
warpme has joined #dri-devel
ManMower has quit [Remote host closed the connection]
ManMower has joined #dri-devel
flom84 has joined #dri-devel
kaiwenjon has joined #dri-devel
flom84 has quit []
rasterman has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: -> jf]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
<karolherbst> mareko: it seems to be an issue with nir_opt_idiv_const actually....
warpme has quit []
<karolherbst> if I disable that pass, llvm sdiv/udiv and nir_lower_idiv both work
<karolherbst> if I don't, both fail as well
<karolherbst> mhh, the main difference seems to be v_mul_hi_i32_i24_e32 (aco) and v_mul_hi_u32 (llvm)
<karolherbst> ehh, the other way around, v_mul_hi_i32_i24_e32 is from LLVM
jsa has joined #dri-devel
bolson has quit []
<zamundaaa[m]> Demi: the wrong rendering would happen only in the window of the bad client
<zamundaaa[m]> Which the client can already do anyways
<DemiMarie> zamundaaa: is that guaranteed?
<pendingchaos> that's probably the bug. v_mul_hi_u32(a, b) where signext_24_32(a)==a && signext_24_32(b)==b isn't the same as v_mul_hi_i32_i24_e32(a, b) if a or b is negative
<zamundaaa[m]> If the compositor doesn't do anything really stupid
<zamundaaa[m]> If a GPU reset happens, that could corrupt the whole screen temporarily, but you don't need to send the compositor any data to cause one
<karolherbst> pendingchaos: mhh... that would be a bug in LLVM then, no? Because nir_to_llvm simply emits LLVMBuildMul with some shifts
<DemiMarie> zamundaaa: does that mean that Mesa’s optimizers are not allowed to introduce time-of-check to time-of-use issues to shaders?
<karolherbst> or mhh..
<zamundaaa[m]> I'm not sure what you mean?
* DemiMarie thinks if she needs to use a pastebin for a code block
<karolherbst> the reporter also uses llvm-18...
vliaskov has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
coldfeet has joined #dri-devel
Haaninjo has joined #dri-devel
<DemiMarie> (put in a gist to not confuse IRC users)
<zamundaaa[m]> I don't know if there's guarantees for that, but fetching pixels from the buffer multiple times would be bad for performance
<zamundaaa[m]> So I doubt it would ever do such a thing
<pendingchaos> I can imagine situations where that transformation might be beneficial
<pendingchaos> whether it's allowed or not probably depends on what kind of load "c[0]" is and what's between "a = c[0]" and "b[a] = 0"
bolson has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
cmarcelo has joined #dri-devel
<DemiMarie> In C it is allowed unless c is a pointer to an _Atomic type, but GLSL doesn’t have those and even if it did I doubt compositors would use them for these operations.
sima has joined #dri-devel
leizhou has quit [Remote host closed the connection]
leizhou has joined #dri-devel
<DemiMarie> pendingchaos: that’s what makes me nervous.
kaiwenjon has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<DemiMarie> Are there any formats that have an alpha channel and for which there is no opaque format with the same layout?
Company has quit [Read error: Connection reset by peer]
<DemiMarie> If I get an image in ARGB8888, I can tell a compositor to treat it as XRGB8888 without needing to make any copies. Are there any formats for which there is no opaque version?
Company has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
rz_ has quit [Ping timeout: 480 seconds]
leizhou has quit [Remote host closed the connection]
gbittencourt4 has quit []
sukuna has quit [Ping timeout: 480 seconds]
gbittencourt4 has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
rasterman has quit [Ping timeout: 480 seconds]
guru_ has quit []
oneforall2 has joined #dri-devel
gouchi has joined #dri-devel
leizhou has joined #dri-devel
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
leizhou has quit []
ManMower has quit [Remote host closed the connection]
caliking916 has joined #dri-devel
kaiwenjon has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
caliking916 has quit []
mbrost_ has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
luc has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
caliking916 has joined #dri-devel
dv_ has quit [Quit: WeeChat 3.8]
vliaskov has joined #dri-devel
mvlad has quit [Remote host closed the connection]
caliking916 has quit []
crabbedhaloablut has quit []
Haaninjo has quit [Quit: Ex-Chat]
crabbedhaloablut has joined #dri-devel
ManMower has joined #dri-devel
guludo has quit [Quit: WeeChat 4.3.6]
crabbedhaloablut has quit []
gouchi has quit [Quit: Quitte]
epoch101 has joined #dri-devel
crabbedhaloablut has joined #dri-devel
mbrost has joined #dri-devel
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
kaiwenjon has quit [Read error: Connection reset by peer]
kaiwenjon has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
kaiwenjon has quit []
kaiwenjon has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
docmax has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
cambrian_invader has joined #dri-devel
nopjmp has quit [Remote host closed the connection]
nopjmp has joined #dri-devel
Kayden has quit [Quit: -> home]
pa has joined #dri-devel
mbrost has joined #dri-devel
heat has quit [Remote host closed the connection]
vliaskov has quit [Ping timeout: 480 seconds]
gbittencourt4 has quit []
gbittencourt4 has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]