rgallaispou1 has quit [Read error: Connection reset by peer]
<wvanhauwaert>
hi, I want to sure that on my imx53 (adreno/a2xx), no color correction is done at all. Anyone can point me in a direction where or what to alter?
technopoirot has joined #dri-devel
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
mszyprow has joined #dri-devel
kts has quit []
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
ella-0 has joined #dri-devel
kts has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
ella-0_ has quit [Remote host closed the connection]
nchery has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
devilhorns has quit []
JoniSt has joined #dri-devel
<jenatali>
karolherbst: I skimmed and it looks good, I'll give you a proper r-b in a bit
wvanhauwaert has quit [Remote host closed the connection]
technopoirot has joined #dri-devel
sergi has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
<JoniSt>
Man, TC is making my head spin...
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
<zmike>
the buffer tracking code is a bit of a mind-melter until you find your zen
<zmike>
I think this may need a mareko intervention
<zmike>
or at least I don't have the bandwidth to consider it further on a friday
<JoniSt>
Yeah, we might really need mareko to look over this. Though, as far as I can tell, the problem is "just" that multiple TCs can't properly tell each other that their buffers are busy / bound somewhere? I don't see a way to actually make this tracking work cross-context (since one TC can't possibly know how many other TCs there are)...
<zmike>
yes, that's exactly the problem
<zmike>
the buffer tracking is tc-local, so multi-context inherently breaks it
<JoniSt>
Marking buffers as "this is shared, disable all optimizations that don't work cross-context" does actually sound like a proper fix for me
<JoniSt>
TC will just stop tracking such buffers in a thread-local way
<zmike>
well I'm not sure that's exactly what we want either since not all multi-context usage triggers this sort of behavior
<karolherbst>
jenatali: cool thanks
<JoniSt>
Well, all multi-context usage that updates buffers once they're shared will trigger this behavior, so I think it's fair to disable non-thread-safe buffer update optimizations for them
<JoniSt>
Buffers that are only read once they're shared don't trigger it and also won't miss out on those optimizations (and with the "remember which TC created it" strategy, only those buffers that are actually shared will be affected)
<zmike>
yeah that could be
<zmike>
but then that disabling would have to occur before the buffer is initially bound
tursulin has quit [Ping timeout: 480 seconds]
<zmike>
so probably it would have to go something like having an entrypoint on descriptor binds which checks a tc bool for multi-context -> if false, do atomic read of num_contexts to set this bool -> if true, permanently disable buffer tracking for the lifetime of the app
<JoniSt>
Hmm, I'm not sure about that... As long as a buffer belongs to only one TC, that TC can do whatever it wants with it - update it unsynchronized, replace its storage, etc.
<zmike>
that's true, but there's no way to detect the problem case
<zmike>
once a buffer is bound and storage-replaced in a multi-context scenario then tracking is permanently broken for that buffer until another buffer is bound to that same location
<zmike>
and the context where it is bound can't know about a different context replacement until it's too late
<JoniSt>
Ah, that's exactly the place where I want to fix it! As soon as a second TC touches a buffer, tracking gets permanently disabled for that buffer
<zmike>
but it's already broken
<zmike>
so it's too late
<JoniSt>
Why is it? Doesn't the second context see threaded_resource.latest when the buffer initially gets shared? Everything should still be consistent there as long as no further replacements happen
<zmike>
this is the exact scenario I posted in the ticket
<zmike>
the buffer tracking is broken on tc X
<JoniSt>
No no, context Y can't actually replace the buffer with my suggested fix
<zmike>
oh I see, so you're proposing to cut it off before that point
<zmike>
and only allow X to perform replacements
<zmike>
hm
<JoniSt>
Y will see that "oh no I've been given a shared buffer" and immediately mark that buffer as "here be dragons"
<JoniSt>
X will also not be able to perform replacements anymore
<JoniSt>
Replacements (and unsync updates) will be permanently disabled for the shared buffer on all contexts as soon as it gets shared
<JoniSt>
It'll work like this: X creates the buffer and sets "threaded_resource.owning_tc=X", or something. Y will see that threaded_resource.owning_tc!=Y, so shenanigans are happening. It then sets threaded_resource.is_shared=true. is_buffer_busy will always return true for such buffers and replacements are forbidden if that flag is set. No TC is ever going to replace that buffer again.
<zmike>
let the drivers determine whether they can handle unsynchronized mapping
<JoniSt>
Unsynchronized maybe, but replace will still be broken
<zmike>
that's still a separate issue
<JoniSt>
Though, until a TC flushes a batch using a certain buffer, another TC can still ask the driver and get "not busy" back even if the first TC is currently using it... So this does actually require disabling the busy tracking in TC for those buffers
lynxeye has joined #dri-devel
<karolherbst>
uhhhh... spirv-tools totally broke building shared libraries :(
nchery has quit [Ping timeout: 480 seconds]
stuart has joined #dri-devel
wv has quit []
<karolherbst>
ahh no, need to define BUILD_SHARED_LIBS ...
<karolherbst>
build systems....
wvanhauwaert has joined #dri-devel
off^ has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<MrCooper>
karolherbst: especially since one generally doesn't want BUILD_SHARED_LIBS in llvm-project... doesn't spirv-tools have something like *_BUILD_*_DYLIB?
<karolherbst>
they have
nchery has joined #dri-devel
<karolherbst>
ohh wait.. I think there is just SHARED_LIBS actually
<karolherbst>
but I thought SPIRV_TOOLS_BUILD_STATIC=OFF is doing the trick, because it's the only "documented" option in their build system
<karolherbst>
BUILD_SHARED_LIBS doesn't even appear in ccmake
<karolherbst>
although I think BUILD_SHARED_LIBS is a global cmake thing?
<karolherbst>
MrCooper: also.. it's not an LLVM project
<zmike>
Kayden: do you happen to recall where in the gl spec you saw the part about thread synchronization occurring on bind?
<zmike>
I'm trying to find it but my ctrl+f is not yielding results
<zmike>
JoniSt: why don't you do a run at this idea you have and add it to !16993
<zmike>
I think this is going to need more deliberation
<JoniSt>
zmike: Already on it!
<zmike>
great, thanks
<JoniSt>
Though I think this should probably be a new MR since it's a completely different approach from what has already been reviewed in 16993
<zmike>
up to you, I'm getting ready to clock out for the week
<JoniSt>
I'll need a while anyway, no worries - gotta get familiar with piglit etc, I'm still a total newbie here
<zmike>
glad to have you aboard 👍
<JoniSt>
Thanks! :)
bkrause has left #dri-devel [#dri-devel]
off^ has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
dviola has joined #dri-devel
mbrost has joined #dri-devel
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
dviola has quit [Quit: WeeChat 3.5]
jimjams has joined #dri-devel
nchery has joined #dri-devel
lemonzest has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
luc4 has joined #dri-devel
<luc4>
Hello! Is this the proper place to ask questions about KMS DRM?
technopoirot has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
ybogdano has joined #dri-devel
Putti[l]_ has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
technopoirot has joined #dri-devel
Putti has quit [Ping timeout: 480 seconds]
lemonzest1 has joined #dri-devel
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
lemonzest has quit [Ping timeout: 480 seconds]
maxzor__ has quit [Ping timeout: 480 seconds]
<karolherbst>
luc4: sure is
dviola has quit [Quit: WeeChat 3.5]
maxzor__ has joined #dri-devel
dviola has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
nchery is now known as Guest3951
nchery has joined #dri-devel
maxzor__ has quit [Ping timeout: 480 seconds]
Guest3951 has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<luc4>
karolherbst: thanks
Duke`` has joined #dri-devel
<luc4>
Is it possible to call drmModeSetPlane() from multiple threads concurrently? I'm receiving the error "No space left on device", but I'm not sure what that means in this context. Any idea?
mszyprow has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
<karolherbst>
luc4: looking at the code, the answer seems to be yes. "No space left on device" usually means the IOCTL returned -ENOSPC
<karolherbst>
maybe its out of bound?
<karolherbst>
check out the DRM_IOCTL_MODE_SETPLANE ioctl
<luc4>
karolherbst: sorry, what do you mean by "out of bound"?
<luc4>
karolherbst: do you mean "geometrically", in terms of coordinates?
<karolherbst>
yes
<karolherbst>
if it's memory we usually return ENOMEM
<luc4>
karolherbst: oh, I did not think about that, I'll have to check, thanks!
<karolherbst>
could be something else though, but it's something inside the kernel doing it, so worst case if the documentation doesn't give any hints, might be a good idea to try to debug it on the kernel side. But arguments out of bounds would be my best bet here
<luc4>
karolherbst: I'll check but I doubt that. Setup is 1080p, and I write a 720p frame in (0, 0). But I'll check to be sure.
<karolherbst>
yeah... hard to say what's happening from remote
<luc4>
karolherbst: I perfectly understand
<karolherbst>
some expert on the KMS idea might be able to help if given more details
<karolherbst>
there are also some drm debugging flags to enable more debugging in dmesg, but I never know what to enable
digetx has quit [Ping timeout: 480 seconds]
lemonzest1 has quit [Ping timeout: 480 seconds]
<luc4>
karolherbst: this is the first time I'm using drm. What I did was simply starting from this simple example https://github.com/BayLibre/ffmpeg-drm/blob/master/main.c. I took the same concept and "duplicated" it on two different threads. One writes on one plane, and the other writes on another. I shared the same fd for both threads, seemed more reasonable. I'm probably doing this all wrong, but I couldn't find a simple example
<luc4>
using multiple planes so I'm trying by myself.
<karolherbst>
yeah.. can't really comment on the threading bits. It could be that the kernel races on stuff, but I think if you have a simple reproducer which makes inherently sense, might be easier to comment on for others
digetx has joined #dri-devel
<luc4>
karolherbst: thank you for your time anyway!
<luc4>
karolherbst: just to be sure about this, can you confirm it is impossible to have two different processes concurrently writing on different planes?
<karolherbst>
no clue
<vsyrjala>
only one process can control kms at a time
toolchains has quit [Ping timeout: 480 seconds]
<luc4>
vsyrjala: thank you for the confirmation!
<JoniSt>
Hmm... How do you summon a mareko? :P (Regarding MR 17338, which is my second attempt at fixing multi-context buffer busy tracking in TC)
maxzor_ has quit [Ping timeout: 480 seconds]
<robclark>
JoniSt: /cc @mareko
<JoniSt>
Ah right, duh! Thanks! :P
<bbrezillon>
jekstrand: FWIW, the util_sign_extend(val & mask) in nir_serialize.c could/should be converted to util_mask_sign_extend()
<bbrezillon>
don't know if you plan to do that after merging !17214
lemonzest1 has joined #dri-devel
<JoniSt>
robclark: Good question with the buffer multithreading... Afaik the rule is just "don't use the same GL object from multiple threads concurrently" but I'll try to look it up
<JoniSt>
That'd mean one thread has to unmap the buffer first before another one maps it (or parts of it, even non-overlapping ones) but I'm not quite sure if I remember this correctly
<JoniSt>
Oh actually I found a rule that forbids this
<robclark>
yeah, I know gallium api better than gl so wasn't quite sure..
<jekstrand>
bbrezillon: Done. I threw it on top before Marge picks it up. I threw your RB on it speculatively. Want to give it a quick look just to be sure?
<JoniSt>
GL is a mess... But hey, maybe this MR will fix some of the weird zink flakes that mike has been experiencing :)
lemonzest1 has quit [Ping timeout: 480 seconds]
<zmike>
no, those are almost exclusively caused by ci using old libX11 and some glx problems in drisw
<JoniSt>
Ah I see!
<JoniSt>
The zink fail is fixed with the new version of the multi-context MR by the way :)
<zmike>
\o/
<zmike>
I'll plan to look at it first thing monday
<zmike>
or tuesday?
<zmike>
I don't remember which day I'm back in the office
<JoniSt>
Alright, no stress :)
<JoniSt>
I'm just happy that I found a solution that actually fixes this properly
Putti[l]_ has quit []
lynxeye has quit [Quit: Leaving.]
lemonzest1 has joined #dri-devel
<bbrezillon>
jekstrand: yep, LGTM
lemonzest1 has quit [Ping timeout: 480 seconds]
<Kayden>
zmike: OpenGL 4.6 Section 5.3 Propagating Changes to Objects
<Kayden>
zmike: has the rules for objects being accessed by multiple contexts at the same time
<JoniSt>
Kayden: Thanks! :)
<Kayden>
it's unfortunately very obtuse to read :(
<Kayden>
got the whole client/server thing from the idea of indirect GLX where the app actually talks GL protocol at a GL server that actually has a driver
<Kayden>
and I also get the sense that just nothing works like it says
<Kayden>
it might obey the rules but it's nothing like the implementation
lemonzest1 has joined #dri-devel
<JoniSt>
Apps also just don't rebind their stuff for inter-context synchronization... So Mesa has to detect this itself in TC
<ajax>
it's actually a good model to internalize, i think?
<ajax>
because the whole point of the c/s split in glx is to allow the implementation more room to do things asynchronously
<ajax>
slash in parallel
<JoniSt>
Yeah, just like TC does. But once there are multiple servers (contexts), stuff gets very ugly
<ajax>
which tc+egl kind of gives you, because you just marshall off the commands and maybe they work
<ajax>
so you solve it for the one-context case because you already have to, and then the multi-ctx case falls out naturally
<JoniSt>
"Maybe they work" :D
<ajax>
whole reason anything in graphics is performant tbh
<ajax>
if glVertex3f was synchronous you'd dispatch maybe 10k vertices a second?
<JoniSt>
Well, ideally the application would set up a bunch of data structures and submit all of its work with a single call :P
<JoniSt>
Like you can (and should) already do with Vulkan
<JoniSt>
But having to pretend everything is synchronous while also making stuff hard of course makes things a lot more complicated and fragile
<JoniSt>
*while also making stuff fast
MajorBiscuit has joined #dri-devel
mvlad has quit [Remote host closed the connection]
lemonzest1 has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.5]
slattann1 has quit [Ping timeout: 480 seconds]
zehortigoza has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
lemonzest1 has joined #dri-devel
<JoniSt>
Well, there was my first "Push a commit and watch the entire pipeline turn red" moment
lemonzest1 has quit [Ping timeout: 480 seconds]
chaim has quit [Quit: Konversation terminated!]
jfalempe has quit [Quit: Leaving]
maxzor__ has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
nchery has quit [Quit: Leaving]
lemonzest1 has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
lemonzest1 has quit []
<jenatali>
Sigh looks like this merge is going to time out because an a630 runner got hung and I didn't notice until it was too late to restart it
<jenatali>
After I also restarted a radeonsi job that flaked
<jenatali>
Oh cool but nobody else was trying to merge so I could just reassign it and let the job finish woo
wv has joined #dri-devel
wvanhauwaert has quit [Ping timeout: 480 seconds]
OftenTimeConsuming is now known as Guest3971
pcercuei has quit [Read error: Connection reset by peer]
OftenTimeConsuming has joined #dri-devel
pcercuei has joined #dri-devel
Guest3971 has quit [Remote host closed the connection]
OftenTimeConsuming has quit [Remote host closed the connection]