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