ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<daniels>
jenatali: anything in particular?
<daniels>
DemiMarie: the API doesn’t make it possible, but even if it did, it would be a case of ‘play stupid games, win stupid prizes’
<jenatali>
daniels: I've been hit by a freedreno (a630) and turnip (zink) flake today, but I feel like in recent weeks I've woken up to a spam of "assigned to Marge, CI failed, assigned to Marge, ..." emails
<daniels>
jenatali: urgh. off tomorrow but will drudge through the stats next week
<DemiMarie>
daniels: what do you mean? I know that modifying a buffer that has been passed to Mesa is bad. The question is *how* bad. The problem is that these buffers come from untrusted clients, which might try to exploit e.g. TOCTOU vulnerabilities. And forcing a defensive copy is not great for performance.
<daniels>
DemiMarie: I don't know what you're trying to defend against. if the client wants to render garbage, it doesn't need to bother racing the compositor, it can just render garbage anyway
<jenatali>
And if it is racing the compositor, it'll race a defensive copy too
<DemiMarie>
daniels jenatali: the question is if rendering garbage is the *only* possible consequence
jfalempe_ has quit [Remote host closed the connection]
jfalempe_ has joined #dri-devel
<anholt>
jenatali: so, tomeu said he'd run the ci_run_n_monitor in stress mode for the new coverage that would be both fd and turnip flakes today, would have hoped that he was scraping #freedreno-ci when doing that
<daniels>
DemiMarie: yeah
<jenatali>
anholt: Ah, didn't realize new coverage was coming online, that makes sense
<anholt>
jenatali: !19071
<jenatali>
Thanks
<daniels>
anholt: tbh ci_run_n_monitor should really be picking up flakes itself
<anholt>
daniels: wouldn't that be fancy.
<daniels>
anholt: yeah, WIP :)
<anholt>
oh my.
<anholt>
it is hard to express how excited I am for that.
<anholt>
flake management of new coverage is so much of what I do.
<DemiMarie>
daniels: Okay, thanks! The reason I wasn not sure is that in C/C++/Rust, data races mean that *anything* can happen, including e.g. overflowing buffers or jumping to random locations (though likelyhood of this in practice is low)
<daniels>
anholt: yeah, it's annoyed me for a little bit that this is largely based on people manually eyeing IRC channels which are mainly full of noise
<daniels>
DemiMarie: again, if client pixel buffer data is an attack vector, you don't need to win a race against the compositor for this to be useful, you just need to supply the broken data to begin with
<DemiMarie>
daniels: that is not true for *all* kinds of data (consider the case where a length is read, bounds-checked, then read again). Hence why I wanted to make sure that Mesa does not e.g. do something unsafe if two consecutive reads of pixel data return different values.
<anholt>
DemiMarie: nothing in mesa is parsing pixel data like that.
<DemiMarie>
anholt: I figured as much, but was wondering if there could be problems due to e.g. NIR optimizations of shaders.
iive has quit [Quit: They came for me...]
<anholt>
if the user's shader is trying to do something like that on shared buffers, that's something they can choose to do, but that's not mesa's problem.
heat_ has quit [Ping timeout: 480 seconds]
ahajda_ has quit []
loki_val has joined #dri-devel
<daniels>
it could in theory be an attack vector you could construct if you really tried, but you'd have to try to a pathological extent
crabbedhaloablut has quit [Ping timeout: 480 seconds]
orbea has quit [Remote host closed the connection]
orbea has joined #dri-devel
<anholt>
ajax: I feel like I've gone down this rabbit hole before, but is the Xorg we're using in CI going to be doing automatic compositing by default?
samuelig__ has quit []
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<alyssa>
ok... the upside down thing is a bit of a red herring
<alyssa>
when presenting upside down quake, there's also no HUD!
<alyssa>
like we're presenting the wrong buffer
<alyssa>
or rendering to the wrong buffer, I suppose
ybogdano has quit [Ping timeout: 480 seconds]
<alyssa>
-------Or this is just all racey
Daanct12 has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
<DemiMarie>
anholt daniels: what I was trying to figure out is if Mesa generates GPU machine code that does that kind of stuff if the source code does not do it. It sounds like the answer is ”no”.
<jessica_24>
that hint to the compositor to mark a specific ROI as solid fill without the compositor having to calculate that
<jessica_24>
(sorry for the late response btw, just wanted to confirm some details about the android hwc with the team first)
rmckeever has quit [Quit: Leaving]
dviola has quit [Quit: WeeChat 3.7.1]
yuq825 has joined #dri-devel
Company has quit [Quit: Leaving]
tzimmermann has joined #dri-devel
Duke`` has joined #dri-devel
fxkamd has quit []
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
jewins has quit [Read error: Connection reset by peer]
neobrain[m] has quit []
fab has joined #dri-devel
<tomeu>
anholt: I did rather scrape it from the job logs, but it was a manual job and there are so many tests with very similarly names flaking that I could have missed some
bgs has joined #dri-devel
<tomeu>
something I have wished in the past is to only log to irc the flakes that aren't known yet
<tomeu>
with some drivers emitting so many flake notifications each run, following those channels properly would be quite time consuming
Danct12 has quit [Read error: Connection reset by peer]
tursulin has joined #dri-devel
fab has joined #dri-devel
jkrzyszt has joined #dri-devel
danvet has joined #dri-devel
samuelig has joined #dri-devel
sgruszka has joined #dri-devel
djbw has quit [Ping timeout: 480 seconds]
<mareko>
what is our policy regarding anonymous unions and structs?
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
Daaanct12 has quit [Remote host closed the connection]
<MrCooper>
mareko: AFAIK they're a GCC extension, do they work with MSVC?
<glennk>
included in c11
<MrCooper>
anholt: AFAIK the only case where automatic compositing is enabled by default is still when the window visual doesn't match the parent/root window's
<MrCooper>
glennk: cool, then Mesa could use them
lynxeye has joined #dri-devel
pcercuei has joined #dri-devel
sysescool has quit [Remote host closed the connection]
sysescool has joined #dri-devel
sysescool has quit [Remote host closed the connection]
sysescool has joined #dri-devel
sarahwalker has joined #dri-devel
sysescool has quit [Ping timeout: 480 seconds]
anarsoul has quit [Remote host closed the connection]
anarsoul has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
idr_ has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
Edgrs has joined #dri-devel
Edgrs has quit []
anholt_ has joined #dri-devel
anholt has quit [Read error: Connection reset by peer]
Lucretia has quit []
Lucretia has joined #dri-devel
<pcercuei>
Working on a DMABUF importer right now. I have an IOCTL to dma_buf_attach(). Do I need an IOCTL to dma_buf_detach() as well? What happens if userspace calls the former, then just fclose the DMABUF? Does this automatically call dma_buf_detach() on all attachments?
Major_Biscuit has quit [Ping timeout: 480 seconds]
Akari has joined #dri-devel
rasterman has joined #dri-devel
<lynxeye>
pcercuei: No the attachment holds a separate reference to the dmabuf. What exactly does the ioctl do? Why is userspace directly responsible for creating the attachment?
fab has quit [Quit: fab]
rgallaispou has quit [Read error: Connection reset by peer]
<pcercuei>
lynxeye: I'm working on an importer, so the DMABUFs are created externally (with udmabuf in my case, for now)
<pcercuei>
So I believe I need an IOCTL to map each DMABUF with my device (create a dma_buf_attachment)
Edgrs has joined #dri-devel
Edgrs has quit []
<pcercuei>
What I don't really know is if I need an IOCTL to request a "detach" as well, and what happens if userspace doesn't call it and just close the DMABUF file descriptor
itoral has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
Major_Biscuit has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
Major_Biscuit has joined #dri-devel
Leopold_ has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
<MrCooper>
pcercuei: dma-buf fds can be closed anytime after import, this does not automatically destroy the BO which resulted from the import
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
fxkamd has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<lynxeye>
pcercuei: The fd you get in userspace is just a handle/reference to the dma-buf. You keep it open as long as you need it to transfer the dma-buf from exporter to importer. Your importer would then attach to the dmabuf and keep it alive that way, userspace can close the handle at that point. Your importer needs some kind of tracking for all the dma-bufs it has attached to, so you can cleanup when your importer context goes away (e
<lynxeye>
he driver fd is closed).
jewins has joined #dri-devel
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
Haaninjo has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
rgallaispou has joined #dri-devel
<pcercuei>
MrCooper, lynxeye: ok, thanks
Duke`` has quit []
Duke`` has joined #dri-devel
Duke`` has quit []
Akari has quit [Ping timeout: 480 seconds]
junaid has quit [Ping timeout: 480 seconds]
soreau has quit [Remote host closed the connection]
kts has joined #dri-devel
fxkamd has quit []
soreau has joined #dri-devel
djbw has joined #dri-devel
ybogdano has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
rgallaispou has quit [Read error: Connection reset by peer]
iive has joined #dri-devel
Major_Biscuit has quit []
Duke`` has joined #dri-devel
rgallaispou has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
devilhorns has quit []
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
ppascher has joined #dri-devel
Akari has joined #dri-devel
Company has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
\10X has joined #dri-devel
\10X has quit [autokilled: This host violated network policy. Mail support@oftc.net if you think this is in error. (2022-11-18 17:04:54)]
rasterman has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
mhenning has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
ybogdano has joined #dri-devel
gouchi has joined #dri-devel
kts has quit [Quit: Leaving]
alanc has quit [Remote host closed the connection]
Guest1881 has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<emersion>
bl4ckb0ne: nope, and can't even do that between 2 gpus of the same vendor
<emersion>
> Applications must only import external semaphore handles exported from the same device or set of devices used by the current context, and from compatible driver versions.
<emersion>
basically you need to check that the UUIDs match before using the ext
Kayden has quit [Ping timeout: 480 seconds]
<bl4ckb0ne>
huh
<bl4ckb0ne>
how is this even working then
<emersion>
it's used to share resources between GL and Vulkan, when GL and Vulkan are running the same driver
OftenTimeConsuming has quit [Remote host closed the connection]
<bl4ckb0ne>
no, i mean the setup that i have
<emersion>
it's deliberately using opaque driver-specific handles
<emersion>
maybe it works by chance thanks to mesa
<bl4ckb0ne>
monado running on radv, and wxrc on iris
<bl4ckb0ne>
still getting major tiling issues but i get something renderer
<bl4ckb0ne>
rendered*
OftenTimeConsuming has joined #dri-devel
<bl4ckb0ne>
so it works by chance but really shouldnt
<bl4ckb0ne>
should it be fixed?
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
jewins has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
lygstate has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
<lygstate>
Recently I monitored flakes requently, I found the Mesa CI Daily Report didn't helped much about found flakes much
haagch has quit [Quit: No Ping reply in 180 seconds.]
<haagch>
if you patch monado to use linear tiling instead of optimal tiling it probably works magically thanks to prime magic
<haagch>
pretty sure it doesn't work with nvidia proprietary driver at all
<jenatali>
Wow, !19816 is on merge attempt #7
mvlad has quit [Remote host closed the connection]
OftenTimeConsuming is now known as Guest1886
OftenTimeConsuming has joined #dri-devel
macromorgan has quit [Quit: Leaving]
Guest1886 has quit [Remote host closed the connection]
haagch has quit [Quit: No Ping reply in 180 seconds.]
tagr has quit [Remote host closed the connection]
cphealy has quit [Read error: Connection reset by peer]
cphealy has joined #dri-devel
tagr has joined #dri-devel
haagch has joined #dri-devel
<eric_engestrom>
jenatali: yeah, CI's not very stable lately :/
<eric_engestrom>
I spent 80% of the last week and a half figuring out what's making our runners unstable
<eric_engestrom>
I'm guessing others are also working on theirs
<eric_engestrom>
but overall I get the feeling it's been getting worse :(
<jenatali>
Yeah, if each runner has a roll of the dice for a flake, once you have multiple issues that can all happen, you end up with re-runs that hit other flakes, and it's just a mess
haagch has quit []
haagch has joined #dri-devel
heat_ has quit []
heat has joined #dri-devel
haagch has quit []
haagch has joined #dri-devel
<DavidHeidelberg[m]>
yeah :(
<DavidHeidelberg[m]>
btw. if you see some traces flaking, just throw it at me asap, I'll try always quickly fix it
<DavidHeidelberg[m]>
eric_engestrom: btw. about change to python docs; do we let others vote how they want to approach versioning? (since we both sent MRs)
<eric_engestrom>
DavidHeidelberg[m]: thanks, I'll try to remember for the traces
<eric_engestrom>
for the python MR, I think your MR should land now as it's obviously correct
<DavidHeidelberg[m]>
kk, I'll push it for start
<eric_engestrom>
my MR is more about having a documented logic for what we'll do going forward
<eric_engestrom>
oh, I just realized maybe I didn't answer your question: yes: I think people should "vote" on whether that logic seems reasonable (from both dev & packager sides)
<eric_engestrom>
today that means python 3.7 is the minimum supported
haagch has quit [Quit: No Ping reply in 180 seconds.]
<DavidHeidelberg[m]>
btw. I agree with you. 3.7 is reasonable compromise. Anyway, I completly love the type checking and stuff from 3.9 & 3.10.. but :D
haagch has joined #dri-devel
h0tc0d3 has quit [Quit: Leaving]
dcz_ has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
did anyone tried to get clang + 32-bit compiled? I see we accumulating 32-bit warnings and fails, but our jobs won't catching them
gouchi has quit [Remote host closed the connection]
Lynne has quit [Quit: Lynne]
ybogdano has quit [Ping timeout: 480 seconds]
Lynne has joined #dri-devel
ds` has quit [Quit: ...]
ds` has joined #dri-devel
ybogdano has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
ahajda_ has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<anholt_>
tomeu: I grep for NEW in the irc logs for unknown flakes.
ybogdano has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
Kayden has joined #dri-devel
ybogdano has joined #dri-devel
<pzanoni>
jekstrand: are you aware of any application or test that is absolutely going to 100% fail if we don't get implicit tracking right?
OftenTimeConsuming has joined #dri-devel
<karolherbst>
airlied: soo.. I have the issue with radeonsi that a grid having 1024 threads doesn't really work :/ so the first grid executes sucessfully, but the second is just doing nonesense
<karolherbst>
so [512, 1, 1] x [8, 1, 1] works, [1024, 1, 1] x [4, 1, 1] doesn't
<karolherbst>
the first 1024 threads work fine though... dunno what's up
<jekstrand>
pzanoni: Nope! Some will maybe fail a bit. I guess it depends on how much you get it wrong.
<pzanoni>
jekstrand: if you have an idea on how I could write a small gl or vk app that's going to fail an assert() if we get implicit tracking wrong, please feel free to tell me, I'll absolutely write it
<pzanoni>
jekstrand: I already have an egl app that does all the fd exporting and passing around through unix sockets and stuff, I'm thinking on how to repurpose it to this