00:14 LaughingMan[m]: looks like the server provides two certs. one (71a6f5daed116c73b5e4428e01828ddb747dea59a3c03be2fba5109a7ed2bc98) is trusted but the other (bc94dfd0af7e6ba21186ae0226f0dd27a95755ffc1d10c5b4b2e33a503549c3c) isn't valid for the archive subdomain. doesn't result in any actual errors for me though.
03:18 kode54: holy crap, marie
03:18 kode54: https://lore.kernel.org/all/20230505144910.317943-1-matthew.auld@intel.com/
03:18 kode54: this patch made intel-compute-runtime work
03:21 kode54: never mind
03:21 kode54: it was a false alarm :[
03:39 kode54: why is XE_FENCE_INITIAL_SEQNO -127 when seqno is an unsigned type everywhere?
03:46 kode54: great
03:46 kode54: an attempt was made to catch wrapping errors
03:46 kode54: apparently it just fails right away with that seqno
04:23 kode54: apparently I don't know what's up, it's just failing its first DMA fence
07:33 sima: jani, https://lwn.net/Articles/931180/ <- should we do that in dim?
07:35 sima: we could set it for the mr generation only ...
07:38 sima: https://paste.debian.net/hidden/7ee2bcd2/ something like this?
09:01 sima: emersion, see my other reply, essentially I'm not a fan of forever adding new GETFOORESOURCE and GETFOO/SETFOO and DRM_MODE_OBJECT_FOO for every new $FOO
09:01 emersion: we don't need that
09:01 jani: sima: yeah. there's really a fair amount of stuff that a user could blow up with their local config, and we should check the config
09:01 emersion: i just the GETPROPERTIES
09:01 emersion: and nothing more
09:01 sima: also the plane:crtc:connector graph is N:M:K
09:02 sima: emersion, yeah but with enable flag to get foo nodes
09:02 emersion: ?
09:02 sima: emersion, I'm also nowhere talking about making full blown color op graphs
09:02 pq: when did danvet become sima? :-o
09:02 sima: it happens
09:03 emersion: it took me some time to realize
09:03 sima: it's all linked to the same auth'ed oftc account
09:03 sima: or should be
09:03 emersion: sima, can i update the WhosWho page, or would you rather not?
09:03 sima: hm where is that even?
09:03 emersion: https://dri.freedesktop.org/wiki/WhosWho/
09:03 sima: can do for sure
09:04 pq: realizing your identity requires explicit use of /whois, which I almost never do
09:04 sima: emersion, fixed
09:04 emersion: thx
09:05 emersion: sima, there is a generic DRM_IOCTL_MODE_OBJ_GETPROPERTIES already
09:05 emersion: and that's the only thing we need
09:06 emersion: this proposal doesn't actually touch any uAPI header, apart from adding a new DRM_MODE_OBJECT_COLOROP entry
09:07 emersion: we also do _not_ need a way to list all colorop object IDs (ala DRM_IOCTL_MODE_GETPLANERESOURCES)
09:08 emersion: and yeah, we do _not_ need GETCOLOROP
09:08 emersion: no new struct
09:18 sima: emersion, replied to you too
09:19 sima: it's essentially the exact same idea we've done for cursor/primary planes
09:20 sima: where we added a type/class to the existing thing
09:20 sima: just even more generic
09:20 sima: because I think extending kms api with properties is more flexible and more fits in with the direction we've taken since atomic
09:20 sima: but also, it's a bikeshed :-)
09:21 sima: jani, I think adding ad-hoc is probably good enough, since there's sooooo much git config can do
09:21 sima: and it's growing every release
09:29 sima: emersion, pq tbf since I seem to just have caused massive confusion maybe we need to wait another few specific object types until it's time for a kms node object
09:29 sima: we're not running out of flags anytime soon
09:32 sima: DRM_MODE_PROP_OBJECT_ENUM would still be nice, but I think we can do that without explicit nodes
09:42 sima: pq, passing back shaders would give us an excuse to use ebpf in kms :-)
09:52 emersion: sima, you replied with an internal kernel struct
09:53 emersion: please don't use internal kernel things when talking about uAPI
09:53 emersion: DRM_MODE_PROP_OBJECT_ENUM would be nice I agree
09:54 emersion: I still am strong -1 on the node object type
09:54 sima: emersion, hm why?
09:54 emersion: I don't see the point
09:54 emersion: it makes the uAPI ugly for no good reason
09:55 emersion: I'll type a reply later, I'm afk atm
09:55 sima: emersion, yeah that part is pure bikeshed
09:55 sima: the DRM_MODE_PROP_OBJECT_ENUM has some semantic meaning, and if we agree on that I'm like 90% happy at least
09:56 emersion: sorry for using the term "ugly", I shouldn't have
09:56 sima: it should be good enough to get at least a bit more type checking
09:56 sima: emersion, it's defo a bit more cumbersome for userspace to just fish out the stuff it wants
09:56 emersion: "inconsistent", " overkill" is still what i'd call it
09:56 sima: emersion, so the reason I thought of it was the mention of the scaler node
09:56 sima: we might get more stuff, like a crc tap
09:56 sima: or a histogram tap
09:56 emersion: we don't need nodes when we can represent them with props
09:57 sima: or maybe funk blending modes
09:57 sima: but I guess we can handle those the same way we do now: explicit op-in flags
09:57 sima: and the kernel appropriately filters everything to present to userspace only the nodes/links it understands
09:58 sima: like we currently filter plane types and writeback connectors (although filtering the links there is much easier than pulling a crc tap node out of the middle of the plane color pipeline, but all doable)
09:59 sima: so I guess I also get a price for failing to explain my motivation :-/
09:59 sima: emersion, the scaler might grow some props to control how it scales
10:00 sima: like pixel-art upscaling vs linear vs bilinear vs "here's you NxM tap matrix"
10:00 sima: so I'd expect that we'll get full-blown scaler nodes too
10:01 sima: the nodes also would be a really neat way to express were exactly the various crc tap points are that debugfs can expose
10:01 sima: plus adaptive backlight needs histogram output or you can't
10:06 sima: pq, ^^ maybe this explains why I even brought this all up
10:32 pq: sima, the scaler element is *already* a full-blown element - it just didn't have anything to configure at first.
10:33 sima: pq, I guess I missunderstood what emersion a bit further up with meant with "we don't need nodes when we can represent them with props"
10:33 pq: sima, all the "branch-off nodes" you mentioned so far are all leaf nodes. Therefore they won't have any elements after them, so they don't actually need to be branches at all.
10:33 sima: I thought that was about the scaler node
10:33 pq: I have no idea what you were talking about there.
10:33 sima: pq, hm my idea was to put them all in-line
10:33 pq: yes
10:34 sima: but I guess we could put them out-of-line with different "crc" or "histogram" object pointers
10:34 sima: kinda like the plane has the color-pipeline prop
10:34 pq: they can be inline in the pipeline, they just don't branch off like graph, but act as no-op elements.
10:34 sima: pq, yeah that's what I meant
10:35 pq: so there is nothing to add to the design to do that, just the actual element types.
10:35 sima: I really don't argue for a full blown graph, just a touch more generic node object type so we can extend more later
10:35 sima: but we can also extend more later the same way we've added more stuff thus far
10:35 sima: pq, ah then you missed a piece
10:35 pq: I have no idea what DRM_MODE_PROP_OBJECT_ENUM is about, and I think it's irrelevant to me.
10:35 sima: my idea was that kernel would guarantee that userspace can safely skip any class it doesn't understand
10:36 pq: no
10:36 sima: but within a class like colorop it must understand all elements or things go wrong
10:36 sima: so adding crc or histogram tap points as a different type would not convey enough meaning
10:36 sima: and we'd need to again filter them like we do now when we add new things
10:36 pq: I thought a crc elements *is* a COLOROP object?
10:36 sima: nope
10:36 sima: making it a colorop object would defeat the point
10:37 pq: oookay
10:37 sima: it would break uapi because suddenly the compositor has a thing in the middle it doesn't understand
10:37 sima: so we _have_ to filter it out
10:37 sima: like we currently filter out planes that userspace doesn't understand
10:37 sima: or writeback connectors
10:37 sima: the idea of nodes was that you'd get them all in GETRESOURCES or when walking a color pipeline
10:38 sima: but by using the class property (_not_ the type property within the colorop class)
10:38 pq: it seems like it would be much better is a crc-element *is* a COLOROP object with "type"="bypass" property. Then userspace knows it does not need to undertand any furhter.
10:38 sima: userspace would know what it could safely skip (i.e. what's safe to add for new features) and what it must understand
10:38 sima: pq, that feels really funky to me
10:38 pq: it's much simpler and streamlined than a mess of nodes
10:39 sima: we'd end up with a really_the_type_I_mean="crc" or so
10:39 sima: pq, it's exactly the same list of nodes
10:39 sima: so the mess should be 100% equivalent
10:39 pq: "crc" could be an alternative value to the element "type" so crc can be toggled on/off
10:39 sima: hm
10:40 pq: just like all other elements emersion already mentioned
10:40 sima: ok I guess that would need to be put down into the uapi spec that anything with "bypass" can be set to that and userspace can ignore it
10:40 pq: I thought that's obvious.
10:40 sima: if you don't spec it
10:40 sima: or if a compositor fails to implement it
10:40 pq: "type" is an enum, and if "bypass" is an allowed value, then what else could it mean?
10:41 sima: then no, it'd be an uapi breakage if we add something
10:42 sima: pq, it's not so much what it means, but what's less likely to result in compositors getting confused and failing to use the hw color pipeline just because we added something
10:42 sima: if we say "there's potentially random gunk in the pipeline, you must filter on class=="ColorOp" I think we have better chances
10:42 pq: if you worry about that, add another pipeline
10:42 sima: than "you need to handle arbitrary stuff with type=bypass
10:43 sima: hm yeah that might work too
10:43 sima: probably what we have to do
10:43 sima: at least in the uapi, the driver could just expose one and we do a few filtered versions automatically as compat
10:43 pq: sima, filter on this, or filter on that, I see no difference. But I do see a difference between one-level and two-level type systems.
10:43 sima: my point is kinda it's two-level either way
10:44 pq: it's not
10:44 sima: like once you add something that breaks an existing compositor it has to be two-level
10:44 sima: because you need to hide that stuff from the old compositors
10:44 pq: don't do that
10:44 sima: it breaks it you don't?
10:45 sima: like the alternate pipelines are just very convoluted way to make the 2 level classes work
10:45 sima: thus far we just filtered stuff out with flags
10:45 sima: e.g. planes are also two-level for exactly this reason
10:45 pq: yeah, so we already have two ways to avoid breaking old compositors: don't modify existing pipelines, and offer "type"="bypass" option.
10:45 sima: same for connectors
10:46 sima: all I kinda threw in is to make this a bit more explicit
10:46 pq: bypass has to be there *anyway* so why invent another redundant type level on top?
10:46 sima: I expect people to get it wrong :-)
10:47 sima: we have enough amusement with compositors doing funny stuff that that's a fairly safe assumption
10:47 pq: I expect people to accidentally design UAPI wrong, but you are very much against that too. *shrug*
10:47 sima: I'm not sure whether explicit two-level would actually help though
10:47 pq: I don't understand what we're arguing about.
10:48 sima: the "wrong uapi" we can try to prevent, because there's only one canonical upstream
10:48 pq: it won't help, it's just another level to get things wrong
10:48 sima: (excluding vendors doing absolute hilarious stuff in their downstream trees)
10:48 sima: preventing wrong compositors has been fairly hopeless historically
10:48 pq: no, it just means we never release any UAPI
10:49 sima: so expecting that type=bypass will allow us to add stuff I don't buy, we'll have to filter in-kernel
10:49 sima: either with alternate kernels or explicit opt-in
10:49 pq: ok, that sentence I can understand, and I disagree, but ok then.
10:50 pq: we just add more pipelines to pick from.
10:50 sima: well that's a way of filtering imo
10:50 sima: but yeah I think the node bikeshed is probably for the dumpster pile :-)
10:50 pq: no, no filtering, just add new pipelines to everyone
10:50 sima: the DRM_MODE_PROP_OBJECT_ENUM I think would be good to keep
10:51 sima: pq, well it's the old pipeline as a filtered version of the new one, could even generate that one programatically in drm core code
10:51 sima: which I expect is how we'd implement this because doing it by hand is not going to be consistent enough
10:51 sima: but yeah in the uapi it's just more pipelines
10:52 pq: ...I could have not guessed at all that you meant the *old* pipeline is a filtered pipeline. That's not how userspace sees things.
10:52 pq: I'm also not sure you want to automate generating "old" pipelines from new ones, but that's kernel internal, so I don't care the least.
10:54 pq: At least it's easy to have CI checks to ensure old pipelines keep on being advertised like they used to be.
10:55 pq: maybe we need VKMS to add ramdom COLOROP nodes with "type"="bypass" and require that userspace passes that test.
10:56 sima: pq, it's how we've done all the obj extensions thus far, we outright hide them
10:56 sima: pq, yeah that might work to keep bypass functional like you plan to
10:56 sima: *functional for forward compat
10:56 pq: for NVIDIA hardware support for bypass is a must already
10:57 pq: they have elements that do special things no-one else does
10:58 pq: and tbh I expect all hardware vendors to have some elements no-one else has
10:59 pq: you could even insert random bypass elements for actual hw drivers, too
11:04 dolphin: airlied: did a rebase of the topic/core-for-CI
11:09 pq: sima, it sounds a bit like you are intentionally trying to design some artificial kernel-internal structures so that there would be some kernel-internal work to do before actual UAPI. Like a framework for a single use case that doesn't need it. - from your email 2h ago
11:10 pq: sima, I'll let you reply to it if you got some new conclusions from IRC.
11:15 pq: sima, I guess you are now me from the virtualized cursor plane discussion.
11:15 sima: pq, yeah that was a bit the idea, essentially a case of "maybe this is what it should have looked like from the start"
11:16 sima: pq, the key bit really is the DRM_MODE_PROP_OBJECT_ENUM though, everything else doesn't matter from uapi pov I think
11:16 sima: so instead of object class + separate possible_$type mask
11:16 sima: do what you have in the proposal as an explicit enum
11:16 sima: but with the additional semantic meaning that it really has to be a kms obj and not just a random integer value
11:16 pq: there are no masks...
11:17 pq: or even options
11:17 sima: pq, the existing graph links are all constraint with masks
11:17 sima: possible_crtcs in plane and connector
11:17 pq: no, they're not. They are just single, immutable, links.
11:18 pq: If you want to re-design absolutely everything, then ok, but I don't think people are going to wait for it.
11:19 sima: pq, since when is CRTC_ID immutable on a plane or connector?
11:19 sima: it's exactly the same as your color pipeline selector
11:19 pq: I'm talking about those at all.
11:20 pq: I'm not looking to change those at all.
11:20 sima: except the explicit enume is a lot better uapi than the stuff we have right now
11:20 sima: pq, we can't
11:20 sima: but we can do better going forward
11:20 sima: which is what I'm trying to argue for
11:21 sima: make this entire kms graph node/link business just a notch more semantically meaningful
11:21 sima: instead of ad-hoc everywhere like we've done thus far and caused quite some confusion
11:21 pq: maybe write the UAPI docs for what you are imagining?
11:21 sima: see mail to emmersion, but I guess I can do a bit more detail
11:22 pq: I've read all the email, and there is no UAPI doc patch.
11:22 sima: (yes it's internals mixed up in there because I wanted to show that I really don't want to make the links a part like what emersion wrote)
11:22 pq: nothign that even resembles UAPI doc
11:22 sima: yeah I'll type that up I guess
11:22 pq: and UAPI header to go with it would be nice, kernel internals are absolutely uninteresting
11:50 sima: I need the header otherwise I can't attach the kerneldoc :-)
12:11 sima: emersion, pq while I'm looking around for the right place to type the uapi proposal (and filling gaps)
12:11 sima: ... what's the interaction of these new objs with drm leases?
12:12 sima: entirely forgot about this myself too :-/
12:12 swick[m]: mh, the links between COLOROP objects are just numbers but they also are immutable. selecting the pipeline on a plane are links to COLOROP objects but mutable... so I guess for the later you want this new DRM_MODE_PROP_OBJECT_ENUM
12:13 pq: right, would not want lessee to have access to change lessor's colorop parameters.
12:14 swick[m]: leasing a plane should probably lease out all the possible pipelines as well
12:14 pq: seems simple enough in that case: expose all colorobjs that are reachable from the leased plane/crtc objects.
12:15 swick[m]: indeed
12:15 pq: colorop objects are never used in two pipelines
12:15 pq: even if they would refer to the same hardware block in multiple pipelines
12:16 pq: that's another reason why I don't really understand what kernel internal state tracking infrastructure would be needed
12:16 sima: pq, yeah I think the fix is simple, just something I realized
12:16 pq: good to realize :-)
12:17 sima:was reading set/get_prop ioctl code to be able to document it correctly :-)
12:18 pq: unrelated colorop objects would never be advertised to lessees anyway, but just in case the lessee goes fishing by guessing IDs
12:19 sima: yeah kms id space is extremely predictable
12:19 sima: so not much fishing required
12:25 swick[m]: reading the backlog, I'm with pq. User space figuring out that it can skip elements which can be set to bypass is one of the least hard problems it has to solve when mapping its pipeline onto a KMS color pipeline...
12:27 pq: indeed
13:11 mlankhorst: tjaalton: Hey, what's igt used for inside ubuntu?
13:21 Company: jadahl, swick[m]: I'm looking at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14#note_1899436 from a client perspective
13:22 jadahl: Company: perhaps a #wayland topic?
13:22 Company: like, if GTK was given a random icc profile (from a fullscreen gstreamer say) and wanted to pass it on, it seems suboptimal if stuff doesn't show up on screen
13:22 Company: oh right
13:23 Company:reposts
13:47 tjaalton: mlankhorst: dunno, why?
16:26 alyssa: gfxstrand: First day! :-D
16:26 alyssa: Trying to compile a "NIR maintenance" todo list
16:26 alyssa: I assume you will want to fill it out :p
16:38 ccr: alyssa, I am shocked that paparazzo zmike's SGC blog has not yet revealed the news about your new position
16:39 alyssa: ccr: I wonder
16:39 ccr: :)
16:40 zmike: I don't post news for other people unless they don't have blogs
16:40 alyssa: it's not news it's gossip
16:40 alyssa: the world must know about my new gig on Taco Bell's graphics team
16:41 zmike: TBGT is supposed to be secret until june...
16:49 ccr: !
16:49 ccr: accelerated fast food rendering
16:55 MrCooper: TIL RT stands for Rendered Tacos
17:17 jenatali: RTRTRT: real-time raytraced rendered tacos
19:21 anholt_: NIR folks, I'd like input on naming in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22809. would like to repaint the shed once hopefully.
19:26 alyssa: ooh I love NIR bikesheds
19:28 alyssa: anholt_: +1 on kusma's suggestion of nir_get_variable_with_location
19:28 alyssa: but also I don't care and am find with nir_get_slot_var
19:28 alyssa: *fine
19:29 alyssa: gfxstrand: working on an MR I think you'll like
20:06 alyssa: gfxstrand: https://gitlab.freedesktop.org/alyssa/mesa/-/commit/4f2ac0dc6628de61bec69517cb1e55ac4adb84ad
20:06 alyssa: Example: https://gitlab.freedesktop.org/alyssa/mesa/-/commit/2c0a1f0c7274cf5ac7cab2028f2986cac4bbfe43
20:06 alyssa: this is exactly what AGX wants
20:07 alyssa: it's not quite what Bifrost wants but still a net improvement
20:07 alyssa: not inclined to convert every backend until we agree that we want to move in the direction of unified atomics
20:07 alyssa: but, if we're in agreement, I have a coherent plan on how to get there that's not "10000 line flag day commit yeet!"
20:08 alyssa: namely
20:08 alyssa: 1. add unified intrinsics coexisting with the current stuff
20:08 alyssa: 2. add a pass to convert current intrinsics to unified ones
20:08 alyssa: 3. convert drivers one at a time to ingest unified intrinsics (opting in by calling the pass)
20:08 alyssa: ...
20:08 alyssa: 4. now that all drivers are opted in, convert producers one at a time to produce unified intrinsics
20:09 alyssa: ...
20:09 alyssa: 5. now that only unified atomics are used, the pass is dead. delete all its callers (a single line deleted from each driver, possibly just a sed), delete the pass, and delete the old intrinsics
20:10 jenatali: I like it
20:10 alyssa: thanks :)
20:11 alyssa: Anyway, for this MR, I aim to do 1, 2, and a representative sample of 3 (convert enough drivers to establish the concept is viable and give lots of examples for other people to convert their drivers)
20:11 alyssa: then hopefully nerdsnipe a bunch of backend maintainers to write the easy patch for their backends in parallel
20:12 jenatali: The DXIL change would be straightforward
20:12 alyssa: yeah, it's straightforward for all backends
20:12 alyssa: I think
20:12 alyssa: but not fully mechanical
20:13 alyssa: This is obviously a lot more code than the helper you added for NAK, but converting drivers to that helper doesn't get us much closer to switching to new style atomics
20:13 alyssa: (since you'd still need a nontrivial flag day at some point even if all drivers use it)
20:14 dj-death: alyssa: I think some of the work Kayden did recently matches pretty well with your plan
20:14 alyssa: dj-death: eh?
20:14 dj-death: alyssa: we already put the ALU op in our backend as a sources
20:14 alyssa: OK
20:15 alyssa: (This is in response to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22724 fwiw, which includes an intel patch)
20:15 dj-death: alyssa: yeah I've seen that
20:16 dj-death: alyssa: but as you can see that would be rewriting 1/2 switch statements for anv
20:16 dj-death: I mean anv/iris/etc...
20:17 alyssa: right.. the helper makes things a little less awkward for the backend but doesn't actually fix the problem
20:17 alyssa: if we're all on board with the direction of unified intrinsics, I'll send out the MR tomorrow (with Mali and AGX converted)
20:24 alyssa: (and ACO and ir3 since I guess I care about those now o:)
22:26 alyssa: oh, oof, NIR's existing atomics match what ACO does
22:26 alyssa: (and I guess AMD hw)
22:26 alyssa: so nothing really saved for ACO from unifying them
22:26 alyssa: though it's probably not any harder. let's find out.
22:28 alyssa: and ACO also handles these funny inc_wrap thing
22:29 alyssa: that's for images only apparently. uff.
22:29 alyssa: don't @ me but why do we have that in NIR at all? why not just add with 1?
22:30 alyssa: Who is even producing these?
22:31 alyssa: Seemingly glsl-to-nir but not vtn
22:32 alyssa: uff. weirdo GL thing
22:34 alyssa: Well. still "just" ALU
22:35 alyssa: what's not clear to me is why only a few hardware supports that
22:35 alyssa: it seems to be for EXT_shader_image_load_store
22:35 alyssa: oh but that's not the ext that people use, gated on a CAP
22:36 alyssa: Fine, whatever, sure
22:52 alyssa: Some of these backends are harder to convert, uff
22:56 alyssa: llvmpipe, you're up
22:56 alyssa: well, lp_bld_nir
22:56 alyssa: guess I am working on lavapipe today :-D
22:57 jenatali: Can I get a nir reviewer to take a look at the first patch of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22787 ?
22:58 alyssa: oh hey that's me
22:59 jenatali: I debated just pinging you directly :P
23:00 alyssa: jenatali: Lol
23:00 alyssa: +1 on the commit message
23:00 alyssa: Do you really want a mesa set?
23:01 jenatali: What else would I want?
23:02 jenatali: I guess I could've gone for a bitset based on block index?
23:03 alyssa: Oh I mean shrug
23:03 alyssa: I've never seen a block with more than, like, 3 predecessors in practice :p
23:04 jenatali: Yeah I'm not really sure how you can get more, but it's possible
23:04 alyssa: loop with many breaks/continues
23:04 alyssa: the loop header has arbitrarily many predecessors
23:06 jenatali: Right
23:18 jenatali: So yeah, could do the O(n*m) search, or switch to a bitset, but since this only does anything in places where validation would fail today, I'm not worried about the allocation overhead from the set, and I'd rather not rework it if that's the only complaint :P
23:25 alyssa: :D
23:38 jenatali: Ok that needs more investigation, thanks for questioning me :)
23:38 jenatali: I'll split that MR and land just the dzn bits then
23:39 alyssa: +1
23:49 alyssa:deletes a chunk of llvmpipe
23:50 HdkR: :O
23:58 alyssa: 3 files changed, 54 insertions(+), 230 deletions(-)