ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
LaughingMan[m] has joined #dri-devel
<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.
psykose has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
pochu has joined #dri-devel
pcercuei has joined #dri-devel
Haaninjo has joined #dri-devel
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
Zopolis4 has quit [Quit: Connection closed for inactivity]
sgruszka has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
bmodem has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
sadhu has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
cmichael has joined #dri-devel
<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
<emersion>
we don't need that
<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
<emersion>
i just the GETPROPERTIES
<emersion>
and nothing more
<sima>
also the plane:crtc:connector graph is N:M:K
<sima>
emersion, yeah but with enable flag to get foo nodes
<emersion>
?
<sima>
emersion, I'm also nowhere talking about making full blown color op graphs
<pq>
when did danvet become sima? :-o
<sima>
it happens
<emersion>
it took me some time to realize
<sima>
it's all linked to the same auth'ed oftc account
<sima>
or should be
<emersion>
sima, can i update the WhosWho page, or would you rather not?
<pq>
realizing your identity requires explicit use of /whois, which I almost never do
<sima>
emersion, fixed
<emersion>
thx
rasterman has joined #dri-devel
<emersion>
sima, there is a generic DRM_IOCTL_MODE_OBJ_GETPROPERTIES already
<emersion>
and that's the only thing we need
<emersion>
this proposal doesn't actually touch any uAPI header, apart from adding a new DRM_MODE_OBJECT_COLOROP entry
<emersion>
we also do _not_ need a way to list all colorop object IDs (ala DRM_IOCTL_MODE_GETPLANERESOURCES)
<emersion>
and yeah, we do _not_ need GETCOLOROP
<emersion>
no new struct
Namarrgon has joined #dri-devel
<sima>
emersion, replied to you too
<sima>
it's essentially the exact same idea we've done for cursor/primary planes
<sima>
where we added a type/class to the existing thing
<sima>
just even more generic
<sima>
because I think extending kms api with properties is more flexible and more fits in with the direction we've taken since atomic
<sima>
but also, it's a bikeshed :-)
<sima>
jani, I think adding ad-hoc is probably good enough, since there's sooooo much git config can do
<sima>
and it's growing every release
<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
<sima>
we're not running out of flags anytime soon
<sima>
DRM_MODE_PROP_OBJECT_ENUM would still be nice, but I think we can do that without explicit nodes
<sima>
pq, passing back shaders would give us an excuse to use ebpf in kms :-)
<emersion>
sima, you replied with an internal kernel struct
<emersion>
please don't use internal kernel things when talking about uAPI
<emersion>
DRM_MODE_PROP_OBJECT_ENUM would be nice I agree
<emersion>
I still am strong -1 on the node object type
<sima>
emersion, hm why?
Mangix has quit [Read error: Connection reset by peer]
<emersion>
I don't see the point
Mangix has joined #dri-devel
<emersion>
it makes the uAPI ugly for no good reason
<emersion>
I'll type a reply later, I'm afk atm
jkrzyszt has joined #dri-devel
<sima>
emersion, yeah that part is pure bikeshed
junaid has quit [Ping timeout: 480 seconds]
<sima>
the DRM_MODE_PROP_OBJECT_ENUM has some semantic meaning, and if we agree on that I'm like 90% happy at least
<emersion>
sorry for using the term "ugly", I shouldn't have
<sima>
it should be good enough to get at least a bit more type checking
<sima>
emersion, it's defo a bit more cumbersome for userspace to just fish out the stuff it wants
<emersion>
"inconsistent", " overkill" is still what i'd call it
<sima>
emersion, so the reason I thought of it was the mention of the scaler node
<sima>
we might get more stuff, like a crc tap
<sima>
or a histogram tap
<emersion>
we don't need nodes when we can represent them with props
<sima>
or maybe funk blending modes
<sima>
but I guess we can handle those the same way we do now: explicit op-in flags
<sima>
and the kernel appropriately filters everything to present to userspace only the nodes/links it understands
<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)
<sima>
so I guess I also get a price for failing to explain my motivation :-/
<sima>
emersion, the scaler might grow some props to control how it scales
<sima>
like pixel-art upscaling vs linear vs bilinear vs "here's you NxM tap matrix"
<sima>
so I'd expect that we'll get full-blown scaler nodes too
<sima>
the nodes also would be a really neat way to express were exactly the various crc tap points are that debugfs can expose
<sima>
plus adaptive backlight needs histogram output or you can't
<sima>
pq, ^^ maybe this explains why I even brought this all up
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
pochu_ has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
<pq>
sima, the scaler element is *already* a full-blown element - it just didn't have anything to configure at first.
<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"
<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.
<sima>
I thought that was about the scaler node
gouchi has joined #dri-devel
<pq>
I have no idea what you were talking about there.
<sima>
pq, hm my idea was to put them all in-line
<pq>
yes
<sima>
but I guess we could put them out-of-line with different "crc" or "histogram" object pointers
<sima>
kinda like the plane has the color-pipeline prop
<pq>
they can be inline in the pipeline, they just don't branch off like graph, but act as no-op elements.
<sima>
pq, yeah that's what I meant
<pq>
so there is nothing to add to the design to do that, just the actual element types.
<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
<sima>
but we can also extend more later the same way we've added more stuff thus far
<sima>
pq, ah then you missed a piece
<pq>
I have no idea what DRM_MODE_PROP_OBJECT_ENUM is about, and I think it's irrelevant to me.
<sima>
my idea was that kernel would guarantee that userspace can safely skip any class it doesn't understand
<pq>
no
<sima>
but within a class like colorop it must understand all elements or things go wrong
<sima>
so adding crc or histogram tap points as a different type would not convey enough meaning
<sima>
and we'd need to again filter them like we do now when we add new things
<pq>
I thought a crc elements *is* a COLOROP object?
<sima>
nope
<sima>
making it a colorop object would defeat the point
<pq>
oookay
<sima>
it would break uapi because suddenly the compositor has a thing in the middle it doesn't understand
<sima>
so we _have_ to filter it out
<sima>
like we currently filter out planes that userspace doesn't understand
<sima>
or writeback connectors
<sima>
the idea of nodes was that you'd get them all in GETRESOURCES or when walking a color pipeline
<sima>
but by using the class property (_not_ the type property within the colorop class)
<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.
<sima>
userspace would know what it could safely skip (i.e. what's safe to add for new features) and what it must understand
<sima>
pq, that feels really funky to me
<pq>
it's much simpler and streamlined than a mess of nodes
<sima>
we'd end up with a really_the_type_I_mean="crc" or so
<sima>
pq, it's exactly the same list of nodes
<sima>
so the mess should be 100% equivalent
<pq>
"crc" could be an alternative value to the element "type" so crc can be toggled on/off
<sima>
hm
<pq>
just like all other elements emersion already mentioned
<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
<pq>
I thought that's obvious.
<sima>
if you don't spec it
<sima>
or if a compositor fails to implement it
<pq>
"type" is an enum, and if "bypass" is an allowed value, then what else could it mean?
<sima>
then no, it'd be an uapi breakage if we add something
<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
<sima>
if we say "there's potentially random gunk in the pipeline, you must filter on class=="ColorOp" I think we have better chances
<pq>
if you worry about that, add another pipeline
<sima>
than "you need to handle arbitrary stuff with type=bypass
<sima>
hm yeah that might work too
<sima>
probably what we have to do
<sima>
at least in the uapi, the driver could just expose one and we do a few filtered versions automatically as compat
<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.
<sima>
my point is kinda it's two-level either way
<pq>
it's not
<sima>
like once you add something that breaks an existing compositor it has to be two-level
<sima>
because you need to hide that stuff from the old compositors
<pq>
don't do that
<sima>
it breaks it you don't?
<sima>
like the alternate pipelines are just very convoluted way to make the 2 level classes work
<sima>
thus far we just filtered stuff out with flags
<sima>
e.g. planes are also two-level for exactly this reason
<pq>
yeah, so we already have two ways to avoid breaking old compositors: don't modify existing pipelines, and offer "type"="bypass" option.
<sima>
same for connectors
<sima>
all I kinda threw in is to make this a bit more explicit
<pq>
bypass has to be there *anyway* so why invent another redundant type level on top?
<sima>
I expect people to get it wrong :-)
rasterman has quit [Quit: Gettin' stinky!]
<sima>
we have enough amusement with compositors doing funny stuff that that's a fairly safe assumption
<pq>
I expect people to accidentally design UAPI wrong, but you are very much against that too. *shrug*
<sima>
I'm not sure whether explicit two-level would actually help though
<pq>
I don't understand what we're arguing about.
<sima>
the "wrong uapi" we can try to prevent, because there's only one canonical upstream
<pq>
it won't help, it's just another level to get things wrong
<sima>
(excluding vendors doing absolute hilarious stuff in their downstream trees)
<sima>
preventing wrong compositors has been fairly hopeless historically
<pq>
no, it just means we never release any UAPI
<sima>
so expecting that type=bypass will allow us to add stuff I don't buy, we'll have to filter in-kernel
<sima>
either with alternate kernels or explicit opt-in
<pq>
ok, that sentence I can understand, and I disagree, but ok then.
<pq>
we just add more pipelines to pick from.
<sima>
well that's a way of filtering imo
<sima>
but yeah I think the node bikeshed is probably for the dumpster pile :-)
<pq>
no, no filtering, just add new pipelines to everyone
<sima>
the DRM_MODE_PROP_OBJECT_ENUM I think would be good to keep
<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
<sima>
which I expect is how we'd implement this because doing it by hand is not going to be consistent enough
<sima>
but yeah in the uapi it's just more pipelines
<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.
<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.
cmichael has quit [Quit: Leaving]
<pq>
At least it's easy to have CI checks to ensure old pipelines keep on being advertised like they used to be.
cmichael has joined #dri-devel
<pq>
maybe we need VKMS to add ramdom COLOROP nodes with "type"="bypass" and require that userspace passes that test.
<sima>
pq, it's how we've done all the obj extensions thus far, we outright hide them
<sima>
pq, yeah that might work to keep bypass functional like you plan to
<sima>
*functional for forward compat
<pq>
for NVIDIA hardware support for bypass is a must already
<pq>
they have elements that do special things no-one else does
<pq>
and tbh I expect all hardware vendors to have some elements no-one else has
<pq>
you could even insert random bypass elements for actual hw drivers, too
<dolphin>
airlied: did a rebase of the topic/core-for-CI
<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
pochu_ has quit []
pochu has joined #dri-devel
<pq>
sima, I'll let you reply to it if you got some new conclusions from IRC.
gouchi has quit [Remote host closed the connection]
<pq>
sima, I guess you are now me from the virtualized cursor plane discussion.
<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"
<sima>
pq, the key bit really is the DRM_MODE_PROP_OBJECT_ENUM though, everything else doesn't matter from uapi pov I think
<sima>
so instead of object class + separate possible_$type mask
<sima>
do what you have in the proposal as an explicit enum
<sima>
but with the additional semantic meaning that it really has to be a kms obj and not just a random integer value
<pq>
there are no masks...
<pq>
or even options
<sima>
pq, the existing graph links are all constraint with masks
<sima>
possible_crtcs in plane and connector
<pq>
no, they're not. They are just single, immutable, links.
<pq>
If you want to re-design absolutely everything, then ok, but I don't think people are going to wait for it.
<sima>
pq, since when is CRTC_ID immutable on a plane or connector?
<sima>
it's exactly the same as your color pipeline selector
<pq>
I'm talking about those at all.
<pq>
I'm not looking to change those at all.
<sima>
except the explicit enume is a lot better uapi than the stuff we have right now
<sima>
pq, we can't
<sima>
but we can do better going forward
<sima>
which is what I'm trying to argue for
<sima>
make this entire kms graph node/link business just a notch more semantically meaningful
<sima>
instead of ad-hoc everywhere like we've done thus far and caused quite some confusion
<pq>
maybe write the UAPI docs for what you are imagining?
<sima>
see mail to emmersion, but I guess I can do a bit more detail
<pq>
I've read all the email, and there is no UAPI doc patch.
<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)
<pq>
nothign that even resembles UAPI doc
<sima>
yeah I'll type that up I guess
<pq>
and UAPI header to go with it would be nice, kernel internals are absolutely uninteresting
<sima>
I need the header otherwise I can't attach the kerneldoc :-)
psykose has joined #dri-devel
aravind has joined #dri-devel
psykose has quit [Remote host closed the connection]
<sima>
emersion, pq while I'm looking around for the right place to type the uapi proposal (and filling gaps)
<sima>
... what's the interaction of these new objs with drm leases?
<sima>
entirely forgot about this myself too :-/
<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
<pq>
right, would not want lessee to have access to change lessor's colorop parameters.
<swick[m]>
leasing a plane should probably lease out all the possible pipelines as well
<pq>
seems simple enough in that case: expose all colorobjs that are reachable from the leased plane/crtc objects.
<swick[m]>
indeed
<pq>
colorop objects are never used in two pipelines
<pq>
even if they would refer to the same hardware block in multiple pipelines
<pq>
that's another reason why I don't really understand what kernel internal state tracking infrastructure would be needed
<sima>
pq, yeah I think the fix is simple, just something I realized
<pq>
good to realize :-)
* sima
was reading set/get_prop ioctl code to be able to document it correctly :-)
itoral has quit [Remote host closed the connection]
<pq>
unrelated colorop objects would never be advertised to lessees anyway, but just in case the lessee goes fishing by guessing IDs
<sima>
yeah kms id space is extremely predictable
<sima>
so not much fishing required
<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...
<pq>
indeed
heat_ has joined #dri-devel
mbrost has joined #dri-devel
Danct12 has quit [Quit: WeeChat 3.8]
sadhu has quit [Quit: Leaving]
mbrost_ has joined #dri-devel
mbrost__ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
<mlankhorst>
tjaalton: Hey, what's igt used for inside ubuntu?
<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
<Company>
oh right
pundir has joined #dri-devel
* Company
reposts
mdroper has joined #dri-devel
jewins has joined #dri-devel
heat_ has quit []
heat has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
<tjaalton>
mlankhorst: dunno, why?
mbrost has quit [Ping timeout: 480 seconds]
mattrope_ has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
kzd has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
stuarts has joined #dri-devel
fxkamd has joined #dri-devel
gouchi has joined #dri-devel
frieder has quit [Remote host closed the connection]
kts has joined #dri-devel
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
glennk has quit []
glennk has joined #dri-devel
mattrope_ has quit []
mszyprow has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
bgs has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
cmichael has quit [Quit: Leaving]
Kwiboo- has quit [Quit: .]
Kwiboo has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
gfxstrand: First day! :-D
<alyssa>
Trying to compile a "NIR maintenance" todo list
<alyssa>
I assume you will want to fill it out :p
fxkamd has quit []
<ccr>
alyssa, I am shocked that paparazzo zmike's SGC blog has not yet revealed the news about your new position
kts has quit [Quit: Konversation terminated!]
<alyssa>
ccr: I wonder
<ccr>
:)
<zmike>
I don't post news for other people unless they don't have blogs
<alyssa>
it's not news it's gossip
<alyssa>
the world must know about my new gig on Taco Bell's graphics team
<zmike>
TBGT is supposed to be secret until june...
<alyssa>
it's not quite what Bifrost wants but still a net improvement
<alyssa>
not inclined to convert every backend until we agree that we want to move in the direction of unified atomics
<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!"
<alyssa>
namely
<alyssa>
1. add unified intrinsics coexisting with the current stuff
<alyssa>
2. add a pass to convert current intrinsics to unified ones
<alyssa>
3. convert drivers one at a time to ingest unified intrinsics (opting in by calling the pass)
<alyssa>
...
<alyssa>
4. now that all drivers are opted in, convert producers one at a time to produce unified intrinsics
<alyssa>
...
<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
<jenatali>
I like it
elongbug has quit [Read error: Connection reset by peer]
<alyssa>
thanks :)
<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)
<alyssa>
then hopefully nerdsnipe a bunch of backend maintainers to write the easy patch for their backends in parallel
elongbug has joined #dri-devel
<jenatali>
The DXIL change would be straightforward
<alyssa>
yeah, it's straightforward for all backends
<alyssa>
I think
<alyssa>
but not fully mechanical
<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
<alyssa>
(since you'd still need a nontrivial flag day at some point even if all drivers use it)
<dj-death>
alyssa: I think some of the work Kayden did recently matches pretty well with your plan
<alyssa>
dj-death: eh?
<dj-death>
alyssa: we already put the ALU op in our backend as a sources
<jenatali>
I guess I could've gone for a bitset based on block index?
<alyssa>
Oh I mean shrug
<alyssa>
I've never seen a block with more than, like, 3 predecessors in practice :p
<jenatali>
Yeah I'm not really sure how you can get more, but it's possible
<alyssa>
loop with many breaks/continues
<alyssa>
the loop header has arbitrarily many predecessors
<jenatali>
Right
elongbug has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
smiles_1111 has joined #dri-devel
<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
<alyssa>
:D
psykose has joined #dri-devel
psykose has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
elongbug has quit [Remote host closed the connection]
<jenatali>
Ok that needs more investigation, thanks for questioning me :)
<jenatali>
I'll split that MR and land just the dzn bits then