ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
kzd has quit [Quit: kzd]
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #dri-devel
kzd has joined #dri-devel
RAOF has quit [Remote host closed the connection]
mstoeckl has quit [Quit: Lost terminal]
vyivel has quit [Read error: Connection reset by peer]
hikiko has quit [Quit: Leaving!]
RAOF has joined #dri-devel
vyivel has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #dri-devel
yyds has joined #dri-devel
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #dri-devel
yuq825 has joined #dri-devel
Daanct12 has joined #dri-devel
karolherbst_ has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
AnuthaDev has joined #dri-devel
vyivel has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
tlwoerner has quit [Quit: Leaving]
<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'
<airlied>
ah LVP_POISON_MEMORY is the secret CI thing I didn't have locally
Duke`` has joined #dri-devel
itoral has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
macromorgan_ has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
AnuthaDev has quit [Quit: AnuthaDev]
dviola has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
kj_ has joined #dri-devel
junaid has joined #dri-devel
DodoGTA has joined #dri-devel
kj has quit [Ping timeout: 480 seconds]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
DodoGTA has quit []
DodoGTA has joined #dri-devel
junaid has quit [Remote host closed the connection]
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
DodoGTA has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.0.5]
Daanct12 has joined #dri-devel
pcercuei has joined #dri-devel
hansg has joined #dri-devel
kts has joined #dri-devel
bmodem has joined #dri-devel
frieder has joined #dri-devel
sima has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
vyivel has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
j`ey has left #dri-devel [#dri-devel]
rasterman has joined #dri-devel
DodoGTA has joined #dri-devel
glennk has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
<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
<MrCooper>
flush as in glFlush?
crabbedhaloablut has joined #dri-devel
neobrain has joined #dri-devel
lynxeye has joined #dri-devel
sarahwalker has joined #dri-devel
jkrzyszt has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
ficoPRO10 has joined #dri-devel
cobralt^ has quit [Ping timeout: 480 seconds]
cobralt^ has joined #dri-devel
cobralt^ has quit [Read error: Connection reset by peer]
cobralt^ has joined #dri-devel
kj_ is now known as kj
JohnnyonFlame has quit [Read error: Connection reset by peer]
<mlankhorst>
lumag: usually we wait for a conflict btw. :)
i509vcb has quit [Quit: Connection closed for inactivity]
agd5f_ has joined #dri-devel
<sima>
mlankhorst, should we have that as a reference in the dim docs maybe?
<sima>
jani, ^^
<sima>
iirc it's one of the clearest and least angry "how to do merges" explainers from linus
agd5f has quit [Ping timeout: 480 seconds]
<jani>
sima: I'm a bit surprised he seems to promote topic branches while that's been frowned on lately in drm land
<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
<sima>
jani, I guess we could do it like linus proposed, but it means committers would push entire branch merges
<sima>
and I don't think that's a good idea for us with the committer model
<jani>
agreed
<sima>
but the part about why/how to do merges does apply to us too, fully
<sima>
jani, yeah if your merge commit message has the word "sync" in it, it's probably not so good :-P
mclasen has joined #dri-devel
darkglow has quit [Quit: darkglow]
<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
<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
ced117 has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
Amber_Harmonia has quit [Ping timeout: 480 seconds]
dtmrzgl has quit []
<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?
<emersion>
there is no way for KMS drivers to opt-out of implicit modifier support
vsyrjala_ has joined #dri-devel
<emersion>
IOW, all KMS drivers support implicit modifiers
<emersion>
KMS doesn't use INVALID to represent implicit modifiers
anarsoul has quit [Read error: Connection reset by peer]
hansg has quit [Remote host closed the connection]
Amber_Harmonia has joined #dri-devel
<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.
<pq>
sima, yeah, documenting it is part of the new color pipeline UAPI effort.
itoral has quit [Remote host closed the connection]
<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
<sima>
so you might still end up stuck in a configuration corner that you can't get out of without ALLOW_MODESET
<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.
<sima>
that's a thing we cannot guarantee across the board
<pq>
and that's what drivers need to give us
<sima>
we can try really hard, but guarantee is too much
cobralt^ has quit [Remote host closed the connection]
<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
<sima>
there's currently no way to ensure b)
<pq>
funky hardware can be funky for sure, but make sure to require ALLOW_MODESET if you can't go or revert without.
bmodem has quit [Ping timeout: 480 seconds]
<sima>
since currently what we can do is "current state" -> "arbitrary state A"
<sima>
what you want is "arbitrary state A" -> "arbitraryt state B" TEST_ONLY queries
<pq>
Userspace that is happy with a static setup will just do one ALLOW_MODESET commit when it starts, and be done.
<sima>
would be a pretty big rewrite
<sima>
yeah I understand what you want
<sima>
I'm telling you atomic cannot guarantee this
<sima>
and it would be a huge amount of work to get there
<sima>
we'd need to rewrite everything so that atomic check doesn't look at the current state, but an explicitly passed-in state
<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
<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
<sima>
and if we preemptively just reserve all kinds of resources (fifo space, memory bw, clocks, ...) for all compositors fallback states, we're screwed
<karolherbst_>
austriancoder: update vtn_opencl.c
<karolherbst_>
atm we call into libclc for that
<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.
<karolherbst_>
and then make it go through the nir_alu_op_for_opencl_opcode path instead and emit the nir instruction
karolherbst_ is now known as karolherbst
<sima>
pq, yeah that's pretty much my argument too, if you want a robust compositor you need this fallback
<sima>
and then probably mark some features as "can't use that safely"
<karolherbst>
uhm.. I think in nir it's urol/uror, right?
<sima>
since only when you set ALLOW_MODESET does atomic guarantee that the TEST_ONLY result is the same, irrespective of the current state
Company has joined #dri-devel
<sima>
without allow_modeset TEST_ONLY applies only to that specific state _transition_
<karolherbst>
austriancoder: alternatively just handle it explicitly inside handle_special so it doens't go through handle_clc_fn
<karolherbst>
but that kinda depends on how rotate needs to be implemented
<sima>
so A->B works does not imply that B->A can work
<sima>
and it's also not transitive
<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.
<karolherbst>
yeah... fair :D
<karolherbst>
but yeah, all the SPIR-V CL instructions are handled inside vtn_opencl
<austriancoder>
karolherbst: I will dive into it the next 1-2 day
<karolherbst>
cool
<karolherbst>
I think I was there at some point, but for some reason I ended up using libclc for it anyway
AnneHappy has joined #dri-devel
<karolherbst>
maybe we don't have a proper lowering path in place?
<austriancoder>
so be prepared for some questions
<austriancoder>
maybe
<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"
<karolherbst>
but we do have lower_rotate...
<karolherbst>
ohh yeah.. that's newer than the vtn_opencl stuff
<austriancoder>
so in nir it would be a urol
<MrCooper>
sima: the compositor can complain about "broken HW/driver" then ;)
<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
<karolherbst>
handle_alu -> nir_alu_op_for_opencl_opcode is the path
<karolherbst>
but you might want to check for `lower_rotate` or we just require drivers to set it
<karolherbst>
kinda depends on if the CL CTS is happy or not
<austriancoder>
I see
AnneHappy has quit [Remote host closed the connection]
<pq>
*unrecoverable
digetx has quit [Ping timeout: 480 seconds]
<sima>
MrCooper, not sure that helps either, since imo the pain is between exposing features of the hw and people trying to use them
<sima>
if we just don't expose the features then it's back to "terrible driver support"
<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.
<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
<karolherbst>
or does your hardware have native support for it?
<sima>
pq, it is on the next commit, like when you try to fall back on multiple outputs
<sima>
it's just not very directly observable, but it's the reason why !allow_modeset test_only checks are neither transitive nor reversible
<austriancoder>
karolherbst: depends on the gpu model .. but I have a nir pass for that
<karolherbst>
mhh
<karolherbst>
I mean, atm I handle it all in the frontend, because on 64 bit hardware it also requires 64 bit offsets
<karolherbst>
but that offset feature is mostly never used
<karolherbst>
and if you require offsets your task runs for hours anyway, so the overhead of variants is super unimportant... mhhh....
<karolherbst>
maybe I really deal with that in the frontend like that
<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".
<pq>
and only if the commit does not have ALLOW_MODESET
<sima>
pq, that doesn't give you what you want
<pq>
we can have a DRM cap for such behavior, I understand it's a new requirement.
<sima>
like you want A->B and B->A
<sima>
but then you do B->C, but you still want to check for C->A as the fallback
<sima>
not C->B->A as your fallback
<sima>
and again, they're not the same
<sima>
pq, also implementing what you want is as much work as implementing generic B->A checks
<sima>
since I flat out don't trust humans to correctly judge whether something is inversible or not
<austriancoder>
karolherbst: ahh 64 bit offsets .. nothing I thought about yet.
<austriancoder>
karolherbst: PIGLIT: {"subtest": {"rotate int1" : "pass"}} - with less instructions :)
<karolherbst>
nice
<karolherbst>
though that's piglit :D
<austriancoder>
:)
<austriancoder>
I will prepare an MR and see what CI thinks about it
<karolherbst>
in the CTS it's test_integer integer_rotate
<karolherbst>
probably breaks for char/shorts/longs in the CTS...
<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.
<karolherbst>
hopefully not
<karolherbst>
austriancoder: but yeah... atm I do all the CL CTS testing manually on my machine and run it through various GPUs
<pq>
also: if userspace is willing to ALLOW_MODESET always, then all hardware features are usable in this respect.
<sima>
pq, I'm more trying to figure out what compositors would actually need
<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"
<sima>
and I get a bit an impression this last ditch escape hatch is not acceptable
<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.
<pq>
That's for generic desktop compositors specifically.
<sima>
yeah I think asking for a bug report is fine, then we can figure out how to sort out the mess
<sima>
I just had way too much cases of people enabling some feature, testing it on their one machine&config and shipping it
<pq>
Special purpose compositors have different requirements, like falling back ever for any reason makes the system unusable for example (set-top boxes).
<sima>
and then the kernel having to bend over backwards to keep up the illusion that all these assumptions somehow hold
<sima>
pq, yeah but those generally are a lot more fine tuned for the hw and use-case
glennk has quit [Ping timeout: 480 seconds]
<sima>
and can make assumptions about the hw/driver that go beyond what atomic uapi guarantees
<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
<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
<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
<pq>
something else.
<sima>
pq, yeah, and currently we do not guarantee this at all
<sima>
and if you want full transitive, I'm not even sure how to implement that
glennk has joined #dri-devel
<sima>
even on _really_ nice hardware
<sima>
the moment you have any shared resources that need a bit of sync it's out
<sima>
iow, if you want full transitive, gpu compositioning it is
<pq>
is anything ever an actual guarantee? I didn't think so.
<sima>
if you set ALLOW_MODESET, we do guarantee everything you listed
<pq>
yes, this is all new UAPI
<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
<sima>
but we can only guarantee this because essentially ALLOW_MODESET _always_ goes through the "everything off" state and then optimizes unecessary transitions out
<sima>
as soon as you disallow that, transitivity and inversion are out
yyds has quit [Remote host closed the connection]
<pq>
yeah, I'm describing what I would want, regardless of whether it's possible.
<sima>
and if you insist they're not we need to statically assign all shared resources and never change that
<sima>
for some value of "statically"
<sima>
probably driver lifetime
<pq>
the KMS color pipeline UAPI though has a much more limited scope and much better defined "must be able to turn off" requirements.
<austriancoder>
karolherbst: I only have one desktop GPU where I could do testing.. so I need to trust CI :D
<sima>
yeah within a very limited feature set we might be able to actually guarantee that
<sima>
but I'm honestly worried about the validation effort
<sima>
like if you just put this into docs it's not going to be worth more than the bits to store it
<sima>
there's a lot of internal consistency checks and "impossible by design" stuff to make the ALLOW_MODESET guarantees work
<pq>
there's always blinky and screaming, and with DRM fligh recorder, maybe even a clue of what went wrong
frieder has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.0.5]
bmodem has joined #dri-devel
<karolherbst>
austriancoder: yeah... I kinda want to wire up CL CI, but uhh...
<karolherbst>
it takes like 15 seconds to trigger and run it here on three drivers
<karolherbst>
just open the MR and I'll verify it doesn't break anything
<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 :)
<karolherbst>
yeah...
<karolherbst>
I suspect urol/uror are 32 bit only
<karolherbst>
and now I remember why I haven't wired that up
<karolherbst>
ohh
<karolherbst>
just the second source needs to be 32 bit...
<karolherbst>
might be enough to throw in a `nir_u2u32`
frieder has quit [Ping timeout: 480 seconds]
<austriancoder>
karolherbst: I updated the previous link .. at the bottom are more infos regarding the assert
<karolherbst>
yeah
<karolherbst>
the second source to uror/urol needs to be 32 bit
jdavies has joined #dri-devel
<austriancoder>
lets try that
jdavies is now known as Guest2961
jkrzyszt has quit [Remote host closed the connection]
<sima>
iirc for an example the panel scaler on older intels can be disabled without a modeset, but not enabled
ishitatsuyuki has joined #dri-devel
<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
<sima>
like ramping up clocks and stuff like that
<sima>
swick[m], ^^
<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
<austriancoder>
karolherbst: yeah.. lets see if CI is happy then I change it
<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
aravind has quit [Ping timeout: 480 seconds]
<sima>
like going back to your safe config might mean that you need to get hold of a full-screen scanout thing again
<swick[m]>
right, so don't allow any commit with !ALLOW_MODESET which would disable the full-screen scanout thing
<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
<sima>
swick[m], that would piss off the people who _want_ us to use the hw fully
<swick[m]>
make it a new flag
<sima>
then the validation problem strikes
<sima>
it's a lot more than "add a flag to the uapi"
<swick[m]>
what exactly do you mean with validation problem?
<sima>
so you have some safe state S
<sima>
essentially the flag would need to guarantee that for any A->B test-only atomic check
<sima>
we then also guarantee that B->S doesn't require a modeset
<sima>
for some compositor specific S
<sima>
or sessions specific or whatever
<sima>
validating that B->S will work requires a substantial rewrite, it's flat out not something current atomic can answer
<swick[m]>
I mean, you're saying that this needs work in drivers, which is definitely true
<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.
<sima>
swick[m], nah the semantics isn't hard
<sima>
the driver work is
<sima>
currently for testing A->B drivers just look at the current state to get at A
<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
<sima>
there's a _lot_ of kms atomic code in the kernel nowadays
<sima>
and this does not cover the drivers which track even more funky transition state in their atomic machinery, only the basic kms drivers
<sima>
or you just pray that driver writes will deduce this correctly and handle in the code, without doing the actual B->C validation
<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
<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"
<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?
<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?
<swick[m]>
sima: the question really is if there is a simpler way to get the guarantees a generic user space needs
<swick[m]>
sima: but I suspect not tbh
bmodem has joined #dri-devel
<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
<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
<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
<pq>
I suspect drivers may be sneaking new KMS props upstrem and no-one notices.
<sima>
pq, I periodically check for these and scream
<pq>
sima, awesome - how do you detect them?
<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.
<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
<swick[m]>
thus we stop using most features on all hardware/drivers which don't work by accident
<swick[m]>
so all the exposing of hardware features is utterly useless
<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
<pq>
hard to write a CTS for KMS when what you need to observe is something you cannot observe in software...
<swick[m]>
yeah, that as well
<swick[m]>
whenever we enable more KMS features, we break someones system
kts has quit [Ping timeout: 480 seconds]
<zmike>
bbrezillon: it seems like you are the vk_cmd_queue_gen.py expert ?
bmodem has quit [Ping timeout: 480 seconds]
<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
<swick[m]>
this situation is not workable IMO
<swick[m]>
we need more guarantees from KMS and we need better testing
<sima>
pq, grepping for drm_property_create essentially
<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
<sima>
but that's an internal thing, shouldn't be visible to userspace because they match
<pq>
cool, so probably all the oddballs I see are downstream
<sima>
mripard, ^^ d6020f4b26179481c7cb13aa94d7abcdfd8a4326 is the commit
<sima>
pq, yeah I think we've become fairly good at doing property uapi much better than in the past
<swick[m]>
my main problem is that if things work, they only work by accident
<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
<swick[m]>
so things never get better
<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
<mripard>
I'm glad we agree that a helper for that property would be nice :)
<sima>
mripard, sometimes I'm stupid
<mripard>
I didn't say that? very far from it
<sima>
mripard, so i915 can't use this one for some reason?
<sima>
s/stupid/inconsistent/ maybe better
<bbrezillon>
zmike: am I? :D
<zmike>
bbrezillon: git log says yes :D
<sima>
swick[m], I think one part is also that there's no library of funny hw for compositors to test against
<sima>
which is why I'm hoping vkms could eventually get there
<sima>
that way you could test against strange corner cases before shipping
ficoPRO10 has joined #dri-devel
<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
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<mripard>
sima: I mean, the not-a-helper-for-a-single-user rule makes sense, really
<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)
<mripard>
which is why I'm also surprised there :)
<sima>
mripard, yeah but I thought it's two here with vc4 and i915
<zmike>
bbrezillon: is there a way you can make this handle itself recursively so any number of nested array/struct/array combos work?
<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
<mripard>
but anyway, I looked at i915 and it was mostly storing it in a very different datastructure than what the helpers are using
<zmike>
I tried reading the code here but python is not really my forte :/
<sima>
swick[m], ime compositors fail at stuff that we really cannot ever guarantee
<mripard>
so the rework looked above my i915-fu, especially for an RFC
<sima>
like blindly assuming that you can use any tiling format, and then getting disappointed
<swick[m]>
ofc there is a lot of stupid user spaces out there
<sima>
this is stuff we cannot ever guarantee because light speed is not infinite and so neither is memory bw
<mripard>
If you want that for the next version, I can totally do it
<sima>
mripard, yeah maybe follow up or something, or a todo
<swick[m]>
but it's also literally impossible the write a generic compositor with the guarantees we get
<sima>
mripard, anyway I'm really happy about the docs for the prop
<swick[m]>
well, literally impossible in the sense that we can't use offloading and color transofmrations
<zamundaaa[m]>
The "any tiling format" case specifically is effectively impossible for compositors to handle...
<sima>
swick[m], I think this needs more shades
<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
<sima>
you're pretty much guaranteed to kill tons of desktops
<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
<swick[m]>
that's most likely true. mutter is especially bad at this...
<swick[m]>
but I also don't see how we could write a compositor without getting to some default state
<emersion>
i don't think i'm aware of any user-space handling the tiling modifiers stuff properly
<bbrezillon>
zmike: it's been a long time, and python is not my area of expertise either, but I can have a look
<emersion>
as in, try using other modifiers on other CRTCs to light up a new output
<zmike>
bbrezillon: oh
<sima>
swick[m], well atm we're still at the "compositors can't even reliable figure out the default state to start with"
<sima>
at least for the tiling fun
<zmike>
I can try to find someone more expert...
<sima>
so "how can we reliably get back to the default state" is a few steps further
frieder has joined #dri-devel
<sima>
emersion, you might need to switch the modifier on the current one even, if that's using up all the fifo space already
<bbrezillon>
zmike: what's the CmdXxx you're looking at?
<emersion>
sima: yeah, by "other" i mean "other than the one i try to light up"
<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
<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)
<emersion>
zamundaaa[m]: that's not enough, needs to re-alloc already-on outputs too potentially
<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
<sima>
zamundaaa[m], it'll stop working the moment mesa hands you a linear buffer and your rendering becomes a slideshow
<zamundaaa[m]>
emersion: KWin always does modesets on all outputs at the same time
<emersion>
oh, nice
<emersion>
so if i have 3 outputs and plug a new one, it'll try to re-allocate buffers for all outputs?
<emersion>
potentially degrading to the implicit modifier on all of them?
<zamundaaa[m]>
yes
<sima>
well it will still work, just not to the user's satisfaction most likely
<emersion>
okay, so that's one compositor
<sima>
ship kwin everywhere, call it done
<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
<sima>
zamundaaa[m], explicit linear might be the more safe fallback I think
<emersion>
zamundaaa[m]: have you tried using non-blocking modesets? because we're seeing issues on amdgpu
<sima>
if it's purely fallback to light up something
<zamundaaa[m]>
emersion: I wanted to, but then I can't get a pageflip event in all cases
<sima>
emersion, amd's dc loves to just pull in all crtc for any modeset
<emersion>
zamundaaa[m]: requested page-flip event but off?
<zamundaaa[m]>
yes
<emersion>
a classic
<emersion>
maybe we could have a "please_send_pageflip_event" prop or something
yuq825 has quit []
<emersion>
or just use drmCrtcQueueSequence maybe?
<zamundaaa[m]>
or simply a flag that disables that stupid workaround
<emersion>
or yeah, just nuke it
<sima>
hm which workaround?
<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
<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
<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
<emersion>
right now it's very hard to figure out when user-space can request NONBLOCK without getting EBUSY
<sima>
hide behind cap
<sima>
emersion, you can't really :-)
<emersion>
so we have a patch to retry without NONBLOCK when we get EBUSY 💩
<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
<emersion>
and i can see how tempting it would be to have a separate thread just to emulate the non-buggy NONBLOCK behavior
<sima>
or some combo of these three, not sure what compositors would really all need
<sima>
you still have no clue about affected_crtc
<zamundaaa[m]>
emersion: actually I might just do that. Should be dead easy in KWin
<sima>
which is why we added this, people complained about random dropped frames
<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?
<sima>
then you shouldn't have any spurious EBUSY
<sima>
no unexpected lost vblank
<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
<sima>
and should be able to use nonblocking modesets?
<sima>
maybe then also allow events on off->off crtc with the same flag
<emersion>
so user-space would try to modeset a CRTC, get EBUSY, notice affected != requested, wait for affected, retry?
<sima>
"actually it might not be that easy" this is pretty much anything in kms :-/
sghuge has quit [Remote host closed the connection]
<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
sghuge has joined #dri-devel
<emersion>
oh
<sima>
maybe we should actually start giving back more error reasons than EINVAL with this
<emersion>
so basically a way for the kernel to say "hm i need these other CRTCs to be involved in the commit"
<sima>
*dummy props = the events for these crtc so you know when it's done
<sima>
yeah
<zamundaaa[m]>
sima: that sounds more like compositors should all stop doing modesets on singular crtcs in general?
<emersion>
and require userspace to honour that
<sima>
and for userspace to enable the events so it can keep track of these additional updates going on
<sima>
zamundaaa[m], it would allow you to make them work better
junaid has joined #dri-devel
<sima>
but yeah atm you do a modeset, you have a chance of dropped frames on the other screen
<austriancoder>
karolherbst: wohooo .. I will make the regarding handle_special and create an MR
pochu has quit [Quit: leaving]
<karolherbst>
cool
<sima>
in general atomic tries really hard to not make that happen, but if the hw requires might be useful userspace is aware?
<sima>
zamundaaa[m], the other issue is that nonblocking commits don't hold the locks, so they additional lock out even more
<sima>
if you do modesets as blocking commits I mean
<sima>
and they affect other crtc states
<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
<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
<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
<emersion>
it would certainly be nice to avoid
<sima>
and its' more that you're holding up TEST_ONLY ioctl calls too
<sima>
the missed frames isn't really avoidable, best we can do is make the compositor aware
<zamundaaa[m]>
hmm, so TEST_ONLY commits will block until the blocking modeset is complete?
<sima>
yeah, if they overlap in crtcs
<sima>
and compositors can't reasonable do nonblocking modesets with events because of all the uapi warts
<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
<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
<sima>
zamundaaa[m], you'd still need to wait for the thread to finish the ioctl?
<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
<sima>
since the kernel doesn't tell you when it's committed the new state to software, so you can race easily
junaid has quit [Remote host closed the connection]
<sima>
zamundaaa[m], ah and the next TEST_ONLY is guaranteed to only start after the events are all received?
frieder has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
hmm, no, I misunderstood your comment about blocking commits interfering with TEST_ONLY
digetx has joined #dri-devel
<sima>
zamundaaa[m], yeah it's just kernel internals, if you run a modeset that pulls in additional crtc
<zamundaaa[m]>
But the problem should be easy to avoid with a mutex
<zamundaaa[m]>
(in userspace)
<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
<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
<sima>
since these states the driver needs to adjust in the additionally affected crtc are purely internal and not visible to userspace
melonai has quit [Quit: Ping timeout (120 seconds)]
<sima>
swick[m], yeah I mean once we have fully free-standing A->B atomic check we can do a _lot_ of cool shit :-)
<swick[m]>
test commits on specific states while we don't have to care what the drivers current state is atm
<swick[m]>
sima: pls add :)
<swick[m]>
but yeah, that would be so clean
<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
<kennylevinsen>
sima: in absence of hindsight, have some caffeine instead - you will need it
<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
g0b has quit [Remote host closed the connection]
<sima>
and the patch is probably small enough we could even backport it if we you want it much faster
<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
luben_ has joined #dri-devel
<sima>
essentially all we need is compositor folks coming up with the exact uapi that's needed
<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
luben has quit []
luben_ has quit []
<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
<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
<kennylevinsen>
at least in wlroots context
luben has joined #dri-devel
<emersion>
kennylevinsen: wait without blocking for the page-flip on affected CRTCs
<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
<emersion>
continue to drive other CRTCs as usual
<emersion>
i think we could come up with an abstraction to wrap everything up
<sima>
zamundaaa[m], but what about affected_crtc?
<sima>
that's the bigger fun iirc
<zamundaaa[m]>
KWin's modesets always contain all crtcs
<zamundaaa[m]>
So I don't really care about that
<sima>
ah yeah that helps :-)
<sima>
zamundaaa[m], so you'd be ok with a check that bails out if affected_crtc != requested_crtc?
<emersion>
kennylevinsen: or yeah we could always include all CRTCs for simplicity at first
<sima>
oh we have even an unused reserved where we could stuff affected_crtc into if this flag is set
<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...
digetx has joined #dri-devel
kzd has joined #dri-devel
<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
<sima>
tzimmermann, are you sure about the various - you've proposed in your review?
<kennylevinsen>
assuming we get to know that it happened so we can react at least
<tzimmermann>
sima, you mean atomic-commit path vs. atomic commit path ?
<sima>
tzimmermann, yeah
<sima>
I thought that's very optional in English, but also no idea
<tzimmermann>
"atomic commit path" is a commit code path that is atomic; "atomic-commit path" is the code path of an atomic commit
<sima>
it's been ages I've sat in a proper grammar lesson for either german or english
<tzimmermann>
best to ask a native speak, though
<sima>
not sure it makes a difference since it's kinda both ...
<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.
<MrCooper>
so if a driver pulls additional enabled CRTCs into a commit, events are sent for those as well?
<sima>
MrCooper, yeah I think that was the issue
<MrCooper>
and user space can cope with that?
<sima>
if you use drm_event at least, for sync_file out-fence it's explicitly per crtc
<kennylevinsen>
[drm:drm_atomic_helper_setup_commit] [CRTC:51:pipe A] busy with a previous commit
<kennylevinsen>
yup
<tzimmermann>
all i can do is to memorize rules and hope to apply them correctly
<MrCooper>
kennylevinsen: my question is about events, not EBUSY
<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
<sima>
that way we're sure userspace knows about all the crtc it'll get events on
<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
<MrCooper>
what I'm getting at, isn't the current behaviour just buggy, CRTCs pulled in by the driver should be ignored WRT events?
<robclark>
so not quite _as_ dire as you make it sound
<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
<MrCooper>
my concern is about getting EINVAL with events and the driver pulling in disabled CRTCs
<zamundaaa[m]>
robclark: there's uAPI that allows you to move properties between CRTCs?
<sima>
robclark, yeah I think for ctm is should be mostly ok to guarantee you can turn it off
<sima>
even for malidp I think
<sima>
zamundaaa[m], it's about moving the resource allocations between crtc really
<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 ;-)
<sima>
MrCooper, yeah we'd need to lift that restriction too
<robclark>
(in worst case, driver can turn it "off" by programming identity matrix)
<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?
<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)
<sima>
zamundaaa[m], hw designer extremely disagree on this
<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
<zamundaaa[m]>
Then the obvious solution is to only expose the CTM on one crtc, right?
<MrCooper>
sima: a) & b) should be solved by only considering CRTCs added by user space for anything event related
<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)
digetx has joined #dri-devel
ficoPRO10 has quit [Ping timeout: 480 seconds]
digetx has quit []
<zamundaaa[m]>
The kernel doesn't need to know. Userspace can decide which crtc to use on which output, right?
<sima>
MrCooper, I guess we could do that too, but iirc some folks did complain about dropped vblanks for no reason
<sima>
and the kernel knows this stuff
<MrCooper>
zamundaaa[m]: planes can move between CRTCs as well, e.g. AMD GPUs have a single overlay plane per GPU
<sima>
zamundaaa[m], this gets more fun when you can have ctm on some planes but not freely reassigneable planes
<sima>
or a bunch more features like yuv scanout or compressed fb scanout
<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
<zamundaaa[m]>
The CTM property is on the CRTC though
<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
<sima>
there's work to add color stuff to planes, and often that's just internally shared
<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
<sima>
plus we need an explicit flag anyway
<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
<robclark>
and atomic-test fail the other cases so userspace knows to fallback to gpu
<MrCooper>
sima: sure, just saying this can be worked around, in contrast to a) & b)
<sima>
it's also generally what kms drivers do
<zamundaaa[m]>
sima: I know, I was involved in the design of that. The color pipelines are a better abstraction for things like this
<sima>
zamundaaa[m], we also have fun things like double-wide crtc
<sima>
where you need to internally double up everything
<sima>
but if your plane is small enough, you don't
<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
<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
<sima>
but then you hit the event check for disabled ones
<sima>
so currently not really a way out I think
<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...
<kennylevinsen>
we get EBUSY, and our only current option is to fall back to blocking which makes everybody sad
frieder has joined #dri-devel
<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
digetx has joined #dri-devel
<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
<karolherbst>
austriancoder: yeah.. I think that's fine, I think it might make _some_ sense to sort SMad/UMad as Mad, but whatever
<austriancoder>
karolherbst: too much manual work :)
<karolherbst>
yeah...
<MrCooper>
sima: yep, exactly
<pq>
kennylevinsen, how often do you actually *want* to do modesets in your compositor? Do you have some automatic triggers that are not hotplug?
<kennylevinsen>
who doesn't like a good modeset?
<kennylevinsen>
no, it's hotplug, but modesetting 3 displays can take a moment when you plug in a dock
<pq>
they appear one by one?
<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
<MrCooper>
hmm, and then you wouldn't know when you can flip other CRTCs again
<pq>
kennylevinsen, could you maybe wait e.g. 500ms since the last hotplug event before reacting?
<MrCooper>
so yeah, the effectively affected CRTCs definitely need to be communicated to user space
<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?
<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.
<kennylevinsen>
*thought* because the kernel pulls in some more, so the scope of the modeset does not match our expectations
<zamundaaa[m]>
FWIW KWin's abstraction is also still that way, it's possible to make it work
<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
dakr has joined #dri-devel
<sima>
swick[m], essentially switch everyone from $obj->state to use the get_old/new_state helpers
<sima>
and then rename ->state to ->_state or something to catch new users
<zamundaaa[m]>
kennylevinsen: Or do you have modeset test + commit as one function?
<sima>
past that point I have honestly no clear idea and it's just handwaving
<pq>
kennylevinsen, ah, so you'd need to postpone the implementation of a modeset to see how much you can coalesce.
<kennylevinsen>
zamundaaa[m]: ah, so when you want to modeset you basically hold back all commits? that's not a bad idea.
<zamundaaa[m]>
yes
<sima>
swick[m], note that this has kinda been going on for years by now in the background
<austriancoder>
karolherbst: ahh.. I am unsure.. I will just update the current patch .. and let the ordering to somebody else
<swick[m]>
sima: that's some good news at least!
<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
<swick[m]>
sima: get it done for one driver and start doing cool new stuff with it so everyone wants it? :)
kts has joined #dri-devel
<sima>
swick[m], one driver means you cant do the rename to catch mistakes
<sima>
and generally the drivers that would benefit are the ones that are complex
<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
<sima>
so not sure we want to fix that first or after ...
<sima>
(it's hard)
<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.
<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.
<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...
Haaninjo has joined #dri-devel
<zamundaaa[m]>
yeah if tests are also per output you may need an API break to do everything right
<karolherbst>
austriancoder: okay :D
Duke`` has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
melonai has joined #dri-devel
frieder has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
AnuthaDev has joined #dri-devel
AnuthaDev has quit []
AnuthaDev has joined #dri-devel
flom84 has joined #dri-devel
AnuthaDev has quit []
AnuthaDev has joined #dri-devel
i509vcb has joined #dri-devel
flom84 has quit [Remote host closed the connection]
cmichael has quit [Quit: Leaving]
flom84 has joined #dri-devel
ficoPRO10 has joined #dri-devel
mszyprow has joined #dri-devel
aravind has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
gallo has joined #dri-devel
gallo has quit []
ficoPRO10 has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
<gfxstrand>
dcbaker: Any idea how to do 32-bit builds with a proc macro? :sweat:
<dcbaker>
gfxstrand: cross compiling?
<dcbaker>
I should be more clear, what's the situation you're thinking of?
<gfxstrand>
dcbaker: The problem is that proc macros need to be compiled 64-bit because they get loaded as a .so by rustc
<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?
<gfxstrand>
Yes
<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
<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
flom84 has quit [Ping timeout: 480 seconds]
<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
<gfxstrand>
Oh, I'm using a cross file
<gfxstrand>
And libnak_file _build32/src/nouveau/compiler/libnak_ir_proc.so ~/projects/mesa/nak
<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
<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
<gfxstrand>
<gfxstrand>
<gfxstrand>
<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
<gfxstrand>
It has rust_crate_type set to proc-macro
<gfxstrand>
IDK what meson version I'm on. Some frankenbranch from Xavier
<dcbaker>
add native : true to any targets with rust_crate_type : 'proc-macro'
<gfxstrand>
It gets grumpy when I do that
<dcbaker>
hmmmm, is the branch public yet?
<gfxstrand>
Okay, pulled meson/master and now I'm getting an error
<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?
<dcbaker>
I thought those were suppoed to be link_with........ one second
<gfxstrand>
Maybe that's not what it's complaining about?
<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.
<dcbaker>
That is what it's complaining about
<dcbaker>
what does meson --version say?
<gfxstrand>
I literally just pulled tip-of-tree
<gfxstrand>
1.2.99
<gfxstrand>
And I switched to using rust.proc_macro() to build it
<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
<dcbaker>
sigh, and here I thought I was going to finish writing LLVM pkg-config patches today... lol
<gfxstrand>
dcbaker: It's my nak/conformance branch if you want to pull it
glennk has quit [Remote host closed the connection]
<mattst88>
dcbaker: LLVM pkg-config would be awesome!
<mattst88>
I read that llvm-config is deprecated, but I don't know what's supposed to be the replacement?
<dcbaker>
I saw that it's deprecated too and decided I needed to write the replacement before they decide "use cmake" is the replacement
<mattst88>
ugh
<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" ;)
<mattst88>
sounds good
<mattst88>
are you trying to figure out how to get someone to add you to the approved-list for contributing to llvm?
<mattst88>
Vincent Lejeune <vljn@ovi.com> is a former mesa contributor, I think?
<dcbaker>
There's a few former Mesa people over there. Nicolai does a lot of LLVM work too I think
junaid has joined #dri-devel
jeeeun841351 has quit []
<mattst88>
nobled@dreamwidth.org as well
<mattst88>
these are from the 'LLVM relicensing - long tail' spreadsheet
jeeeun841351 has joined #dri-devel
<cwabbott>
I thought that effort was effectively dead because a former core contributor with changes all over the place refused to sign
<cwabbott>
there was some mailing list drama over that I think
<mattst88>
hmm, I really don't know. seems like they would have removed the pages from the website if it was dead
<cwabbott>
holding out hope, I guess?
<cwabbott>
it's been ages and I haven't heard them announce they'd switched
<mattst88>
I think they switched what license *new* code is contributed under
<mattst88>
and the relicensing long tail effort is about being able to remove the old license
<mattst88>
but I'm just getting this from that link
jeeeun8413519 has joined #dri-devel
jeeeun841351 has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
ngcortes_ has joined #dri-devel
jeeeun8413519 has quit [Read error: No route to host]
jeeeun8413519 has joined #dri-devel
cobralt^ has joined #dri-devel
<cwabbott>
yeah, I guess so
<cwabbott>
I dunno how useful it is to have a mixed license like that, but... IANAL
rasterman has quit [Quit: Gettin' stinky!]
AnuthaDev has quit []
<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
tursulin has quit [Ping timeout: 480 seconds]
ngcortes_ has joined #dri-devel
fab has quit [Quit: fab]
ngcortes has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
ngcortes_ has quit []
<gfxstrand>
dcbaker: Any ideas?
ngcortes has joined #dri-devel
<dcbaker>
gfxstrand: I found another bug, which is annoying
<dcbaker>
I think I found a workaround for that, but will need to fix it too :/
<dcbaker>
It seems to work in a unit test... let me see on your branch
Duke`` has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
mszyprow has quit [Ping timeout: 480 seconds]
<dcbaker>
gfxstrand: I see I need to finish that work I started for allowing partial_dependency() to work with pkg-config...
<dcbaker>
you have /usr/lib/valgrind hardcoded :)
<dcbaker>
I am seeing the same build failure you are
<dcbaker>
Now to figure out why it's failing but our unit test is not. I have a few ideas
mclasen has quit [Remote host closed the connection]
<airlied>
dcbaker: is your plan to add pkg-config to llvm itself?
mclasen has joined #dri-devel
<mattst88>
I think it must be, since he's trying to get intel to add him to their CLA
<dcbaker>
airlied: yes
<dcbaker>
I actually already have it mostly working for static linking, with some extra Meson patches to make the whole thing transparent
<airlied>
dcbaker: should talk to tstellard about how it might be received
<airlied>
there is #llvm on this server where he might be found if you haven't talked to them yet
<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
<airlied>
I think tstellar is his nickname
<dcbaker>
I will give him a ping and see what he thinks, thanks
<dcbaker>
gfxstrand: I know what the problem is! syn is! we need build-machine subprojects. I fortunately have some patches for that!
<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
junaid has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
cef has quit [Quit: Zoom!]
cef has joined #dri-devel
iive has quit [Quit: They came for me...]
ficoPRO10 has quit [Ping timeout: 480 seconds]
pa- has quit [Ping timeout: 480 seconds]
pa has joined #dri-devel
RSpliet has quit [Read error: Connection reset by peer]