<HdkR>
static constructors and destructors are a battle I fight far too often, and I'm the one adding them. gaah
phasta has joined #dri-devel
rgallaispou has joined #dri-devel
jsa2 has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest6066
dsimic has joined #dri-devel
Guest6066 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
lynxeye has joined #dri-devel
mehdi-djait3397165695212282475 has joined #dri-devel
LeviYun has joined #dri-devel
apinheiro has joined #dri-devel
mehdi-djait3397165695212282475 has quit [Ping timeout: 480 seconds]
DodoGTA has left #dri-devel [#dri-devel]
sukuna has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
tango_ has joined #dri-devel
u-amarsh04 has joined #dri-devel
LeviYun has joined #dri-devel
mwalle has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
DodoGTA has joined #dri-devel
V has quit [Remote host closed the connection]
V has joined #dri-devel
haaninjo has joined #dri-devel
phasta_ has joined #dri-devel
fomys has joined #dri-devel
u-amarsh04 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
phasta__ has joined #dri-devel
phasta has quit [Read error: Connection reset by peer]
phasta__ has quit []
phasta_ has quit [Ping timeout: 480 seconds]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
phasta has joined #dri-devel
pcercuei has joined #dri-devel
kaiwenjon has quit [Quit: WeeChat 3.8]
amarsh04 has joined #dri-devel
<emersion>
pq, i've started reviewing the drm_colorop stuff
kaiwenjon has joined #dri-devel
<emersion>
i don't know HDR well, so let me know if you've been reading the replies and i missed anything
<sima>
mripard, dropped some replies
<soreau>
MrCooper: what spec are you reading? the usual user-facing docs don't mention it for glReadPixels AFAICT
kaiwenjon has quit [Quit: WeeChat 3.8]
<MrCooper>
the GL spec
<MrCooper>
I mean, if it wasn't the case, every non-PBO glReadPixels caller without preceding glFinish would be broken, that's pretty much every one I've seen
<mripard>
sima: awesome, thanks
kaiwenjon has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
kaiwenjon has quit [Quit: WeeChat 3.8]
amarsh04 has quit []
<soreau>
MrCooper: idk, skimming the 4.6 spec around ReadPixels doesn't seem to say anything explicit either (not disagreeing with you that drivers don't sync, just that it's not well documented, if at all)
feaneron has joined #dri-devel
kts has joined #dri-devel
dviola has joined #dri-devel
kaiwenjon has joined #dri-devel
amarsh04 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
tango_ has quit [Ping timeout: 480 seconds]
Hazematman has quit [Quit: WeeChat 4.5.1]
amarsh04 has quit []
Hazematman has joined #dri-devel
Hazematman has quit []
Hazematman has joined #dri-devel
Hazematman has quit []
Hazematman has joined #dri-devel
Hazematman has quit []
Hazematman has joined #dri-devel
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<phasta>
I just saw that discussion with DRM maintainers and Greg about cherry picking fixes commits
<phasta>
Soooooo. I don't have expertise on this. Why are we doing that in DRM?
<phasta>
When fixing sth, why can't we just send it to Linus with Cc stable and Fixes: and Greg will do the backporting?
<mripard>
because, sometimes, we get it wrong
<mripard>
and a patch that was initially merged in -next turned out to be needed in -fixes
Hazematman has quit [Quit: WeeChat 4.5.1]
<phasta>
Hmm. But that must be a general problem in the kernel, no? Isn't there a process for that?
<mripard>
most of the other maintainers rebase their trees
<mripard>
so in such a case, they would drop it from their next branch, and apply it again as a fix
<phasta>
Ah alright. And we're too big for that
<mripard>
we have so many people committing on the trees that rebasing the trees isn't something we can do, really
Hazematman has joined #dri-devel
<sima>
phasta, not so much too big, but we have committers and you can't rebase branches when more than 2-3 people touch it
Hazematman has quit []
<sima>
phasta, the other part is also that developers just want to push their work to the main branch, and figuring out where a bugfix needs to go is sometimes tricky
Hazematman has joined #dri-devel
<phasta>
I assume it has been discussed in the past to make DRM More hierarchical, with many independent subbranches that actively get merged into drm-xy-zz?
<sima>
so for the drm-intel tree with paid maintainers, we cherry-pick _all_ bugfixes
<sima>
because that's easier for committers
Hazematman has quit []
<sima>
phasta, it's a pile of paperwork to make that happen, and like any other subsystem we lack volunteers
<mripard>
phasta: that was pretty much how early drm-misc looked like
<sima>
so instead of trying to pull of the impossible, we've adjusted the process to not be so much busy work for maintainers
<sima>
there's also all the cross-branch coordination pain you have with lots of tiny branches
<phasta>
will read – still, that's exactly what Linus is doing, just at smaller scale
Hazematman has joined #dri-devel
Hazematman has quit []
<sima>
phasta, what do you mean with that here?
Hazematman has joined #dri-devel
<phasta>
sima, Linus has subsystems below him, and those subsystems often have dedicated driver maintainers with their own branches. So it's the same model, many branches, and they all merge at Linus, with merge conflicts and all those problems
<sima>
phasta, yeah eventually a single tree gets too messy and different trees make sense. we still have some within drm, just a lot less
<javierm>
phasta: there's also the fact that cross-kernel changes are less common I would say that cross-subsystem changes
<sima>
or at least they're happening more gradually/slower
<sima>
within a subsystem it's just nice when you can just land a refactor in one go and done
<javierm>
phasta: when those occur, the inter trees coordination is painful. Need topic branches and so on
<sima>
but if you touch too many trees that becomes impossible, and you need to do it in stages: 1 land new uapi 2 push refactoring into all separate trees 3. wait for a full release for everything to converge 4. delete old uapi
rz has quit [Ping timeout: 480 seconds]
<javierm>
sima: yeah, or as mentioned ask for topic branches that can be merged in all the other trees but that's painful to coordinate
<phasta>
Yes, touching APIs across the kernel is also painful
<sima>
javierm, topic branches only work for smaller stuff, ime they have limits
<javierm>
sima: yeah, agreed
<sima>
like adding the new uapi can be done with topic branch often, otherwise you need to already wait a full cycle between 1 and 2
kts_ has quit []
<sima>
and for really big stuff you get to repeat 2/3 a few times because new users of the old uapi keep cropping up
<sima>
it's just a lot of pain all around
<javierm>
sima: yeah, the .i2c_probe_new work from Uwe comes to mind. It took 6 years to replace everything and 606 patches only to remove the old users
<javierm>
a change like that in drm can be done with a single patch and merging it is trivial once you get all the acks
<mlankhorst>
So it seems initially drm_client_modeset_probe correctly detects the tiles and offsets, and in second pass just ignores the offset. :s
apinheiro has quit [Quit: Leaving]
itoral has quit [Remote host closed the connection]
tango_ has quit [Quit: I'm never quite so stupid as when I'm being smart (Linus van Pel)]
heat has joined #dri-devel
lemonesque has quit [Ping timeout: 480 seconds]
amarsh04 has joined #dri-devel
<sima>
mlankhorst, would probably also need some minimal atomic retry to try with fewer crtc, since multi crtc constraints kinda regressed with conversion to atomic
<sima>
or at least I thought you get black screen now if the config with all crtc doesn't work
<sima>
otoh before you got black screeen sometimes due to crtc-by-crtc switching on vt switch
<mlankhorst>
It works, I just run into a detection issue
jsa2 has joined #dri-devel
<mlankhorst>
I have a tiled display on DP-MST, with DP-0.8 and DP-0.9, DP-0.9 is the primary screen, DP-0.8 the secondary
<mlankhorst>
DP-0.8 needs to be set to the offset at 1920, but the offsets are not set correctly when not using the fallback code
vsro has joined #dri-devel
<sima>
mlankhorst, oh I more meant when you have even more displays and run into clock/bw and other sharing issues
<mlankhorst>
Sorry, just a boring 4k tiled display. :-)
<jenatali>
glehmann: yeah seems gst-htz-5-windows-shell is unhealthy
<jenatali>
Pinged in #freedesktop
bolson has joined #dri-devel
fab has quit [Quit: fab]
<jenatali>
glehmann: that runner should be paused now
lemonesque has joined #dri-devel
<glehmann>
thanks
vsro has joined #dri-devel
kzd has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
simon-perretta-img has joined #dri-devel
fab has joined #dri-devel
jsa2 has quit [Ping timeout: 480 seconds]
moxie has quit [Quit: WeeChat 3.8]
moxie has joined #dri-devel
vsro has quit [Remote host closed the connection]
phasta has quit [Quit: Leaving]
<chaos_princess>
hi all. how do dri drivers that have bridges deal with someone unloading the bridge or panel drivers? i seem to be unable to find the right callbacks for "your bridge just got yanked out"
<mripard>
chaos_princess: poorly
<mripard>
chaos_princess: bridge module unloading triggers use-after-free really easily at the moment
<mripard>
(and panels are in the same situation)
<chaos_princess>
i am trying to submit a new driver, and got review feedback to the effect of "what if someone unloads your mipi bridge or panel".
jsa1 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<mripard>
we're working on both at the moment, but we're not yet at the "please be nice and signal when you go away phase", we're at the "please please please don't crash" phase :)
<mripard>
do you have a link to that review?
LeviYun has joined #dri-devel
<chaos_princess>
and, like, ok, technically possible, but 1. why, and 2. i guess you will power down relevant hardware, and when you insmod the driver again, you will get a serror
kaiwenjon has quit [Read error: Connection reset by peer]
kaiwenjon has joined #dri-devel
<jenatali>
alyssa: I like the foundational work for sure. I'm a *little* hesitant on adding global constructors/destructors for registration but happy to defer that discussion to the next MR
tango_ has joined #dri-devel
LeviYun has joined #dri-devel
cgbowman has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
<demarchi>
q66: whose patch is that?
LeviYun has joined #dri-devel
kaiwenjon has quit [Quit: WeeChat 3.8]
oneforall2 has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
kaiwenjon has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
cgbowman has quit [Remote host closed the connection]
cgbowman has joined #dri-devel
nukelet1 has joined #dri-devel
davispuh has joined #dri-devel
kaiwenjon has quit [Quit: WeeChat 3.8]
nukelet is now known as Guest6092
nukelet1 is now known as nukelet
Guest6092 has quit [Ping timeout: 480 seconds]
kaiwenjon has joined #dri-devel
rgallaispou has quit [Quit: Leaving.]
kts has quit [Quit: Leaving]
<pq>
emersion, appreciated. Since drm_colorop all about exposing hardware capability, it doesn't matter much if the operations "make sense". The most important part is that they are unambiguously defined.
mbrost has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has quit []
<rodrigovivi>
sima: airlied: about "drm: Introduce device wedged event"... our user space components don't have daemons to keep listening to the udev events... and udev events seems more for admins creating their own scripts or distros to take some action... so, the question is, should we really require the regular open source upstream consumer to get them in, or could be like sysfs is for admins only in many cases?
<sima>
rodrigovivi, I still think some demo script that shows this can be integrated or used in production would be good, just to show we didn't design unusable uapi
<sima>
doesn't need to be much, I agree with that
<zamundaaa[m]>
rodrigovivi: compositors do use udev events
<sima>
but if we built this and then later on some management middleware thing tries to use it and balks, it's kinda awkward
<rodrigovivi>
yeap, because many different kind of actions could be taken when the device is declared wedged... I didn't want to put a hard rule in the compositor
<sima>
I mean if you get a compositor to use this to drive its fallback to sw rendering or something, that'd be epic
<sima>
for this one I don't think we need quite that much
<sima>
but should be more than a bunch of igt
<rodrigovivi>
hmm.. I like that idea very much indeed...
<demarchi>
rodrigovivi: I think we did that impl basing it on the sysadmin need, but there are other possible uses... example... (?) the integration with userspace drivers ( slide 10 of https://www.youtube.com/watch?v=qpBLju1l9_w @ 5:34)
<sima>
demarchi, userspace driver would probably need a drm_event, not udev event
kaiwenjo1 has joined #dri-devel
<sima>
so yeah if umd needs this itself, it defo needs real userspace since I don't think the uevent works :-)
<zamundaaa[m]>
sima: hmm, that epic example isn't actually that far out
kaiwenjon has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
I just tested it, and with some minor adjustments to clean things up (like the linux-dmabuf Wayland global), it would work fine in KWin
<sima>
zamundaaa[m], dump it into an mr, make rodrigovivi really happy?
<sima>
or directly put an "ack, this works, here's the link to the code" reply onto that patch
<zamundaaa[m]>
will do
kaiwenjo1 has quit []
<demarchi>
zamundaaa[m]: that would be awesome, thanks
lynxeye has quit [Quit: Leaving.]
<alyssa>
jenatali: I mean I don't love it but... I don't really see an alternative
<jenatali>
alyssa: Explicit registration like how it's staged in your current MR?
<jenatali>
I guess, I don't know what the bindgen stuff will look like so I don't know how well that would work, but it seems feasible for each generated file to define an exported register/unregister instead of constructore/destructor
<alyssa>
the problem is, who calls the explicit callers
<alyssa>
s/callers/functions/
<jenatali>
Whoever's responsible for compiler init/deinit?
<jenatali>
I.e. for GL put it in mesa/st and for VK it's in the driver
<alyssa>
I don't think that really works
<alyssa>
it's an n:m problem
<alyssa>
like it would work "for now" but long-term we'll have many CL libraries across the tree, some for drivers, some common code, some for frontends
<alyssa>
and the latter can be used for various combinations of drivers / APIs
<alyssa>
it's not feasible for the driver to enumerate every library it might use - using CL in a common NIR pass should be an impl detail
<soreau>
is there a way to simulate a gpu reset in llvmpipe?
<jenatali>
IMO the right choice is for each component to have an init/uninit. E.g. if a common NIR pass happens to use CL then NIR (or that pass) needs an init/uninit
<alyssa>
can't do it in the frontend because there are driver libs (maybe even more than 1, if gl/vk get split out between a vendor. arguably asahi should probably have 3)
<jenatali>
Like how the GLSL type singleton requires callers to init/uninit
<alyssa>
yeah and I *hate* hate hate hate the glsl type singleton :p
<alyssa>
("so why'd you go and copy it?" "*sigh*")
<jenatali>
:)
<zamundaaa[m]>
soreau: I don't think there is, but that would be very cool
<alyssa>
The mental model with vtn_bindgen2 is that it's just nir_builder
<zamundaaa[m]>
Testing GPU resets by manually triggering amdgpu to do GPU resets again and again isn't exactly awesome
<alyssa>
whether the nir_builder is being done by hand or targeted from CL (or potentially GLSL?) is an impl detail, the caller shouldn't have to care
<jenatali>
Sure. But if the nir_builder has printfs in it then the caller might have to care
<jenatali>
Source doesn't matter, contents matter
<soreau>
zamundaaa[m]: that's what I've been thinking this whole time, while not implementing gpu reset event handling
<alyssa>
It has to care in the sense of "handling printfs" but shouldn't in the sense of "enumerating every place it might get format strings from"
<alyssa>
If we really can't do global ctor, the next best would be meson tricks to accumulate all the defiitions across the tree or something like that
<jenatali>
FWIW I'm not going to hard block it, I just want to make sure that it's really the right tool for the job
<alyssa>
*nod*
<jenatali>
If there's other options I want to make sure we explored those first
<soreau>
zamundaaa[m]: I suppose you could just fire the event on a compositor trigger to test with any driver, and then if it works, test 'for real' (since that's eventually unavoidable)
<jenatali>
DllMain bugs are awful to try to debug
<alyssa>
right..
<alyssa>
The other viable option is embedding the format string in the nir itself - not as a sideband in nir->printf_info, but as actual nir instructions
<jenatali>
I'd take global ctors over that :)
<alyssa>
...Fair :p
<alyssa>
It's really about the programming model
<alyssa>
the original sin here is format-strings being a sideband in NIR instead of first class
<alyssa>
all of the resulting dominos of nonsense (ending with global ctors) is just a consequence of marrying that sketchy design with the programming model of "self-contained nir_builder functions that Just Work"
<zamundaaa[m]>
soreau: you can, but that misses all the fun real world bugs
<alyssa>
(and like, everything else in NIR is fine here, it's just printfs that are uniquely screwed up such that the serialized NIR function impl does not actually tell you what the function does)
<alyssa>
(nir->xfb_info is pretty bad too but not relevant here)
<jenatali>
Yeah, fair
karenw has joined #dri-devel
<alyssa>
although now i'm wondering if there's a cleaner solution where the gpu binaries are still writing hashes (not whole strings) but the whole string is embedded as a nir intrinsic or something
<alyssa>
actually that doesn't solve my problem nvm
<jenatali>
There's the nir_debug_info intrinsics which have strings
<jenatali>
You could make the printf take an SSA value instead of a hash, and then embed the (hash, string) in a printf_string intrinsic
<alyssa>
wait that doesn't solve my problem though :/
<alyssa>
because of disk caching
<alyssa>
(would require backend special casing if the string isn't going into the binary proper)
<alyssa>
(which is very much Not Better than the alternatives I think)
<jenatali>
Oh because you need to process the format string without walking the nir?
<alyssa>
right
<jenatali>
Yeah. Hard problem for sure
<alyssa>
for the use case of "used a bindgen'd printf when compiling an app shader, that saved to disk, a week later we load the shader back and hit the printf instruction but we don't know what the hash is from"
cgbowman has quit [Remote host closed the connection]
cgbowman has joined #dri-devel
kaiwenjon has joined #dri-devel
kaiwenjon has quit []
<alyssa>
hmm.... but maybe I *can* solve this with Meson shenanigans
<alyssa>
currently bindgen'ing is happening in the leaves of the tree (e.g. in each driver's independent meson.build)
<alyssa>
but I guess we could invert that and do all the bindgen for the tree at root-level
<alyssa>
which is a little ugly but afaik legal
<alyssa>
and then we can easily aggregate all boundgen-things across the tree at a meson level
LeviYun has quit [Ping timeout: 480 seconds]
<alyssa>
and at that point I'm ... not even sure if we need the singleton tricks, since it all becomes static
<alyssa>
dcbaker: are you around? this is out of my wheelbarrow
<alyssa>
(if we're going to do it this way we should probably pivot now since it would render much of the code in that MR redundant)
<daniels>
if all you want to do is aggregate, then put generated_nir_progs = [] at the root level, have every leaf do e.g. generated_nir_progs += libagx_h in its own meson.build, then at the end you have a fully-populated array of targets
<alyssa>
daniels: that might be the way to go.. I'm trying to figure out where "the end" would be, though
<alyssa>
I guess I should just try that and find out what blows up :p
<alyssa>
thanks
balrog has quit [Ping timeout: 480 seconds]
<daniels>
at the bottom of src/meson.build, where subdir('tool') is, you'll have processed all other src/ subdirectories, so the array will be as full as it's ever going to be
<daniels>
then probably what you want is subdir('src/compiler/nir/prinwtf') or whatever, and do whatever it is you're trying to do in src/compiler/nir/prinwtf/meson.build
<alyssa>
nice 'typo' XD
<alyssa>
the complication there is that prinwtf/meson.build would spit out an object file which needs to link with every relevant .so in mesa ... except all those .so's were from all the subdirs above
<daniels>
that's fine, it's a global namespace
<daniels>
so libagx = shared_library(...) in src/asahi/libagx/meson.build will be available to any other meson.build, provided it's sourced later
LeviYun has joined #dri-devel
<alyssa>
the problem is in the other direction... prinwtf/meson.build would be declaring `libwtf = shared_library(..)` and then {libgallium_dri.so, libpanvk.so, ...} all need to link with libwtf.so
<alyssa>
except libwtf hasn't been declared yet becuase it depends on all those drivers' subdirs
<alyssa>
it's cyclic at a meson.build level (even though the actual data flow isn't cyclic - I don't think meson can break that cycle itself)
jernej has quit [Ping timeout: 480 seconds]
DarkShadow44 has quit [Ping timeout: 480 seconds]
DarkShadow44 has joined #dri-devel
jernej has joined #dri-devel
<daniels>
yeah, in that case you'd need to have src/ include compiler/wtf/, then have compiler/wtf/ include src/asahi/wtf/ + src/panfrost/wtf/ + ... and use that to build libwtf, then have everything later link with libwtf
LeviYun has quit [Ping timeout: 480 seconds]
<alyssa>
mmmh right
<alyssa>
and then the added spice I'm now seeing is that our (intel, asahi, and mary's MR for pan) spv's are depending on generated source files from genxml
<alyssa>
which causes heartburn for both directions of meson tricks
<alyssa>
maybe the global ctor isn't so bad ;-;
<daniels>
do the genxml in wtf and then they'll be available to the driver build later
<daniels>
('later' in the sense of, the meson.build is parsed via a subdir() call occurring afterwards)
<alyssa>
that should work ... i'm trying to figure out if we're actually better off at that point.
<alyssa>
will mull on this
<alyssa>
thanks for the input :}
vliaskov has quit [Ping timeout: 480 seconds]
fomys has quit []
karenw has quit [Ping timeout: 480 seconds]
<daniels>
np
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
<pixelcluster>
mlankhorst: regarding the dmem fix, the general issue happens whenever you have a cgroup that doesn't have a pool that's part of the pool hierarchy we're currently traversing (simplest case would probably be a cgroup with no pools) - that cgroup must also have at least one child
<pixelcluster>
hope that's somewhat understandable? hard to put into words but I'm not sure I have enough ascii art skills to visualize it either :S
<mlankhorst>
so basically cg1/cg1_1,cg1_2 and evicting from cg1_2?
<mlankhorst>
and then what is the failure with cg1_1?
<mlankhorst>
* XE_BO_FLAG_SCANOUT should ideally be set at creation, or is
<mlankhorst>
* automatically set when creating FB. We cannot change caching
<mlankhorst>
* mode when the boect is VM_BINDed, so we can only set
<mlankhorst>
* coherency with display when unbound.
jkrzyszt has quit [Quit: Konversation terminated!]
sima has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
<hakzsam>
dcbaker: yes
<dcbaker>
Sweet, its on the marge queue and will be the last thing in the release today
rgallaispou has joined #dri-devel
mbrost has joined #dri-devel
kzd has joined #dri-devel
kaiwenjo1 has joined #dri-devel
kaiwenjo1 has quit []
jsa1 has quit [Ping timeout: 480 seconds]
coldfeet has joined #dri-devel
jsa1 has joined #dri-devel
<pixelcluster>
mlankhorst: more like cg1/(cg1_1/cg1_1_1),cg1_2, then evicting from cg1_2; cg1_1 (and by consequence cg1_1_1) would be the cgroups that have zero pools (or only unrelated ones)
<pixelcluster>
the issue is that, when iterating over cg1_1's pools, we overwrite our "current pool" variable (that's "pool" in code) - the next loop iteration we'll descend down the hierarchy to cg1_1_1, at which point we'll set the "current parent pool" variable ("parent_pool" in code) to the value of the "current pool"
coldfeet has quit [Ping timeout: 480 seconds]
<pixelcluster>
but we just overwrote "current pool" with some completely unrelated pool (or didn't overwrite it at all...)
mbrost has quit [Ping timeout: 480 seconds]
<pixelcluster>
so in the end we'll traverse some pools that are completely unrelated to the ones we started with, or something like that