<sima>
that repo seems a bit defunct, so wondered whether we need it when drm-misc has moved to gitlab
Daanct12 has joined #dri-devel
airlied_ has joined #dri-devel
airlied has quit [Read error: Connection reset by peer]
Haaninjo has quit [Quit: Ex-Chat]
itoral_ has joined #dri-devel
hansg has quit [Remote host closed the connection]
bmodem has joined #dri-devel
hansg has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #dri-devel
itoral has joined #dri-devel
itoral_ has quit [Ping timeout: 480 seconds]
itoral_ has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
<sima>
tzimmermann, entirely aside and I didn't check, but re your dma_resv locking work: we must ensure that dma_resv_lock in atomic_commit code is _only_ called after commit_hw_done() has been called
<sima>
otherwise we might deadlock with the next commit since that one can wait for the previous to finish while holding the dma_resv lock
<sima>
(through the absolute maze that is called dma_fence)
<sima>
tzimmermann, which means you cannot take dma_resv_lock in end_fb_access
<sima>
(we might be getting this wrong already, in which case I'm going to put on the thousand yard stare and scream silently)
kts has joined #dri-devel
apinheiro has joined #dri-devel
dorcaslitunyaVM has joined #dri-devel
itoral__ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
itoral_ has quit [Ping timeout: 480 seconds]
CounterPillow_ has joined #dri-devel
CounterPillow has quit [Ping timeout: 480 seconds]
<sima>
jfalempe, do you have a link to the discussion for the new drm_panic_set_buffer design?
<sima>
jfalempe, asking because I liked that part of v7 a lot more, so kinda wondering what I'm missing
<dj-death>
anybody undersand why nir_opt_loop_unroll cannot easily unroll consecutive loops in the same block?
<dj-death>
I thought maybe starting from the bottom of the block and going up would do it
<dj-death>
but probably missing something...
<tzimmermann>
sima, the rework pushes the pin/unpin resv lock from callbacks outside into drm_gem_pin(), but the order of calls does not change. the issue with end_fb_access should not happen
<tzimmermann>
the changes to fbdev code are unrelated to end_fb_access
<dj-death>
danylo: looks like you might know ;)
<tzimmermann>
sima, there's no pin in end_fb_access, only vmap. vmap has already been fixed to not take the resv lock
<danylo>
dj-death No way I know anything about it =) I have a few commits there but that was long ago...
<sima>
tzimmermann, ah great
itoral__ has quit [Remote host closed the connection]
itoral__ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<dj-death>
danylo: yeah 4 years it looks like :)
CounterPillow_ is now known as CounterPillow
<sima>
jfalempe, apologies that I entirely dropped the ball (at least I couldn't find the patch I've thought I've written), here's what I had in mind to fix the locking for your v7 design https://paste.debian.net/hidden/0ee26837/
<sima>
imo that's more robust than requiring explicit set_buffer calls sprinkled over drivers, but I want to understand the reasons for that design in v8 first
<jfalempe>
but I'm fine with both design, the main issue with the set_buffer() approach is that it requires a call for each buffer flip, and for some driver, it's a bit complex to make sure the buffer set is always valid.
<tzimmermann>
sima, IIRC there was this problem of going over atomic state and trying to figure out if it has a valid framebuffer and where. so my suggestion was to tell the panic handler when/where a framebuffer is avaialble
<sima>
tzimmermann, yeah, and silly me forgot to actually type up the patch since I think I've figured out how to do it
<sima>
but essentially even ttm based drivers I think can just access the relevant structures in panic context, as long as the trylock succeeds
<sima>
it means it's not perfectly synchronized to hw state when racing against a modeset, but I think that's ok and worth the simplification we get
<sima>
also this design would allow drivers to protect the scanout registers mmio writes with the raw spinlock and then maybe access vram with peek/poke registers (also protected by the panic lock)
<sima>
and we'd actually be perfectly in sync with hw state
<sima>
if people feel like that's worth it
<sima>
but it does assume the get_scanout_buffer callback form v7
<jfalempe>
sima: thanks for this patches, I don't know enough the drm internal to write this on my own.
<jfalempe>
I will work on a v9, with going back to the get_scanou_buffer from v7
<sima>
jfalempe, maybe hold a bit before we reach consensus :-)
<sima>
also I think if we do have a driver where the set_buffer approach is best, we could still add that
<sima>
and I just realized that the window of new sw state, but not yet in hw shouldn't be that big
<sima>
the big hold-up is if the atomic needs to wait for fences
<sima>
and if those are not signalled yet, then we have excellent chances that the gpu is still rendering, so probably going to overwrite our panic stuff still
<sima>
since the gpu doesn't die with the cpu/kernel on panic
<sima>
also I have meetings now and then I'm off for dinner in zürich, but I'll check scrollback for more discussions tomorrow
<sima>
since I'm not sure what I typed up in the kerneldoc is actually correct :-)
dogukan has joined #dri-devel
<jfalempe>
sima: in the panic handler, we can wait a bit if the gpu is still rendering, but by doing active polling, not by sleeping.
<sima>
uh polling sounds dangerous
<sima>
also I think I got it the wrong way round, since in this case the buffer that's shown is not the one being rendered to
<dogukan>
libdrm states that GEM handles are unique to DRM file descriptions and they should be reference counted in user space. So, what is the expected behavior after a fork? We would have two processes that have an fd to the same DRM file description, with different address spaces.
<dogukan>
Or is forking even allowed in this case? I see that struct drm_file keeps a tid to the process owning the file. In this case, we would have two processes having access to the same drm_file.
<pq>
dogukan, you can fork, and both processes then have the same open DRM device file, and they will screw up that reference counting.
<pq>
AFAIK the same happens if you send DRM device fd to another process via IPC, too. Just don't do it.
<pq>
As a rule of thumb, always set CLOEXEC and exec immediately after fork in the child process.
kts has joined #dri-devel
kts has quit []
danylo has quit [Quit: Ping timeout (120 seconds)]
melonai5 has quit []
danylo has joined #dri-devel
melonai5 has joined #dri-devel
kts has joined #dri-devel
psykose has quit [Read error: No route to host]
sknebel has quit [Remote host closed the connection]
psykose has joined #dri-devel
shoragan has quit [Quit: quit]
shoragan has joined #dri-devel
sknebel has joined #dri-devel
<DavidHeidelberg>
eric_engestrom: Heya, what would think about publishing also sha512 for new releases?
macromorgan_ has joined #dri-devel
macromorgan has quit [Ping timeout: 480 seconds]
guludo has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
<eric_engestrom>
DavidHeidelberg: I don't see the point, but I also have no objection
<eric_engestrom>
the release email already has that, so I assume you're talking about the release note for the website?
rasterman has quit [Quit: Gettin' stinky!]
<eric_engestrom>
honnestly, I'm not sure I see the point in copying the checksum into the release notes at all, especially since the tarball link is not even there
<eric_engestrom>
I would be in favour of dropping the checksum from the relnotes
<eric_engestrom>
or adding the tarball link (and then we can generalize "SHA256 checksum" into eg. "Tarball checksum" and have put everything from the xorg release script in there)
<mattst88>
emersion: tl;dr instructions for making a pixman release these days?
<daniels>
not that I see anything about pixman there, but
<emersion>
pixman never used that script
<emersion>
it had a custom script baked into autotools before
<sima>
pq, you can send around the fd, but really only before you've done anything with it
<sima>
or at least only one process is allowed to allocated buffers
<sima>
like logind keeping drmfd around so it can force the vt switch if the compositor doesn't cooperate
<DemiMarie>
sima: will Linux be able to produce a BSOD like Windows can?
<daniels>
emersion: ah, sorry for the noise
<jfalempe>
DemiMarie: I'm working on it, see the drm_panic commits on dri-devel
<pq>
sima, are you saying that is it ok to share the fd first, and then *both* processes can start creating and destroying GEM handles to dmabufs shared between each other? :-)
<DemiMarie>
jfalempe: nice!
<pq>
I think the safe path on sharing DRM device fds is so narrow that I'd just say "don't do it".
<sima>
pq, yeah maybe not that :-)
<sima>
pq, well both dri2 and logind massively share them by design, but yeah it's very narrow indeed
<sima>
gtg head out for dinner in zürich now, ttyal
guludo has joined #dri-devel
flto has joined #dri-devel
<mattst88>
daniels: yeah, would be nice if it used that script. I've used that script 100 times :)
<eric_engestrom>
bl4ckb0ne: feel free to comment in !10364 :)
<bl4ckb0ne>
will do, thanks
<eric_engestrom>
fwiw, both amd and nouveau are trying to merge the driver-specific parts of libdrm back into mesa and drop the dependency on libdrm_${driver}
<bl4ckb0ne>
yeah ive been loosely following that
<eric_engestrom>
you could probably convince intel to do the same
<bl4ckb0ne>
in wlroots we just have the "fallback" field set and users clone their own repo, its very convinient
<eric_engestrom>
especially since I think only i965g still uses libdrm_intel, all the other intel drivers use the mesa code for this
<eric_engestrom>
so likely most of it is already there for i965g too
<eric_engestrom>
*i915g
<bl4ckb0ne>
should I bother submit a patch for the `fallback` field or just leave it uncommited and hope for a change in the future
<bl4ckb0ne>
beside a few missing deps not caught by meson, I got latest mesa git built on bookworm
kts has joined #dri-devel
Haaninjo has joined #dri-devel
kts has quit [Remote host closed the connection]
Kayden has quit [Quit: -> JF]
frieder has quit [Remote host closed the connection]
cmichael has quit [Quit: Leaving]
bolson has quit [Ping timeout: 480 seconds]
checkfoc_us has quit []
Duke`` has quit [Ping timeout: 480 seconds]
checkfoc_us has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
flom84 has joined #dri-devel
<jcnrot>
I had fifty line java trace when my father moved to shitland with me. I looked at this trace as open source big gun, and said wau watta trace. Now i am inspecting traces every day, today for an example there was a trace of poop when i left, i was inspecting it close to get a real feeling, nose was entirely in da shit.. I gotta say wau about that trace , only thing that is totally fair to say is just wau. MWK makes poopy fartix type of activity and
<jcnrot>
karolherbst sniffs very close, NOT a single aroma is skipped. Karol is sucha grand fartsniffer imho. what a hero.
pcercuei has quit [Quit: dodo]
<jcnrot>
Scala is much unmaintained, matrix has only support page, and i do not get it how to call those iterators , biggest issue is even when they really turn out to iterate over the divisor and modulo, then i would not, know how to call the division and modulo and respective multiplication without iterator
<jcnrot>
such as unrolled access routines
flom84 has quit [Quit: Leaving]
zhiwang1 has joined #dri-devel
<jcnrot>
they access something by taking a divisor and ANDing modulo of that element and that should return the element, but without iterator i have no clue how that would work
<DemiMarie>
can someone kick them?
macromorgan has joined #dri-devel
<jcnrot>
Technically it should be possible with some checkpointing kit or debugger, cause division is repeated subtraction and multiplication is repeated addition, so you would want to checkpoint how many times to add or remove to access certain elements.
jcnrot was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
warpme has joined #dri-devel
Kayden has joined #dri-devel
macromorgan has quit [Quit: Leaving]
macromorgan has joined #dri-devel
<jenatali>
Ugh. I'm getting some bad loop unrolling behavior. `for (int i = 1; i <= limit; ++i) { arr[i] = foo; }` is giving me out-of-bounds accesses to `arr`
odrling has quit [Remote host closed the connection]
bolson has joined #dri-devel
odrling has joined #dri-devel
warpme has quit []
<jenatali>
Loop analysis sees the induction variable is used to access the array, but misses the fact that it starts at 1, so it sets the loop iteration count to the size of the array, when it needs to be -1
macromorgan_ has joined #dri-devel
<jenatali>
Any nir experts around? Or anyone familiar with loop analysis?
macromorgan has quit [Ping timeout: 480 seconds]
<cheako>
I always brute-force off by one issues, try `i < limit`.
<jenatali>
It's not my shader, it's part of Geekbench
guludo has quit [Quit: WeeChat 4.2.1]
<cheako>
What's `limit` as compared to how many indexes `arr` has?
<jenatali>
limit is an unknown variable. Loop analysis isn't figuring out how many iterations using it
macromorgan_ has quit []
<cheako>
I assume C style semantics, https://onlinegdb.com/hh1N3xoKZ A value `size-1` for limit as in `5 - 1 = 4`would be correct. Yeah, if limit is coming from elsewhere it must be validated somewhere hopefully external to the shader.
<cheako>
If you set `limit = 5`, then the stack smashing detector is triggered.
<jenatali>
Ok it's actually taking the `i = 1` initial condition into account, it's just that the terminating condition of `i <= limit` is tripping it up. Since the loop's *actual* limit is an inclusive limit, but we're guessing an upper bound based on array accesses, which is an exclusive limit
<alyssa>
jenatali: not the first time <= conditions confuse loop analysis :~(
<jenatali>
Yeah...
macromorgan has joined #dri-devel
<jani>
PSA: dim now supports applying patches using b4 with the new b4-shazam and b4-shazam-branch subcommands. please try them out and report about any hiccups.
dogukan has quit [Remote host closed the connection]
dviola has quit [Quit: WeeChat 4.2.1]
dviola has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
u-amarsh04 has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
Leopold___ has quit [Read error: Connection reset by peer]
Leopold_ has joined #dri-devel
Leopold_ has quit []
Leopold_ has joined #dri-devel
<jenatali>
Yeah the array out-of-bounds logic in nir_opt_loop_unroll is busted too. It assumes that the induction var's value is going to be == the trip count, which is wrong for loops starting at nonzero values or not incrementing
<jenatali>
Fun
JohnnyonFlame has joined #dri-devel
CounterPillow has quit [Read error: Connection reset by peer]
CounterPillow has joined #dri-devel
<alyssa>
womp
macromorgan_ has joined #dri-devel
macromorgan_ has quit [Read error: Connection reset by peer]
macromorgan has quit [Ping timeout: 480 seconds]
macromorgan has joined #dri-devel
<cambrian_invader>
should drm_bridges have internal locking e.g. between the HPD IRQ and atomic_enable?
<cambrian_invader>
I notice that e.g. msm does this
glennk has quit [Ping timeout: 480 seconds]
zhiwang1 has quit [Quit: Connection closed for inactivity]
gfxstrand has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
mvlad has quit [Remote host closed the connection]