03:37 airlied: whoever does the v3d runners, looks like jobs schedules on some of them are dying with serial.serialutil.SerialException: [Errno 2] could not open port /dev/serial/by-path/pci-0000:00:14.0-usb-0:2.1.4:1.0-port0: [Errno 2] No such file or directory: '/dev/serial/by-path/pci-0000:00:14.0-usb-0:2.1.4:1.0-port0'
03:58 mupuf: eric_engestrom: ^
04:40 airlied: ah LVP_POISON_MEMORY is the secret CI thing I didn't have locally
07:28 airlied: oh nuts, you are in a maze of twisty atexit handlers, llvm registers one, piglit registers one, piglit's one triggers after llvm's one, causing a flush which causes and llvm recompile
07:37 MrCooper: flush as in glFlush?
08:42 mlankhorst: lumag: usually we wait for a conflict btw. :)
08:42 mlankhorst: And then use that as justification
08:43 mlankhorst: https://lore.kernel.org/lkml/CAHk-=wh-u8dKyLtcDo4Vd=p==9hOH5D40de3tpC_rr_8eo9Lwg@mail.gmail.com/
08:55 sima: mlankhorst, should we have that as a reference in the dim docs maybe?
08:55 sima: jani, ^^
08:56 sima: iirc it's one of the clearest and least angry "how to do merges" explainers from linus
09:01 jani: sima: I'm a bit surprised he seems to promote topic branches while that's been frowned on lately in drm land
09:02 sima: jani, it's mostly that I think topic branches are overkill and it's simpler to just ack for merging through the tree where most of the work would have landed
09:04 sima: jani, I guess we could do it like linus proposed, but it means committers would push entire branch merges
09:04 sima: and I don't think that's a good idea for us with the committer model
09:04 jani: agreed
09:05 sima: but the part about why/how to do merges does apply to us too, fully
09:07 jani: sima: yeah, uh, git log --author=jani.nikula --since={2years} --merges
09:09 sima: jani, yeah if your merge commit message has the word "sync" in it, it's probably not so good :-P
09:55 mlankhorst: Usually an excuse like 'requested by lumag for preventing a conflict in applying patches', with an explanation of which patches conflict is good enough
09:57 mlankhorst: My personal take on this is that linus likely just looks at all merge commits when merging a tree, and doesn't like to waste his time on reading backmerge commits
10:12 MrCooper: I notice that neither amdgpu nor i915 list DRM_FORMAT_MOD_INVALID in IN_FORMATS, even though they support implicit tiling parameters; is this intentional?
10:13 emersion: there is no way for KMS drivers to opt-out of implicit modifier support
10:13 emersion: IOW, all KMS drivers support implicit modifiers
10:14 emersion: KMS doesn't use INVALID to represent implicit modifiers
10:14 emersion: unlike the Wayland protocol
10:16 lumag: mlankhorst, the oob hotplug series (https://patchwork.freedesktop.org/series/120393/) requires 6.6-rc
10:17 MrCooper: emersion: k, thanks
10:35 pq: mdnavare, robclark, https://patchwork.freedesktop.org/patch/552839/ maybe?
11:00 pq: sima, "a pretty endless list of hw limitations" is fine, userspace can deal with atomic commit failing when it is taking features into use. But if turning features like CTM "off" (identity matrix counts as off) fails, that's practically recoverable. Turning things off *is* the fallback for userspace, it cannot fall back from that.
11:01 pq: sima, yeah, documenting it is part of the new color pipeline UAPI effort.
11:02 sima: pq, so I think generally you can fall back to a pass-thru mode, but fully turning things off as in releasing resources is on some hw simply not possible
11:03 sima: so you might still end up stuck in a configuration corner that you can't get out of without ALLOW_MODESET
11:04 pq: for compositor robustness, I believe compositors should do their modesets using their full fell-back state, and then enable additional features only without ALLOW_MODESET to ensure they can also back out from the features without ALLOW_MODESET.
11:04 sima: that's a thing we cannot guarantee across the board
11:04 pq: and that's what drivers need to give us
11:05 sima: we can try really hard, but guarantee is too much
11:05 sima: essentially what you want is an atomic test_only which checks two things a) can I flip to this without flicker b) can I then flip to my known safe config without flicker
11:05 sima: there's currently no way to ensure b)
11:06 pq: funky hardware can be funky for sure, but make sure to require ALLOW_MODESET if you can't go or revert without.
11:07 sima: since currently what we can do is "current state" -> "arbitrary state A"
11:07 sima: what you want is "arbitrary state A" -> "arbitraryt state B" TEST_ONLY queries
11:07 pq: Userspace that is happy with a static setup will just do one ALLOW_MODESET commit when it starts, and be done.
11:07 sima: would be a pretty big rewrite
11:07 sima: yeah I understand what you want
11:07 sima: I'm telling you atomic cannot guarantee this
11:07 sima: and it would be a huge amount of work to get there
11:08 sima: we'd need to rewrite everything so that atomic check doesn't look at the current state, but an explicitly passed-in state
11:08 sima: and then we'd need a new interface for userspace to do these checks, since the kernel has no idea what the safe fallback state even is
11:09 austriancoder: karolherbst_: What would be needed in rusticl land to be able to use a native rotate instruction? Maybe I am missing some magic nir switch etc.? Here are is my used cl test with the current nir and blobs binary: https://tmp.christian-gmeiner.info/rotate.txt
11:09 sima: and if we preemptively just reserve all kinds of resources (fifo space, memory bw, clocks, ...) for all compositors fallback states, we're screwed
11:10 karolherbst_: austriancoder: update vtn_opencl.c
11:11 karolherbst_: atm we call into libclc for that
11:11 pq: sima, no-one said that if the driver failed UAPI promises, userspace will keel over. If going back to basic state is not possible without modeset, then I would expect any compositor to just do the modeset, and scream at the user that your driver is broken.
11:11 karolherbst_: and then make it go through the nir_alu_op_for_opencl_opcode path instead and emit the nir instruction
11:11 sima: pq, yeah that's pretty much my argument too, if you want a robust compositor you need this fallback
11:12 sima: and then probably mark some features as "can't use that safely"
11:12 karolherbst: uhm.. I think in nir it's urol/uror, right?
11:12 sima: since only when you set ALLOW_MODESET does atomic guarantee that the TEST_ONLY result is the same, irrespective of the current state
11:12 sima: without allow_modeset TEST_ONLY applies only to that specific state _transition_
11:13 karolherbst: austriancoder: alternatively just handle it explicitly inside handle_special so it doens't go through handle_clc_fn
11:13 karolherbst: but that kinda depends on how rotate needs to be implemented
11:13 sima: so A->B works does not imply that B->A can work
11:13 sima: and it's also not transitive
11:13 austriancoder: karolherbst: I think .. have not thought too deep about it :) Just have seen the a brutal difference with instruction counts and wanted to know what to do.
11:14 karolherbst: yeah... fair :D
11:14 karolherbst: but yeah, all the SPIR-V CL instructions are handled inside vtn_opencl
11:14 austriancoder: karolherbst: I will dive into it the next 1-2 day
11:14 karolherbst: cool
11:15 karolherbst: I think I was there at some point, but for some reason I ended up using libclc for it anyway
11:15 karolherbst: maybe we don't have a proper lowering path in place?
11:15 austriancoder: so be prepared for some questions
11:15 austriancoder: maybe
11:15 sima: pq, also I guess I disagree that this would necessarily imply a broken driver, there really is hw which is a lot of "fun"
11:15 karolherbst: but we do have lower_rotate...
11:16 karolherbst: ohh yeah.. that's newer than the vtn_opencl stuff
11:17 austriancoder: so in nir it would be a urol
11:18 MrCooper: sima: the compositor can complain about "broken HW/driver" then ;)
11:18 karolherbst: if it maps 1:1 then make it use nir_alu_op_for_opencl_opcode, if it needs special nir handling, just do it in handle_special
11:18 karolherbst: handle_alu -> nir_alu_op_for_opencl_opcode is the path
11:19 karolherbst: but you might want to check for `lower_rotate` or we just require drivers to set it
11:19 karolherbst: kinda depends on if the CL CTS is happy or not
11:20 austriancoder: I see
11:21 pq: *unrecoverable
11:22 sima: MrCooper, not sure that helps either, since imo the pain is between exposing features of the hw and people trying to use them
11:22 sima: if we just don't expose the features then it's back to "terrible driver support"
11:23 pq: sima, userspace has no information and therefore does not care at all, if turning something off actually releases resources or not. It's simply not observable.
11:23 karolherbst: austriancoder: the most annoying part is all that offset stuff I'm doing unconditionally... not sure what's the best way of getting rid of the math there btw... probably shader variants
11:23 karolherbst: or does your hardware have native support for it?
11:23 sima: pq, it is on the next commit, like when you try to fall back on multiple outputs
11:24 sima: it's just not very directly observable, but it's the reason why !allow_modeset test_only checks are neither transitive nor reversible
11:24 austriancoder: karolherbst: depends on the gpu model .. but I have a nir pass for that
11:24 karolherbst: mhh
11:24 karolherbst: I mean, atm I handle it all in the frontend, because on 64 bit hardware it also requires 64 bit offsets
11:25 karolherbst: but that offset feature is mostly never used
11:25 karolherbst: and if you require offsets your task runs for hours anyway, so the overhead of variants is super unimportant... mhhh....
11:25 karolherbst: maybe I really deal with that in the frontend like that
11:26 pq: sima, testing for "arbitrary state B -> arbitrary state C" is not necessary. All a driver needs to test is "current state" -> "given state" *and* "given state" -> "current state".
11:26 pq: and only if the commit does not have ALLOW_MODESET
11:26 sima: pq, that doesn't give you what you want
11:27 pq: we can have a DRM cap for such behavior, I understand it's a new requirement.
11:27 sima: like you want A->B and B->A
11:27 sima: but then you do B->C, but you still want to check for C->A as the fallback
11:27 sima: not C->B->A as your fallback
11:28 sima: and again, they're not the same
11:28 sima: pq, also implementing what you want is as much work as implementing generic B->A checks
11:28 sima: since I flat out don't trust humans to correctly judge whether something is inversible or not
11:29 austriancoder: karolherbst: ahh 64 bit offsets .. nothing I thought about yet.
11:29 austriancoder: karolherbst: PIGLIT: {"subtest": {"rotate int1" : "pass"}} - with less instructions :)
11:29 karolherbst: nice
11:29 karolherbst: though that's piglit :D
11:29 austriancoder: :)
11:30 austriancoder: I will prepare an MR and see what CI thinks about it
11:30 karolherbst: in the CTS it's test_integer integer_rotate
11:30 karolherbst: probably breaks for char/shorts/longs in the CTS...
11:30 pq: sima, if hardware is unusable for generic desktops, then it is unusable for generic desktops. If hardware has features that cannot be reasonably used, then they cannot be reasonably used. It's that simple.
11:30 karolherbst: hopefully not
11:31 karolherbst: austriancoder: but yeah... atm I do all the CL CTS testing manually on my machine and run it through various GPUs
11:31 pq: also: if userspace is willing to ALLOW_MODESET always, then all hardware features are usable in this respect.
11:31 sima: pq, I'm more trying to figure out what compositors would actually need
11:33 sima: or whether the best pragmatic option is "everyone does best effort, but you need an absolute last ditch effort that includes ALLOW_MODESET because the alternative is your desktop dies"
11:34 sima: and I get a bit an impression this last ditch escape hatch is not acceptable
11:34 pq: Compositors want predictable behaviour which inlucdes the ability to get back to a simple baseline state always with no end user disruption. When that's not possible, compositors would fall back to ALLOW_MODESET, which causes people to file bug reports on the compositor.
11:35 pq: That's for generic desktop compositors specifically.
11:35 sima: yeah I think asking for a bug report is fine, then we can figure out how to sort out the mess
11:36 sima: I just had way too much cases of people enabling some feature, testing it on their one machine&config and shipping it
11:36 pq: Special purpose compositors have different requirements, like falling back ever for any reason makes the system unusable for example (set-top boxes).
11:36 sima: and then the kernel having to bend over backwards to keep up the illusion that all these assumptions somehow hold
11:36 sima: pq, yeah but those generally are a lot more fine tuned for the hw and use-case
11:37 sima: and can make assumptions about the hw/driver that go beyond what atomic uapi guarantees
11:39 sima: pq, so if you want that "go back to simple baseline state" to not just be best effort but an actual guarantee, that's a) substantially uapi extension with b) a shit ton of driver work and c) probably really hard to actually validate and guarantee it's better than the current "we'll try really hard" approach
11:39 sima: for !allow_modeset, for allow_modeset we do guarantee it, and most of the validation effort is shoulder through the kernel internal atomic design
11:40 pq: sima, the state testing is transitive without ALLOW_MODESET. Current state is A. If test for state B succeeds, then A->B and B->A must work. Commite state B. Test for state C. If state C works, then B->C and C->B must work. Therefore it is always possible to get back to A through B. If it's not, test for C fails. Without ALLOW_MODESET, a driver is not allowed *release* hw resources that might end up used by
11:40 pq: something else.
11:41 sima: pq, yeah, and currently we do not guarantee this at all
11:41 sima: and if you want full transitive, I'm not even sure how to implement that
11:42 sima: even on _really_ nice hardware
11:42 sima: the moment you have any shared resources that need a bit of sync it's out
11:42 sima: iow, if you want full transitive, gpu compositioning it is
11:43 pq: is anything ever an actual guarantee? I didn't think so.
11:43 sima: if you set ALLOW_MODESET, we do guarantee everything you listed
11:44 pq: yes, this is all new UAPI
11:44 sima: because that was a core pinnacle of atomic, it's flat out impossible to reliable drive multiple crtc without this because you can get into corners too easily
11:44 sima: but we can only guarantee this because essentially ALLOW_MODESET _always_ goes through the "everything off" state and then optimizes unecessary transitions out
11:45 sima: as soon as you disallow that, transitivity and inversion are out
11:45 pq: yeah, I'm describing what I would want, regardless of whether it's possible.
11:45 sima: and if you insist they're not we need to statically assign all shared resources and never change that
11:45 sima: for some value of "statically"
11:46 sima: probably driver lifetime
11:46 pq: the KMS color pipeline UAPI though has a much more limited scope and much better defined "must be able to turn off" requirements.
11:46 austriancoder: karolherbst: I only have one desktop GPU where I could do testing.. so I need to trust CI :D
11:46 sima: yeah within a very limited feature set we might be able to actually guarantee that
11:46 sima: but I'm honestly worried about the validation effort
11:47 sima: like if you just put this into docs it's not going to be worth more than the bits to store it
11:47 sima: there's a lot of internal consistency checks and "impossible by design" stuff to make the ALLOW_MODESET guarantees work
11:48 pq: there's always blinky and screaming, and with DRM fligh recorder, maybe even a clue of what went wrong
12:14 karolherbst: austriancoder: yeah... I kinda want to wire up CL CI, but uhh...
12:15 karolherbst: it takes like 15 seconds to trigger and run it here on three drivers
12:15 karolherbst: just open the MR and I'll verify it doesn't break anything
12:17 austriancoder: karolherbst: The blob uses the same single instruction for different data types (just with a different return value type) .. that is nice. on mesa I am hitting an assert :)
12:18 karolherbst: yeah...
12:18 karolherbst: I suspect urol/uror are 32 bit only
12:18 karolherbst: and now I remember why I haven't wired that up
12:18 karolherbst: ohh
12:18 karolherbst: just the second source needs to be 32 bit...
12:18 karolherbst: might be enough to throw in a `nir_u2u32`
12:21 austriancoder: karolherbst: I updated the previous link .. at the bottom are more infos regarding the assert
12:21 karolherbst: yeah
12:21 karolherbst: the second source to uror/urol needs to be 32 bit
12:22 austriancoder: lets try that
12:42 austriancoder: karolherbst: llvmpipe-piglit-rusticl is green now .. would be really cool if you could run it on your gpus: https://gitlab.freedesktop.org/austriancoder/mesa/-/commits/cl-rotate
12:42 karolherbst: yep, will do so in a second
12:43 karolherbst: austriancoder: thow I think it's better to just handle that in `handle_special`
12:43 swick[m]: sima: I don't get why A->B doesn't give us B->A as well if both commits are !ALLOW_MODESET
12:44 sima: hw is funny
12:44 sima: iirc for an example the panel scaler on older intels can be disabled without a modeset, but not enabled
12:45 sima: in general assigning resources can take more than a vblank (if you need to steal something from another crtc first) whereas releasing them usually doesn't
12:46 sima: like ramping up clocks and stuff like that
12:46 sima: swick[m], ^^
12:47 swick[m]: okay, but in these case you absolutely know for certain that enabling might require ALLOW_MODESET, so you could gate disabling them with ALLOW_MODESET as well
12:47 austriancoder: karolherbst: yeah.. lets see if CI is happy then I change it
12:48 sima: swick[m], yeah in general disabling stuff has fewer requirements, except that userspace doesn't really know what kind of transitions means hw pieces have to be disabled or enabled
12:48 sima: like going back to your safe config might mean that you need to get hold of a full-screen scanout thing again
12:49 swick[m]: right, so don't allow any commit with !ALLOW_MODESET which would disable the full-screen scanout thing
12:49 sima: so even if we'd do a "disabling doesn't require modeset if enabling doesn't" userspace doesn't have enough insights into hw to actually know what state transitions only disable stuff
12:50 sima: swick[m], that would piss off the people who _want_ us to use the hw fully
12:50 swick[m]: make it a new flag
12:50 sima: then the validation problem strikes
12:50 sima: it's a lot more than "add a flag to the uapi"
12:50 swick[m]: what exactly do you mean with validation problem?
12:51 sima: so you have some safe state S
12:51 sima: essentially the flag would need to guarantee that for any A->B test-only atomic check
12:51 sima: we then also guarantee that B->S doesn't require a modeset
12:51 sima: for some compositor specific S
12:51 sima: or sessions specific or whatever
12:52 sima: validating that B->S will work requires a substantial rewrite, it's flat out not something current atomic can answer
12:54 swick[m]: I mean, you're saying that this needs work in drivers, which is definitely true
12:55 swick[m]: but the rules are not that hard, are they? if the flag is set, don't do anything that requires a ALLOW_MODESET to get back to the current state.
12:55 sima: swick[m], nah the semantics isn't hard
12:55 sima: the driver work is
12:55 sima: currently for testing A->B drivers just look at the current state to get at A
12:56 sima: if you want to validate B->C, you need to guarantee that drivers _never_ look at the current state, but instead at the free-floating old state
12:56 sima: there's a _lot_ of kms atomic code in the kernel nowadays
12:56 sima: and this does not cover the drivers which track even more funky transition state in their atomic machinery, only the basic kms drivers
12:57 sima: or you just pray that driver writes will deduce this correctly and handle in the code, without doing the actual B->C validation
12:57 sima: and I can guarantee you that'll not work, because even the current atomic rules are pretty hard for drivers to get right without too many bugs
12:58 sima: so if you do the simple way you'll get lots of "sure this'll work" and then you use it and you'll get "I'm terribly sorry"
13:05 swick[m]: sima: mh, but everything that's required is validating A->B && B->A, then all the changes with the new flag are transitive. are you saying that validating B->A would be somehow harder than validating A->B?
13:05 pq: about getting things right; there is no file or anything else simple that would flag a kernel patch as adding new UAPI in the form of a new KMS property, is there?
13:06 pq: I wonder which undocumented properties of e.g. https://drmdb.emersion.fr/properties?object-type=4008636142 are actually upstream.
13:06 sima: swick[m], because the current code can only validate "current state" -> A
13:06 swick[m]: got it
13:07 sima: and changing that assumption is the really big thing
13:07 emersion: pq, yeah, it would be nice to show UI explaining which dumps are official kernel and which aren';t
13:07 sima: once you fixed that we can easily go one step further and validate A->B for arbitrary A and B
13:07 pq: emersion, how could you even tell what is an upstream kernel?
13:07 emersion: pq, recently added https://gitlab.freedesktop.org/emersion/drm_info/-/commit/e7a17967a73c8371681d324ed70e4594950c62ab
13:07 emersion: and kernel version can help a bit
13:08 swick[m]: sima: the question really is if there is a simpler way to get the guarantees a generic user space needs
13:08 swick[m]: sima: but I suspect not tbh
13:08 sima: swick[m], in theory yes, but I've seen enough atomic check code that I flat out don't trust anything simpler that doesn't boil down to doing the _exact_ A->B validation you want
13:09 sima: the code is so complex (for more complex hw than single crtc, fixed plane, nothing else) that if you don't run identical code, you wont get identical answers
13:09 sima: like heck we have a hard time sometimes that atomic check and commit agree, people love to add error codes to callbacks with void return type
13:10 pq: I suspect drivers may be sneaking new KMS props upstrem and no-one notices.
13:10 sima: pq, I periodically check for these and scream
13:11 pq: sima, awesome - how do you detect them?
13:11 swick[m]: but what should we do then? if we don't change KMS then we can't really use any of the KMS features at all.
13:11 swick[m]: if we do the "can't return to default state, using a ALLOW_MODESET commit" thing we have to stop using anything but the default state
13:12 swick[m]: thus we stop using most features on all hardware/drivers which don't work by accident
13:12 swick[m]: so all the exposing of hardware features is utterly useless
13:13 swick[m]: and every time we try to use more KMS features we run into all kinds of stupid problems and have to disable it on some hardware to the point where everything is hardware specific after all
13:15 pq: hard to write a CTS for KMS when what you need to observe is something you cannot observe in software...
13:15 swick[m]: yeah, that as well
13:15 swick[m]: whenever we enable more KMS features, we break someones system
13:16 zmike: bbrezillon: it seems like you are the vk_cmd_queue_gen.py expert ?
13:17 swick[m]: we have to release the software, they have to start using it, experience some bug, report it upstream, then we have to figure out what is going wrong without having the hardware, and then maybe fix it for the next version
13:17 swick[m]: this situation is not workable IMO
13:17 swick[m]: we need more guarantees from KMS and we need better testing
13:17 sima: pq, grepping for drm_property_create essentially
13:18 sima: and last few years I think the only somewhat icky one is vc4 copypasting the rgb broadcast property instead of lifting it to drm shared code
13:18 sima: but that's an internal thing, shouldn't be visible to userspace because they match
13:19 pq: cool, so probably all the oddballs I see are downstream
13:19 sima: mripard, ^^ d6020f4b26179481c7cb13aa94d7abcdfd8a4326 is the commit
13:19 sima: pq, yeah I think we've become fairly good at doing property uapi much better than in the past
13:21 swick[m]: my main problem is that if things work, they only work by accident
13:21 swick[m]: driver devs don't understand what we actually need, it's not documented anywhere and the API is not making it clear either
13:21 swick[m]: so things never get better
13:22 mripard: sima: I'm not sure I get it, last time we discussed it your pov was to not create a helper for it because there was a single user
13:22 mripard: anyway: https://lore.kernel.org/dri-devel/20230920-kms-hdmi-connector-state-v2-3-17932daddd7d@kernel.org/
13:23 mripard: I'm glad we agree that a helper for that property would be nice :)
13:23 sima: mripard, sometimes I'm stupid
13:24 mripard: I didn't say that? very far from it
13:24 sima: mripard, so i915 can't use this one for some reason?
13:24 sima: s/stupid/inconsistent/ maybe better
13:25 bbrezillon: zmike: am I? :D
13:25 zmike: bbrezillon: git log says yes :D
13:25 sima: swick[m], I think one part is also that there's no library of funny hw for compositors to test against
13:26 sima: which is why I'm hoping vkms could eventually get there
13:26 sima: that way you could test against strange corner cases before shipping
13:26 sima: and we could slowly build up a set of cases that compositors need to handle, but which are strange enough that they usually get lost in testing
13:26 mripard: sima: I mean, the not-a-helper-for-a-single-user rule makes sense, really
13:26 zmike: it seems when handling the params for cmd enqueue, something like struct<array<val>> is handled (alloc->alloc->memcpy), but struct<array<struct>> is not (should be alloc->alloc->alloc->foreach->memcpy)
13:27 mripard: which is why I'm also surprised there :)
13:27 sima: mripard, yeah but I thought it's two here with vc4 and i915
13:27 zmike: bbrezillon: is there a way you can make this handle itself recursively so any number of nested array/struct/array combos work?
13:27 swick[m]: sima: that would help a lot, but as long as the API still doesn't give us the guarantees that we actually need to write generic code that also can't be the entire answer
13:27 mripard: but anyway, I looked at i915 and it was mostly storing it in a very different datastructure than what the helpers are using
13:27 zmike: I tried reading the code here but python is not really my forte :/
13:27 sima: swick[m], ime compositors fail at stuff that we really cannot ever guarantee
13:27 mripard: so the rework looked above my i915-fu, especially for an RFC
13:27 sima: like blindly assuming that you can use any tiling format, and then getting disappointed
13:28 swick[m]: ofc there is a lot of stupid user spaces out there
13:28 sima: this is stuff we cannot ever guarantee because light speed is not infinite and so neither is memory bw
13:28 mripard: If you want that for the next version, I can totally do it
13:28 sima: mripard, yeah maybe follow up or something, or a todo
13:28 swick[m]: but it's also literally impossible the write a generic compositor with the guarantees we get
13:28 sima: mripard, anyway I'm really happy about the docs for the prop
13:28 swick[m]: well, literally impossible in the sense that we can't use offloading and color transofmrations
13:28 zamundaaa[m]: The "any tiling format" case specifically is effectively impossible for compositors to handle...
13:29 sima: swick[m], I think this needs more shades
13:29 sima: mostly you can, it's just if you absolutely rely on the fallback to always work and if it doesn't, you just kill the desktop
13:30 sima: you're pretty much guaranteed to kill tons of desktops
13:31 sima: in practice I think things fall over a lot more with just hardcoded assumptions that don't hold up, and testing against vkms models would cover those
13:31 swick[m]: that's most likely true. mutter is especially bad at this...
13:31 emersion: i don't think i'm aware of any user-space handling the tiling modifiers stuff properly
13:31 swick[m]: but I also don't see how we could write a compositor without getting to some default state
13:31 bbrezillon: zmike: it's been a long time, and python is not my area of expertise either, but I can have a look
13:31 emersion: as in, try using other modifiers on other CRTCs to light up a new output
13:32 zmike: bbrezillon: oh
13:32 sima: swick[m], well atm we're still at the "compositors can't even reliable figure out the default state to start with"
13:32 sima: at least for the tiling fun
13:32 zmike: I can try to find someone more expert...
13:32 sima: so "how can we reliably get back to the default state" is a few steps further
13:34 sima: emersion, you might need to switch the modifier on the current one even, if that's using up all the fifo space already
13:34 bbrezillon: zmike: what's the CmdXxx you're looking at?
13:35 emersion: sima: yeah, by "other" i mean "other than the one i try to light up"
13:36 sima: emersion, yeah it's a full config problem, looking at a single crtc isn't how atomic works, so not likely to help find you something that the hw/driver can do
13:36 zamundaaa[m]: FWIW KWin allocates a buffer with implicit modifiers as the fallback for when it can't make things work with the modifier list - with the assumption that Mesa will pick one that works for driving all outputs simultaneously. But obviously that's not actually a good or reliably solution (even if it works in practice so far)
13:37 emersion: zamundaaa[m]: that's not enough, needs to re-alloc already-on outputs too potentially
13:37 zamundaaa[m]: Even that is problematic though, because we don't actually have any information about why the atomic commit fails in the first place
13:37 sima: zamundaaa[m], it'll stop working the moment mesa hands you a linear buffer and your rendering becomes a slideshow
13:37 zamundaaa[m]: emersion: KWin always does modesets on all outputs at the same time
13:37 emersion: oh, nice
13:38 emersion: so if i have 3 outputs and plug a new one, it'll try to re-allocate buffers for all outputs?
13:38 emersion: potentially degrading to the implicit modifier on all of them?
13:38 zamundaaa[m]: yes
13:38 sima: well it will still work, just not to the user's satisfaction most likely
13:38 emersion: okay, so that's one compositor
13:38 sima: ship kwin everywhere, call it done
13:38 zamundaaa[m]: sima: it's better than not having the outputs light up at all, or needing to test the 10 million possible combinations of formats and modifiers that could maybe make it work
13:39 sima: zamundaaa[m], explicit linear might be the more safe fallback I think
13:39 emersion: zamundaaa[m]: have you tried using non-blocking modesets? because we're seeing issues on amdgpu
13:39 sima: if it's purely fallback to light up something
13:39 zamundaaa[m]: emersion: I wanted to, but then I can't get a pageflip event in all cases
13:40 sima: emersion, amd's dc loves to just pull in all crtc for any modeset
13:40 emersion: zamundaaa[m]: requested page-flip event but off?
13:40 zamundaaa[m]: yes
13:40 emersion: a classic
13:40 emersion: maybe we could have a "please_send_pageflip_event" prop or something
13:41 emersion: or just use drmCrtcQueueSequence maybe?
13:41 zamundaaa[m]: or simply a flag that disables that stupid workaround
13:41 emersion: or yeah, just nuke it
13:41 sima: hm which workaround?
13:41 emersion: sima, if you try to page-flip a CRTC and in the same commit also disable another CRTC, you can't get a page-flip event
13:41 sima: the atomic commit infra should get really pissed if drivers don't send out events, because way too many outright failed for anything else than pure flips
13:42 zamundaaa[m]: sima: https://gitlab.com/linux-kernel/linux/-/blob/master/drivers/gpu/drm/drm_atomic.c#L419
13:42 emersion: the kernel EINVALs because PAGE_FLIP_EVENT is used when one of the CRTCs involved is off
13:42 sima: ah yeah this lols
13:43 emersion: DRM_CLIENT_CAP_I_PROMISE_I_WONT_DO_INFINITE_LOOP_AND_BE_A_GOOD_KID
13:43 zamundaaa[m]: perhaps adding a PAGE_FLIP_EVENT_ON_ENABLED_CRTCS flag or something would work too. But either way we'd still have to carry the workaround for many years to come
13:43 sima: emersion, https://gitlab.com/linux-kernel/linux/-/blob/master/drivers/gpu/drm/drm_atomic.c#L1462 there's also this one we'd need to sort out I guess
13:44 karolherbst: austriancoder: looks like the patch is fine
13:44 emersion: sima, in general i think a NONBLOCK mode where the kernel waits for any pending page-flips would be useful to user-space
13:44 emersion: instead of EBUSY
13:45 sima: emersion, yeah that's the third side of this coin I think
13:45 sima: useful nonblock modeset semantics essentially
13:45 emersion: right now it's very hard to figure out when user-space can request NONBLOCK without getting EBUSY
13:45 sima: hide behind cap
13:46 sima: emersion, you can't really :-)
13:46 emersion: so we have a patch to retry without NONBLOCK when we get EBUSY 💩
13:46 sima: you need the affected_crtc outparam, probably a knob to shut up about nonblock, and events irrespective of the crtc state because you know what you're doing
13:47 emersion: and i can see how tempting it would be to have a separate thread just to emulate the non-buggy NONBLOCK behavior
13:47 sima: or some combo of these three, not sure what compositors would really all need
13:47 sima: you still have no clue about affected_crtc
13:47 zamundaaa[m]: emersion: actually I might just do that. Should be dead easy in KWin
13:47 sima: which is why we added this, people complained about random dropped frames
13:49 sima: emersion, what about a new flag which a) always fails when affected_crtc != requested_crtc and b) passes affected_crtc back to userspace so you know what's going on?
13:49 sima: then you shouldn't have any spurious EBUSY
13:49 sima: no unexpected lost vblank
13:49 zamundaaa[m]: hmm, actually it might not be that easy. Doing atomic test_only commits on top of the "current" state is quite difficult when the "current" state isn't actually current as far as KMS is concerned
13:49 sima: and should be able to use nonblocking modesets?
13:50 sima: maybe then also allow events on off->off crtc with the same flag
13:50 emersion: so user-space would try to modeset a CRTC, get EBUSY, notice affected != requested, wait for affected, retry?
13:50 sima: "actually it might not be that easy" this is pretty much anything in kms :-/
13:51 sima: emersion, more like you do a test_only, if fails but you get back a different affected_crtc, you add a few dummy props for these crtc and add them to your book-keeping and retry
13:51 emersion: oh
13:51 sima: maybe we should actually start giving back more error reasons than EINVAL with this
13:51 emersion: so basically a way for the kernel to say "hm i need these other CRTCs to be involved in the commit"
13:52 sima: *dummy props = the events for these crtc so you know when it's done
13:52 sima: yeah
13:52 zamundaaa[m]: sima: that sounds more like compositors should all stop doing modesets on singular crtcs in general?
13:52 emersion: and require userspace to honour that
13:52 sima: and for userspace to enable the events so it can keep track of these additional updates going on
13:52 sima: zamundaaa[m], it would allow you to make them work better
13:53 sima: but yeah atm you do a modeset, you have a chance of dropped frames on the other screen
13:53 austriancoder: karolherbst: wohooo .. I will make the regarding handle_special and create an MR
13:53 karolherbst: cool
13:53 sima: in general atomic tries really hard to not make that happen, but if the hw requires might be useful userspace is aware?
13:54 sima: zamundaaa[m], the other issue is that nonblocking commits don't hold the locks, so they additional lock out even more
13:54 sima: if you do modesets as blocking commits I mean
13:55 sima: and they affect other crtc states
13:55 zamundaaa[m]: sima: I don't think dropped frames on other outputs when you do modesets are a big concern for desktop compositors at least
13:55 zamundaaa[m]: The situations where that is supposed to happen are situations where the user doesn't expect perfect frame pacing on other outputs anyways
13:55 sima: zamundaaa[m], yeah it's not big, but it's one of the annoyances I've heard around (nonblocking) modesets with the current uapi
13:56 emersion: it would certainly be nice to avoid
13:56 sima: and its' more that you're holding up TEST_ONLY ioctl calls too
13:57 sima: the missed frames isn't really avoidable, best we can do is make the compositor aware
13:57 zamundaaa[m]: hmm, so TEST_ONLY commits will block until the blocking modeset is complete?
13:57 sima: yeah, if they overlap in crtcs
13:58 sima: and compositors can't reasonable do nonblocking modesets with events because of all the uapi warts
13:58 zamundaaa[m]: cool, then I can go do modeset commits in a thread after all. TEST_ONLY operating on old state was my only concern regarding that
13:59 sima: and I'm not super keen on changing the locking for blocking commits because so much random semantics piled on top, imo better to make the nonblocking ones actually useable
13:59 sima: zamundaaa[m], you'd still need to wait for the thread to finish the ioctl?
14:00 zamundaaa[m]: no, I'd just send fake pageflip events from the thread when the ioctl is complete. That's what I do right now anyways, just in the main thread
14:00 sima: since the kernel doesn't tell you when it's committed the new state to software, so you can race easily
14:01 sima: zamundaaa[m], ah and the next TEST_ONLY is guaranteed to only start after the events are all received?
14:01 zamundaaa[m]: hmm, no, I misunderstood your comment about blocking commits interfering with TEST_ONLY
14:02 sima: zamundaaa[m], yeah it's just kernel internals, if you run a modeset that pulls in additional crtc
14:02 zamundaaa[m]: But the problem should be easy to avoid with a mutex
14:02 zamundaaa[m]: (in userspace)
14:02 sima: and a test_only on those additional crtc in parallel, then because locking the test_only might be held up for no good reason
14:02 swick[m]: sima: it would be amazing if KMS exposed the KMS to user space as opaque handle and we could do any kind of A->B check
14:02 sima: since these states the driver needs to adjust in the additionally affected crtc are purely internal and not visible to userspace
14:03 sima: swick[m], yeah I mean once we have fully free-standing A->B atomic check we can do a _lot_ of cool shit :-)
14:03 swick[m]: test commits on specific states while we don't have to care what the drivers current state is atm
14:03 swick[m]: sima: pls add :)
14:04 swick[m]: but yeah, that would be so clean
14:04 sima: swick[m], tell this past me roughly 10 years ago, would have been easy to add into the design back when there was no driver code yet
14:04 swick[m]: I was busy finishing school :P
14:04 kennylevinsen: sima: in absence of hindsight, have some caffeine instead - you will need it
14:05 sima: zamundaaa[m], I'm still hoping for fixing the kernel ioctl uapi, because all the pieces are there, this is a thing we can 100% fix in a driver agnostic way
14:05 sima: and the patch is probably small enough we could even backport it if we you want it much faster
14:06 zamundaaa[m]: that would be great. I could do the blocking-modeset-in-thread thing as a workaround where it's not available, but it's not a very nice solution
14:06 sima: essentially all we need is compositor folks coming up with the exact uapi that's needed
14:07 sima: since the work to track the corner cases internally in the kernel and reject them (to avoid surprises for current userspace) is all done
14:07 sima: wasn't the case with the og atomic code, and it was quite a bit of work to track events and all that stuff without relying on drivers to get all the corners right
14:08 kennylevinsen: emersion: hmm, do we actually gain much from a test_only commit that tells us about affected CRTCs? Not sure what action we'd be able to take other than going straight to blocking modeset
14:08 kennylevinsen: at least in wlroots context
14:08 emersion: kennylevinsen: wait without blocking for the page-flip on affected CRTCs
14:08 zamundaaa[m]: sima: I personally would like `PAGE_FLIP_EVENT_ON_ENABLED_CRTCS`, or a cap to disable the "userspace is broken" workaround. Either would work
14:08 emersion: continue to drive other CRTCs as usual
14:09 emersion: i think we could come up with an abstraction to wrap everything up
14:09 sima: zamundaaa[m], but what about affected_crtc?
14:09 sima: that's the bigger fun iirc
14:09 zamundaaa[m]: KWin's modesets always contain all crtcs
14:10 zamundaaa[m]: So I don't really care about that
14:10 sima: ah yeah that helps :-)
14:10 sima: zamundaaa[m], so you'd be ok with a check that bails out if affected_crtc != requested_crtc?
14:11 sima: for nonblocking modesets I mean
14:11 zamundaaa[m]: yeah
14:12 emersion: kennylevinsen: or yeah we could always include all CRTCs for simplicity at first
14:12 sima: oh we have even an unused reserved where we could stuff affected_crtc into if this flag is set
14:13 kennylevinsen: bar a new device-wide-commit API, we'd need to fail back to the compositor and let it know what to wait for for retry if we want it to remain response...
14:22 kennylevinsen: but wlroots API aside, definitely seems like having erroring out on affected_crtc != requested_crtc is a nicer UAPI than having one commit for a CRTC sporadically fail because it was implicitly included in a previous commit
14:23 sima: tzimmermann, are you sure about the various - you've proposed in your review?
14:23 kennylevinsen: assuming we get to know that it happened so we can react at least
14:24 tzimmermann: sima, you mean atomic-commit path vs. atomic commit path ?
14:24 sima: tzimmermann, yeah
14:24 sima: I thought that's very optional in English, but also no idea
14:24 tzimmermann: "atomic commit path" is a commit code path that is atomic; "atomic-commit path" is the code path of an atomic commit
14:25 sima: it's been ages I've sat in a proper grammar lesson for either german or english
14:25 tzimmermann: best to ask a native speak, though
14:26 sima: not sure it makes a difference since it's kinda both ...
14:28 tzimmermann: in your text, atomic refers to all of "commit path". but the code path itself isn't atomic. atomic-commit is a modifier for path. but really ask a native speaker.
14:28 MrCooper: so if a driver pulls additional enabled CRTCs into a commit, events are sent for those as well?
14:28 sima: MrCooper, yeah I think that was the issue
14:29 MrCooper: and user space can cope with that?
14:29 sima: if you use drm_event at least, for sync_file out-fence it's explicitly per crtc
14:29 kennylevinsen: [drm:drm_atomic_helper_setup_commit] [CRTC:51:pipe A] busy with a previous commit
14:29 kennylevinsen: yup
14:29 tzimmermann: all i can do is to memorize rules and hope to apply them correctly
14:29 MrCooper: kennylevinsen: my question is about events, not EBUSY
14:29 emersion: for the latest driver-pulls-CRTCs yikes, there is also https://lore.kernel.org/dri-devel/20231005131623.114379-1-contact@emersion.fr/
14:29 sima: MrCooper, well if it's opt-in it will have to, but to make sure my idea is that we fail the ioctl if the affected_crtc don't match what userspace requested
14:30 sima: that way we're sure userspace knows about all the crtc it'll get events on
14:30 robclark: pq, sima, fwiw the "not being able to turn it off" aspect of CTM (for qc hw) is more like "we can't move it to the other crtc if it is already doing scanout. So it's more like the first N crtc's userspace wants to use CTM get it, and after that atomic tests start failing and userspace does CTM on the gpu for those outputs
14:30 MrCooper: what I'm getting at, isn't the current behaviour just buggy, CRTCs pulled in by the driver should be ignored WRT events?
14:30 robclark: so not quite _as_ dire as you make it sound
14:30 sima: MrCooper, yeah I think for some compositors things blew up on unexpected EBUSY, because there were events in-flights the compositor had no idea about
14:31 MrCooper: my concern is about getting EINVAL with events and the driver pulling in disabled CRTCs
14:31 zamundaaa[m]: robclark: there's uAPI that allows you to move properties between CRTCs?
14:31 sima: robclark, yeah I think for ctm is should be mostly ok to guarantee you can turn it off
14:31 sima: even for malidp I think
14:31 sima: zamundaaa[m], it's about moving the resource allocations between crtc really
14:32 robclark: zamundaaa[m]: no, the issue is we dynamically move around the hw resources that back planes/crtcs (and other things that are not visible to userspace) because kms isn't as dynamic as the hw is ;-)
14:32 sima: MrCooper, yeah we'd need to lift that restriction too
14:32 robclark: (in worst case, driver can turn it "off" by programming identity matrix)
14:33 zamundaaa[m]: robclark: but why do you need to move it? In order to expose the CTM on two crtcs, don't you need to have two CTMs in the first place?
14:33 sima: MrCooper, I think the three pieces are a) EINVAL for events on disabled crtc b) affected_crtc or some way to make sure userspace doesn't stumble over unexpected events c) EBUSY (but userspace should be able to avoid that with a & b)
14:33 sima: zamundaaa[m], hw designer extremely disagree on this
14:34 robclark: so the ctm is tied to the lm (layermixer, thing that blends all the planes attached to crtc).. we can't swap those around if the one we want is already in use
14:34 zamundaaa[m]: Then the obvious solution is to only expose the CTM on one crtc, right?
14:35 MrCooper: sima: a) & b) should be solved by only considering CRTCs added by user space for anything event related
14:35 robclark: but _which_ one.. ideally we want it on the primary display (for things like laptop/tablet/etc).. but how does kernel know this.. so what we settled on is first crtc that asks for it gets it (if it is available)
14:35 zamundaaa[m]: The kernel doesn't need to know. Userspace can decide which crtc to use on which output, right?
14:35 sima: MrCooper, I guess we could do that too, but iirc some folks did complain about dropped vblanks for no reason
14:36 sima: and the kernel knows this stuff
14:36 MrCooper: zamundaaa[m]: planes can move between CRTCs as well, e.g. AMD GPUs have a single overlay plane per GPU
14:36 sima: zamundaaa[m], this gets more fun when you can have ctm on some planes but not freely reassigneable planes
14:36 sima: or a bunch more features like yuv scanout or compressed fb scanout
14:37 sima: those all tend to be assignable resources too, so if you entirely fix things up, you support a _lot_ less than what the hw can do
14:37 zamundaaa[m]: The CTM property is on the CRTC though
14:37 MrCooper: sima: yeah I see the appeal for solving c), though worst case it can be worked around by waiting for any pending flips on all CRTCs to complete
14:37 sima: there's work to add color stuff to planes, and often that's just internally shared
14:38 sima: MrCooper, it's more that the kernel knows it all, and I don't see a reason to hide it from userspace, instead more guessing games
14:38 sima: plus we need an explicit flag anyway
14:38 robclark: zamundaaa[m]: it was a long enough ago that I don't remember all the details, but we did work thru all the possible options and best one was first-come-first-served
14:38 robclark: and atomic-test fail the other cases so userspace knows to fallback to gpu
14:39 MrCooper: sima: sure, just saying this can be worked around, in contrast to a) & b)
14:39 sima: it's also generally what kms drivers do
14:39 zamundaaa[m]: sima: I know, I was involved in the design of that. The color pipelines are a better abstraction for things like this
14:39 sima: zamundaaa[m], we also have fun things like double-wide crtc
14:39 sima: where you need to internally double up everything
14:40 sima: but if your plane is small enough, you don't
14:40 sima: so pretty much any bigger driver has a _lot_ of these internal resources that are limited and get dynamically allocated until you're out
14:42 sima: MrCooper, currently for userspace to work around c) you need to do what kwin does and include all crtc all the time for modesets
14:42 sima: but then you hit the event check for disabled ones
14:42 sima: so currently not really a way out I think
14:44 kennylevinsen: yeah, in wlroots the issue is that we have no idea what we need to wait for - we do a modeset commit for CRTC A which implicitly pull in CRTC B, and when we then try to commit CRTC B not knowing we had something to wait for...
14:45 kennylevinsen: we get EBUSY, and our only current option is to fall back to blocking which makes everybody sad
14:46 kennylevinsen: If we knew what CRTCs needed to be involved we could wait for the right things, but right now it's just a black box saying no
14:48 austriancoder: karolherbst: I have done the easy sorting .. have a shortcut for this stuff in vscode .. if something like this is fine for you I will update the MR: https://tmp.christian-gmeiner.info/ordering.txt
14:49 karolherbst: austriancoder: yeah.. I think that's fine, I think it might make _some_ sense to sort SMad/UMad as Mad, but whatever
14:50 austriancoder: karolherbst: too much manual work :)
14:50 karolherbst: yeah...
14:50 MrCooper: sima: yep, exactly
14:50 pq: kennylevinsen, how often do you actually *want* to do modesets in your compositor? Do you have some automatic triggers that are not hotplug?
14:51 kennylevinsen: who doesn't like a good modeset?
14:51 kennylevinsen: no, it's hotplug, but modesetting 3 displays can take a moment when you plug in a dock
14:52 pq: they appear one by one?
14:52 MrCooper: kennylevinsen: FWIW, instead of using a blocking commit, you could also wait for any pending flips on all other CRTCs to complete, and try again; not sure that's much better though
14:53 MrCooper: hmm, and then you wouldn't know when you can flip other CRTCs again
14:53 pq: kennylevinsen, could you maybe wait e.g. 500ms since the last hotplug event before reacting?
14:54 MrCooper: so yeah, the effectively affected CRTCs definitely need to be communicated to user space
14:55 swick[m]: sima: so, can we do something right now to get everyone working in a direction that we get free-standing A->B atomic checks in the future?
14:55 kennylevinsen: pq: The issue is not timing, but that our abstraction is per-output. If you connect 3 outputs, we do 3 modesets - one for each CRTC we *thought* was affected.
14:56 kennylevinsen: *thought* because the kernel pulls in some more, so the scope of the modeset does not match our expectations
14:56 zamundaaa[m]: FWIW KWin's abstraction is also still that way, it's possible to make it work
14:57 zamundaaa[m]: I let the renderer commit the output states, and only once all outputs have a pending commit, I do the modeset for all of them at once
14:57 sima: swick[m], essentially switch everyone from $obj->state to use the get_old/new_state helpers
14:58 sima: and then rename ->state to ->_state or something to catch new users
14:58 zamundaaa[m]: kennylevinsen: Or do you have modeset test + commit as one function?
14:58 sima: past that point I have honestly no clear idea and it's just handwaving
14:58 pq: kennylevinsen, ah, so you'd need to postpone the implementation of a modeset to see how much you can coalesce.
14:58 kennylevinsen: zamundaaa[m]: ah, so when you want to modeset you basically hold back all commits? that's not a bad idea.
14:58 zamundaaa[m]: yes
14:59 sima: swick[m], note that this has kinda been going on for years by now in the background
14:59 austriancoder: karolherbst: ahh.. I am unsure.. I will just update the current patch .. and let the ordering to somebody else
14:59 swick[m]: sima: that's some good news at least!
14:59 sima: swick[m], I wouldn't be this optimistic, at the current pace we'll get there roughly around the heat death of the universe
15:00 swick[m]: sima: get it done for one driver and start doing cool new stuff with it so everyone wants it? :)
15:02 sima: swick[m], one driver means you cant do the rename to catch mistakes
15:02 sima: and generally the drivers that would benefit are the ones that are complex
15:03 sima: MrCooper, zamundaaa[m] emersion so one issue with making nonblocking modesets actually useful is that it'll probably uncover the various sync bugs drivers have with reassigning shared resources
15:03 sima: so not sure we want to fix that first or after ...
15:03 sima: (it's hard)
15:04 kennylevinsen: zamundaaa[m]: we expose a dedicated test for our wlr_output_state, but commit does a both test and commit. If wlr_output_state includes a modeset we'll do that. In my non-blocking test, it's next render that does the modeset for a particular output.
15:07 kennylevinsen: But I like the idea of just somehow stalling commits on the existing connector-oriented API for a single coalesced modeset, will have to think more about that one.
15:08 kennylevinsen: might also be key to getting us better fallback on resource issues - right now we can only reallocate the crtc that failed modeset, can't back off modifiers on other crtcs...
15:12 zamundaaa[m]: yeah if tests are also per output you may need an API break to do everything right
15:13 karolherbst: austriancoder: okay :D
16:56 gfxstrand: dcbaker: Any idea how to do 32-bit builds with a proc macro? :sweat:
16:56 dcbaker: gfxstrand: cross compiling?
16:57 dcbaker: I should be more clear, what's the situation you're thinking of?
16:57 gfxstrand: dcbaker: The problem is that proc macros need to be compiled 64-bit because they get loaded as a .so by rustc
16:58 dcbaker: So you're building for a 32-bit Linux from a 64-bit Linux, and you need to ensure that you're proc-macro is built 64bit?
16:58 gfxstrand: Yes
16:59 dcbaker: I have good news. If you set up a proper cross compile on a recent version of Meson, then Meson will force your proc-macro to be for the build machine, and thus match your compiler
17:00 dcbaker: I also have pending patches to allow subprojects for the build machine as well as subprojects for the host machine, so we will hopefully have crate support for both machines in 1.3.0
17:00 dcbaker: If you're doing the unsupported CC="gcc -m32" CXX="gcc -m32" RUSTC="rustc --target i686-linux-gnu" meson setup builddir thing, then it will likely break spectacularly
17:01 gfxstrand: Oh, I'm using a cross file
17:01 gfxstrand: And libnak_file _build32/src/nouveau/compiler/libnak_ir_proc.so ~/projects/mesa/nak
17:01 gfxstrand: _build32/src/nouveau/compiler/libnak_ir_proc.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=9c081b772a9a3e434b4750e83ae3d7256ba0f278, with debug_info, not stripped
17:02 gfxstrand:
17:02 gfxstrand: file _build32/src/nouveau/compiler/libnak_ir_proc.so ~/projects/mesa/nak
17:02 gfxstrand:
17:02 gfxstrand: _build32/src/nouveau/compiler/libnak_ir_proc.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=9c081b772a9a3e434b4750e83ae3d7256ba0f278, with debug_info, not stripped
17:02 gfxstrand:
17:02 gfxstrand:
17:02 gfxstrand:
17:02 dcbaker: Then with Meson 1.2 it will magically work. For older versions we need to make sure that the native : true keyword is set for any proc-macro crates
17:02 gfxstrand: It has rust_crate_type set to proc-macro
17:02 gfxstrand: IDK what meson version I'm on. Some frankenbranch from Xavier
17:03 dcbaker: add native : true to any targets with rust_crate_type : 'proc-macro'
17:04 gfxstrand: It gets grumpy when I do that
17:05 dcbaker: hmmmm, is the branch public yet?
17:05 gfxstrand: Okay, pulled meson/master and now I'm getting an error
17:06 gfxstrand: dcbaker: It's now complaining about libnak_ir_proc being in link_with. That's probably wrong. What am I supposed to use to specify proc macro dependencies?
17:07 dcbaker: I thought those were suppoed to be link_with........ one second
17:10 gfxstrand: Maybe that's not what it's complaining about?
17:10 gfxstrand: src/nouveau/compiler/meson.build:84:22: ERROR: Tried to mix libraries for machines build machine and host machine in target 'nak_ir_proc' This is not possible in a cross build.
17:13 dcbaker: That is what it's complaining about
17:13 dcbaker: what does meson --version say?
17:13 gfxstrand: I literally just pulled tip-of-tree
17:14 gfxstrand: 1.2.99
17:14 gfxstrand: And I switched to using rust.proc_macro() to build it
17:14 dcbaker: fun. Let me see if I can replicate that, but I need to pull a non x86_64 standard. Then I need to fix that ASAP
17:15 dcbaker: sigh, and here I thought I was going to finish writing LLVM pkg-config patches today... lol
17:15 gfxstrand: dcbaker: It's my nak/conformance branch if you want to pull it
17:15 gfxstrand: ../../meson/main/meson.py setup -Dbuildtype=debug -Dprefix=$PWD/_install -Dplatforms= -Dgallium-drivers= -Dvulkan-drivers=nouveau-experimental --cross-file=$HOME/.local/share/meson/x86.cross _build32
17:16 dcbaker: Time to do some rust cross compiling :)
17:17 gfxstrand: Everyone's favorite!
17:23 mattst88: dcbaker: LLVM pkg-config would be awesome!
17:23 mattst88: I read that llvm-config is deprecated, but I don't know what's supposed to be the replacement?
17:23 dcbaker: I saw that it's deprecated too and decided I needed to write the replacement before they decide "use cmake" is the replacement
17:24 mattst88: ugh
17:26 dcbaker: so, whenever I get it all sorted (and figure out how I'm supposed to send patches as an Intel employee), I'll tell you so you can go say "I'm google and I want this" ;)
17:27 mattst88: sounds good
17:27 mattst88: are you trying to figure out how to get someone to add you to the approved-list for contributing to llvm?
17:27 mattst88: I'm surprised you're bothering, unless upstream LLVM checks?
17:28 dcbaker: Yes
17:28 mattst88: ah, damn
17:28 dcbaker: LLVM has a CLA I think
17:30 mattst88: makes sense after all the work they've done to try to relicense
17:31 dcbaker: although their docs don't seem to have anything about it...
17:31 mattst88: (https://foundation.llvm.org/docs/relicensing_long_tail/)
17:33 mattst88: Vincent Lejeune <vljn@ovi.com> is a former mesa contributor, I think?
17:35 dcbaker: There's a few former Mesa people over there. Nicolai does a lot of LLVM work too I think
17:46 mattst88: nobled@dreamwidth.org as well
17:47 mattst88: these are from the 'LLVM relicensing - long tail' spreadsheet
17:55 cwabbott: I thought that effort was effectively dead because a former core contributor with changes all over the place refused to sign
17:55 cwabbott: there was some mailing list drama over that I think
17:56 mattst88: hmm, I really don't know. seems like they would have removed the pages from the website if it was dead
18:01 cwabbott: holding out hope, I guess?
18:01 cwabbott: it's been ages and I haven't heard them announce they'd switched
18:06 mattst88: I think they switched what license *new* code is contributed under
18:06 mattst88: and the relicensing long tail effort is about being able to remove the old license
18:07 mattst88: but I'm just getting this from that link
19:29 cwabbott: yeah, I guess so
19:29 cwabbott: I dunno how useful it is to have a mixed license like that, but... IANAL
19:53 mdnavare: sima: So my plan for now is to add a dbg_kms in i915 intel_atomic_check where it adds extra crtcs when allow modeset is not set and then at the call site so in drm_atomic_check_only if affected crtc != requested then return a -EINVAL for now
20:30 gfxstrand: dcbaker: Any ideas?
20:32 dcbaker: gfxstrand: I found another bug, which is annoying
20:33 dcbaker: I think I found a workaround for that, but will need to fix it too :/
20:34 dcbaker: It seems to work in a unit test... let me see on your branch
20:56 dcbaker: gfxstrand: I see I need to finish that work I started for allowing partial_dependency() to work with pkg-config...
20:56 dcbaker: you have /usr/lib/valgrind hardcoded :)
20:57 dcbaker: I am seeing the same build failure you are
20:58 dcbaker: Now to figure out why it's failing but our unit test is not. I have a few ideas
21:13 airlied: dcbaker: is your plan to add pkg-config to llvm itself?
21:17 mattst88: I think it must be, since he's trying to get intel to add him to their CLA
21:18 dcbaker: airlied: yes
21:19 dcbaker: I actually already have it mostly working for static linking, with some extra Meson patches to make the whole thing transparent
21:26 airlied: dcbaker: should talk to tstellard about how it might be received
21:27 airlied: there is #llvm on this server where he might be found if you haven't talked to them yet
21:27 dcbaker: I would appreciate it. If it wouldn't be received, then we need a solution that does not involve CMake, because it sounds like llvm-config is going away
21:28 airlied: I think tstellar is his nickname
21:30 dcbaker: I will give him a ping and see what he thinks, thanks
21:34 dcbaker: gfxstrand: I know what the problem is! syn is! we need build-machine subprojects. I fortunately have some patches for that!
21:34 dcbaker: this issue is that syn is being built for the host machine, and then we're trying to link it with the proc macro being built for the build machine