<alyssa>
nobody's fault there but it adds to the ">_>"
<HdkR>
Just need more build machines to increase the amount of parallelism right? :)
<robclark>
yeah, we will be adding some more hw to freedreno farm.. we just need to find some (and perhaps dealing with moving it between buildings and such.. just need a bigger UPS and LTE hotspot and maybe we can keep it running the whole time :-P)
invapid has joined #dri-devel
invapid has quit [Remote host closed the connection]
ngcortes has quit [Remote host closed the connection]
<jekstrand>
robclark: Don't they all have batteries? Why do you need the UPS? Just get a wireless charging table.
<daniels>
robclark: don't forget a fox to keep the cats at bay
<robclark>
jekstrand: we pull the batteries out so we can power cycle w/ relay
<daniels>
jekstrand: funny story, one of our admins has spent this week figuring out how to keep one of our newer classes of Chromebook balanced between 'the battery is going to swell and burn the building down within the month' and 'even though it's hard-wired through to mains it still refuses to turn on because the battery isn't sufficiently charged'
<robclark>
daniels: it's only a few pdx city blocks, so it shouldn't be too bad.. and the rack already has wheels :-P
* robclark
remembers the pre-usb-c days of phones that didn't have PMIC logic to hold off booting until battery had enough charge.. good fun if you completely ran down the battery
<HdkR>
Since the rack has wheels you can just push it out of the building as it goes up in flames? :)
<daniels>
robclark: I'm pretty sure one prominent ex-phone-manufacturer had multiple patents on exactly that
<daniels>
HdkR: as long as you make sure the path you push it through has consistent LTE signal so you never fail a DNS request
<HdkR>
Really determined to never take CI down
<robclark>
daniels: tbh the qcom PMICs do a better job than TI's at that (but tbf I'm comparing something much more recent to something much older)
<alyssa>
...Nokia?
idr has quit [Quit: Leaving]
<daniels>
alyssa: it's a strong and logical conclusion
<daniels>
robclark: the last I remember of any TI PMIC was the one where USB suspend was terminal ... wonder if they sold that IP to Intel for APL :P
<robclark>
lol
* alyssa
thinks about better approaches to magic resource state tracking in GL driver
<alyssa>
KHR-GLES31 turned up a bug where we werne't flushing properly because the buffer valid range (logic cargoculted from freedreno) wasn't updated from transform feedback writes
<alyssa>
speaking of
<alyssa>
robclark: If you create a streamout target for a resource, then invalidate the resource, then do a draw writing XFB to that resource, and then try to transfer from it
<alyssa>
That miiiight be broken in freedreno if I'm reading the code right?
<alyssa>
because you range_add in create_so_target but not in draw_vbo..?
<alyssa>
similarly if you bind a buffer as an SSBO i'm not sure fd updates valid_buffer_range correctly?
<robclark>
I'd have to dig thru mesa/st but I think it is *somehow* expected to be re-bound as SO target? With TC, TC is doing the valid range tracking and driver isn't using it's internal range tracking
NameBrand has joined #dri-devel
NameBrand has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-09 00:56:12)]
* robclark
didn't really notice there are KHR-GLES tests... really the only thing that matters is android cts (ie. deqp-gles*)
<alyssa>
robclark: Is the moral that I should delete panfrost's tracking and add TC support? :-p
<robclark>
you still need some internal tracking for !TC cases (either disabling TC via env-var for debug, or other state trackers, ie. clover)
<alyssa>
robclark: mmh, right
<alyssa>
well, freedreno's is missing cases for SSBOs and images, it looks like, that tc handles.
xp4ns3 has quit []
<alyssa>
also, i finally noticed the KHR-GLES tests and panfrost was failing 100 of them on a branch that got 100% deqp-gles31
<alyssa>
and that corresponded to a dozen actual bugs that dEQP didn't hit but apps could
<alyssa>
so, well worth it.
Blackisle has joined #dri-devel
Blackisle has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-09 01:07:48)]
<airlied>
daniels: so we be ulimit -c 0 before test runs?
<airlied>
should we
Lightkey has quit [Ping timeout: 480 seconds]
imirkin has quit [Remote host closed the connection]
imirkin has joined #dri-devel
pnowack has quit [Quit: pnowack]
Lightkey has joined #dri-devel
mattrope has quit [Remote host closed the connection]
<zmike>
jekstrand: nice tagging 👍
NiksDev has joined #dri-devel
khfeng has joined #dri-devel
<alyssa>
jenatali: looks like the vs2019 container is stalling in a bunch of MRs..?
<jenatali>
alyssa: I think that's for daniels, I don't know much about the infra side of things
<airlied>
alyssa: stick a dot in front of it
blue__penquin has joined #dri-devel
<Sachiel>
the dot of shame
Duke`` has joined #dri-devel
mbrost has joined #dri-devel
mbrost has quit [Remote host closed the connection]
claus_chr-M has joined #dri-devel
claus_chr-M has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
shankaru1 has joined #dri-devel
macromorgan has quit [Remote host closed the connection]
sdutt has quit [Remote host closed the connection]
Electron^-04212 has joined #dri-devel
vivijim has quit [Remote host closed the connection]
Electron^-04212 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-09 05:10:33)]
lemonzest has joined #dri-devel
thellstrom has joined #dri-devel
shankaru1 has quit [Ping timeout: 480 seconds]
shankaru1 has joined #dri-devel
jewins has quit [Remote host closed the connection]
pekkari has joined #dri-devel
itoral has joined #dri-devel
reductum has quit []
reductum has joined #dri-devel
andrey-konovalov has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
andrey-konovalov has quit [Ping timeout: 480 seconds]
<DPA>
When will the next mesa release be?
frieder has joined #dri-devel
Koniiiik has joined #dri-devel
Koniiiik has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-09 06:30:47)]
<kusma>
Is that some missing filtering or something?
<MrCooper>
yeah, manual jobs have no file filters
<MrCooper>
these jobs do not exist in pipelines for Marge
<kusma>
Ah.
<kusma>
OK, thanks.
Terman has joined #dri-devel
<MrCooper>
np
<kusma>
Seems they don't end up getting run when I trigger the x86_build_base and x86_test_base jobs anyway.
Thete has joined #dri-devel
<kusma>
At least the intel ones. I guess I'd have to trigger arm_build to see if the freedreno job would get run, but I'm not planning on doing that ;)
<MrCooper>
yeah, it's always-manual test jobs
Thete has quit [Remote host closed the connection]
danwellby has joined #dri-devel
danwellby has quit [Remote host closed the connection]
goosfraba has joined #dri-devel
goosfraba has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
vivijim has joined #dri-devel
Lord-Simon has joined #dri-devel
Lord-Simon has quit [Remote host closed the connection]
ppascher has quit [Remote host closed the connection]
ppascher has joined #dri-devel
mceier has quit [Ping timeout: 480 seconds]
mceier has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
libv_ has joined #dri-devel
ppascher has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
MatCat5 has joined #dri-devel
MatCat5 has quit [Remote host closed the connection]
<daniels>
but there are some bigger issues somewhere because it seems to infrequently blow up on pretty much everything
<alyssa>
aside question - ooi what's the intended use of -Wno-unused-variables -Werror in release builds? (annotating things as ASSERED)
<alyssa>
not inherently opposed to it but I don't see the value yet
<zmike>
I think the comments are misleading; helgrind/valgrind throw tons of errors for tc as well without any of them being valid
<alyssa>
and since I mostly do debugoptimized builds locally this is a common legitimate CI fail for code I write that I already tested locally
<daniels>
zmike: huh rly?
<zmike>
yea helgrind throws infinite errors for many parts of mesa
<alyssa>
by the way how do I manually play panfrost jobs? it doesn't seem to work anymore
<zmike>
it's a useful tool for sure, but it's not the ultimate arbiter of thread safety
<alyssa>
I assume that's user error
<zmike>
are you trying to make jobs on the same branch?
<daniels>
alyssa: -Wunused-variables isn't explicitly put in there by us, it's part of the default Meson arguments
<zmike>
might just not be triggering due to no changes detected
<daniels>
alyssa: so if we want release builds to work out of the box ...
<alyssa>
I mean we could set -Wno-unused-variables, presmuably there's a good reason not to
<daniels>
not really, I guess just that no-one has
xp4ns3 has joined #dri-devel
<jenatali>
Unused variable warnings are great. They've caught bugs of mine where I add a new variable but accidentally reference the wrong one in code
<alyssa>
jenatali: On release builds though?
<alyssa>
Agreed for debug builds, with assertions
<jenatali>
Oh I see what you're saying
<alyssa>
I'm struggling to think of a case where it's warnings free in debug but warning in release and there's a real bug to be fixed some way other than adding ASERTED
<jenatali>
Eh, yeah I guess I can't remember any time that was specifically useful
mceier has quit [Remote host closed the connection]
mceier has joined #dri-devel
randomher0 has joined #dri-devel
<danvet>
airlied, heads-up: quite some conflicts around ttm between drm-intel-gt-next and drm-misc-next
<danvet>
so be careful when merging the next pulls on these and maybe push to a test branch first so thellstrom/könig can review/test
leejo has quit [Remote host closed the connection]
<danvet>
tzimmermann, the merge conflict resolutions should be in drm-tip, so maybe just remind airlied to look there
<danvet>
or do a test merge (with git rerere disabled) yourself to see what blows up and compare to the merge resolution drm-tip has
mceier has quit [Remote host closed the connection]
frieder has quit [Ping timeout: 480 seconds]
mceier has joined #dri-devel
macromorgan has joined #dri-devel
<pq>
alyssa, maybe to catch something silly like assert(update_my_cache(foo) == yes!!);? Or maybe there are other ways to detect side-effects from code that magically just totally disappears on production builds?
<pq>
side-effects you rely on
<alyssa>
hmm, usually that comes up as `assert(side_effects_returns_error_code() == 0)`
<alyssa>
for which -Wunused-variable doesn't help you (but a code review does)
<pq>
mm
<pq>
or maybe you call a function to set a local variable that is not needed in production => better not call the function at all then
<alyssa>
Presumably dead code elimination would take care of that, at least if it's inlined.
<pq>
...as a no-side-effects case
aravind has quit []
<pq>
maybe, maybe not, who knows
<pq>
the compiler would need to be absolutely sure the function has no side-effects
<alyssa>
true
<jekstrand>
daniels: Thanks!
<daniels>
yw
<dianders>
pinchartl: I think I'm ready to commit my tisn65dsi86 DP AUX bus series but I wanted to double-check with you before doing so since it still drives the EDID reading from the panel. I've done as was discussed last time on IRC and built up a full DP AUX bus in Linux. All patches are Reviewed by someone (Linus W, Bjorn, or Lyude) other than the patch introducing the DP AUX bus and the dts.
<dianders>
The one introducing the DP AUX bus has Linus W's Ack and I'm assuming that's enough. The dts one I'll work with Bjorn to figure out how to land (in his tree 1 rev later or in drm-misc with his Ack?)
<Lyude>
dianders: I can try to get it today or tomorrow
<dianders>
Lyude: Ah, OK. I'm happy to wait then!
<dianders>
Still would be good to confirm that pinchartl is OK w/ it landing if it has good reviews or if he wants me to wait until he has a chance to take another look.
thellstrom has joined #dri-devel
<danvet>
alyssa, maybe karolherbst needs drm-misc commit rights to push nouveau stuff?
<danvet>
there's quite some random nouveau patches falling through cracks
<karolherbst>
danvet: we are working on it
<danvet>
drm-misc for small things for nouveau?
<karolherbst>
moving to gitlab
<karolherbst>
and allow MRs
<danvet>
ah works too
<karolherbst>
yeah
<karolherbst>
I already written a CI pipeline with checkpatch and build testing
<danvet>
I need to get that going with drm-misc too
<karolherbst>
so shouldn't take too long anymore
<danvet>
hm do you want to make that happen for drm-misc too?
<karolherbst>
danvet: in the past we already pushed some patches through drm directly
<danvet>
since buildtesting with drm is a bit fail ...
<karolherbst>
ahh yeah... it's... uff.. wait a sec
<danvet>
karolherbst, yeah I pick some up and stuff them in drm-misc
<danvet>
but I dont think you can push to drm-msic
<karolherbst>
we have a scheduled job pulling from certain linux trees
<karolherbst>
so we always have an up to date repo cache
<danvet>
emersion, threading broken
mattrope has joined #dri-devel
<karolherbst>
danvet: no I can't, but yeah.. it would be nice to have something working for smaller patches, but we are planning to just use gitlab for it. For really critical bug fixes we used to also just push via airlied.. just that I also sometimes forget about thinks or rely too much on ben to pick things up
<emersion>
danvet, yea yea, it's annoying to fix
<danvet>
so want drm-misc for that, avoids the need to do the pull request yourself?
<danvet>
plus maybe motivates to roll out gitlab for drm-misc :-)
<karolherbst>
if nobody minds
<danvet>
mlankhorst, mripard, tzimmermann ack on drm-misc commit rights for karolherbst for nouveau stuff?
<danvet>
karolherbst, currently comes with the need for scripts for some local checking, but ofc gitlab CI would be better for that eventually
<danvet>
then the maintainers in drm-misc maintainers (mripard, mlankhorst, tzimmermann)
<danvet>
then airlied and me as last resort
<pinchartl>
dianders: I still haven't had time to look at your series I'm afraid. I've scheduled that for the end of next week, but it's not really fair to delay everything, so I'd be ok if you wanted to merge the patches without my review. I'll then cry alone in a corner when I'll try to use the driver on my board
<alyssa>
danvet: ok, ty
<alyssa>
where was I supposed to read that
<alyssa>
what docs did I miss
<danvet>
the maintainer thing is considered uncool enough that default tools miss it :-(
<karolherbst>
upsi
<danvet>
alyssa, but anyone pushing panfrost patches would be good enough for drm-misc stuff too
<danvet>
*committer thing I meant
* danvet
too distracted
<alyssa>
err ok
<danvet>
alyssa, also maybe after another few patches want drm-misc commit bit too?
<danvet>
would solve that problem, give you a pile more :-)
<alyssa>
yeah that would seem to create more problems than it would solve :-)
imirkin_ has joined #dri-devel
<dianders>
pinchartl: LOL. I think it should still be easy enough to make it work on your board.Note: it feels like a good long term direction might be to model a DP connectors as a DP AUX Bus device too, but that wouldn't be required. You could still just read the EDID in the bridge chip for the non-eDP case. OK, I'll wait till Lyude reviews tomorrow and assuming no problems are found I'll plan to commit tomorrow or Friday.
Duke`` has joined #dri-devel
<pinchartl>
dianders: "easy enough", famous last words
<pinchartl>
I know I'll cry :-)
<pinchartl>
but I'll have pain to share
<pinchartl>
I may need to pick the comunity's brain on support for alternate fields in framebuffers
<Venemo>
daniels: sorry to bother you, but it seems to me that MR 11072 has a successful CI pipeline, yet marge didn't merge it
<pinchartl>
for a display device that requires the top and bottom fields to be submitted in consecutive atomic commits, in different buffers, when outputting an interlaced mode
<pinchartl>
has anyone ever had to consider such use cases ?
<daniels>
also you can search for assignee == marge-bot in the open merge requests
stmuk3 has joined #dri-devel
<daniels>
order by last updated and that's the order she'll pick in
<Venemo>
okay
<bnieuwenhuizen>
(well, last updated one is the one she will not pick, IIRC it is by oldest update first)
stmuk3 has quit [Remote host closed the connection]
<Venemo>
but I don't get it. it said "CI failed", but the pipeline I see on the MR's page is green
<Venemo>
also, about the order the MRs are picked. are they really picked in the order of when they were last updated? does that mean that when I commented on it i bumped myself back in the queue?
<karolherbst>
sometimes it fails randomly for.. weird reasons
<karolherbst>
just try again
<Venemo>
daniels already assigned it to marge a few hours ago
<Venemo>
but it seems I pushed it back in the queue when I commented on it? if it really goes by last updated order
<Venemo>
does this also imply that I can get ahead in the queue if I comment on every other MR assigned to it?
<pendingchaos>
Venemo: I tried to merge !11072 by restarting the failed job and reassigning marge
<pendingchaos>
though I think that didn't work because marge was busy with other MRs
<pendingchaos>
so that's why the pipeline is green
<daniels>
(2h, and we had one timeout which blocked everything for 1h)
<alyssa>
Venemo: lol @ the commenting strategy
<Venemo>
well, is that how it works or not?
<karolherbst>
I hope not :D
<bnieuwenhuizen>
AFAIU it does
<karolherbst>
:O
<Venemo>
lol
<Venemo>
then basically we can troll each other's MRs by commenting on them?
<bnieuwenhuizen>
when you got your commit rights you got some trust placed in you, I hope you can find it in your heart not to abuse that trust :)
<karolherbst>
ehhh
<karolherbst>
sure
<ccr>
"with great power comes great responsibility."
<karolherbst>
but...
<karolherbst>
how many people have commit rights in mesa? 150? :D
<Venemo>
let's quietly hope that everyone else forgets this discussion by the next branch point, then? :P
<karolherbst>
:D
<karolherbst>
okay
libv_ has joined #dri-devel
<alyssa>
I got commit rights for mesa in high school, are we sure the process makes sense? ;-P
<alyssa>
"responsibility"
<bnieuwenhuizen>
yes, on the other hand trolling a bit with submission order is far from the most abusive thing anyone could do
<Venemo>
well in this case I just trolled myself by commenting on my own MR, it seems
<alyssa>
Venemo: downstream mesa forks that just sent batches of 100s of commit upstream before the branchpoint when :<
imirkin is now known as Guest1453
imirkin_ is now known as imirkin
<bnieuwenhuizen>
alyssa: the number of commits mostly doesn't matter for Marge durations :P
<karolherbst>
bnieuwenhuizen: don't give us stupid ideas :D
<alyssa>
bnieuwenhuizen: yeah, exactly
<alyssa>
Marge frustration scales with # of MRs, not with # of commits
<karolherbst>
mesa platinum membership for high priority MRs
<bnieuwenhuizen>
really fearful are those busy drivers that have 5 contributors each having a few "small" MRs to put in before the branchpoint
<alyssa>
right now I have an MR that's getting closer to 100 commits and... meh
<pepp>
AFAIU Marge processes MRs in order based on when they were assigned. Not based on the last activity on the MR.
<bnieuwenhuizen>
oh, maybe I was wrong then
<alyssa>
this is the "make ES3.1 conformant" series
<alyssa>
only regresses perf by a zillion %
<jekstrand>
karolherbst: Come on. Stupid ideas are the best. :P
<Venemo>
pepp: is there a way to tell which is actually happening?
<alyssa>
Joking aside I do wonder what the net effect of different trees for different subsystems would be
<alyssa>
It violates my sense of upstream-first purity
<alyssa>
and it would complicate whole-tree refactors
<bnieuwenhuizen>
oh it is configurable, lets see what it is set at
<alyssa>
so those 2 reasons alone are probably NAKs on the idea
<imirkin>
has anyone played with oftc's ability to have multiple nicks identify as the same nick?
libv has quit [Ping timeout: 480 seconds]
<imirkin>
and if so, how does it work? :)
<Venemo>
imirkin: I don't know by heart, but /msg NickServ help should tell you
<imirkin>
Venemo: i did look at https://www.oftc.net/Services/ which references "linked nicks", but doesn't explain how to make that happen
<bnieuwenhuizen>
imirkin: OFTC is very nickserv help heavy :(
<pepp>
bnieuwenhuizen: indeed, thanks... I'm not sure why we're not using assigned_at instead
<bnieuwenhuizen>
I got the second nick but AFAICT it was mostly useless to link them
<imirkin>
bnieuwenhuizen: the help was pretty spartan when i asked it
<Venemo>
imirkin: I think you need to use GROUP. according to NickServ help: GROUP: Group a nickname to this primary nickname.
<imirkin>
oh whoa
<imirkin>
it gives a different help text when you're registered
<imirkin>
than when you're not
<imirkin>
i was looking at the one before i registered
<imirkin>
sigh
<imirkin>
i see group/etc now
<imirkin>
Venemo: thanks :)
<Venemo>
imirkin: you're welcome!
scubasteve has joined #dri-devel
scubasteve has quit [Remote host closed the connection]
blue__penquin has quit [Remote host closed the connection]
xp4ns3 has quit []
GloriousEggroll has joined #dri-devel
ReimuHakurei has joined #dri-devel
ReimuHakurei has quit [Remote host closed the connection]
<MrCooper>
Venemo: it's the lesser evil than the alternative, which was Marge processing MRs in ascending order of the MR numbers
<Venemo>
MrCooper: isn't there a way to make it just go through them in the order in which we assigned them to it?
<MrCooper>
if there was, and I knew about it, I would have changed it
<Venemo>
ok, good to know
<daniels>
Venemo: the way to tell what is actually happening is to go to https://gitlab.freedesktop.org/marge-bot and you can see exactly what she is processing at that moment in time
<Venemo>
daniels: understood, but I think what I'm really curious about is "when is it going to deal with mine", rather than "what is it doing now"
<MrCooper>
(may also need to update to newer marge-bot)
<bnieuwenhuizen>
oh option is indeed only 6 months old and your MR to update it 11, definitely explains things
tobiasjakobi has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
gouchi has joined #dri-devel
<danvet>
agd5f, amdgpu has some struggle with __aeabi_ldivmod on arm
<danvet>
if you don't have a fix for that already
elongbug has joined #dri-devel
<danvet>
emersion, the internals landed a while ago in 5186421cbfe25 for connector epoch counter
<danvet>
which is why I'm surprised about your "roll it out by hand" approach
<emersion>
oh, so it's already there?
<danvet>
just internally
<emersion>
so gluing things together should be trivial?
<danvet>
maybe not consistently for drivers that hand-roll their probe code
<danvet>
it's kms, there's guaranteed to be a surprise
<emersion>
i915 hand-rolls too right?
<danvet>
but should be a lot less pain that rolling it out by hand
<danvet>
yeah, but i915 added this, so good chances it works there already :-)
<emersion>
hm
<emersion>
well, i'll see if i have time to mess around with all of that
<emersion>
not sure it'll be that simple
randomher0 has quit []
elongbug[m] has joined #dri-devel
<danvet>
simpler than rolling it out by hand to all drivers at least
elongbug[m] has left #dri-devel [#dri-devel]
<imirkin>
daniels: thanks for re-re-re-re-reassigning MR's to marge :)
<daniels>
yw
<anholt>
today my plan is finish up the piglit subtests support (last minute bugfix needed a rebuild of the container), then go see about fixing up serial issues with watchdog stuff for pre-cheza.
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<daniels>
anholt: nice, thanks! any idea what's going on with the trace fails?
<anholt>
daniels: trace fails are the async flushes are busted in freedreno, the more-async-flush MR caught them, it got smashed to retry, and we've been suffering since.
<anholt>
there's an MR open from robclark trying to fix it, but it's hard
<daniels>
yeah, makes sense - wonder if it's worth skipping until it's done?
gareth__ has joined #dri-devel
gareth__ has quit [Remote host closed the connection]
<anholt>
I would rather we back out the commit that broke things until drivers are ready
<anholt>
it's a real failure
<daniels>
that works too
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
Danct12 has quit [Quit: Quitting]
lemonzest has quit [Quit: Quitting]
ella-0 has joined #dri-devel
zackr has joined #dri-devel
<agd5f>
danvet, thanks, I'll take a look. Got a link?
<danvet>
agd5f, only just noticed now here while compile testing on arm
<danvet>
but I didn't double-check with your latest -next tree, maybe it's just some local combo or mismerge from trees
jrayhawk has quit []
jrayhawk has joined #dri-devel
jrayhawk has quit []
jrayhawk has joined #dri-devel
jrayhawk has quit []
jrayhawk has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<emersion>
danvet, so you'd accept the series if i add the logic in drm_helper_hpd_irq_event?
pekkari has quit []
<danvet>
well I'll go audit all the current uevents we have
<danvet>
also I'm backlogged real bad on everything :-/
ngcortes has joined #dri-devel
aswar002 has joined #dri-devel
Guest8 is now known as pmoreau[m]
aswar002 has quit []
aswar002 has joined #dri-devel
aswar002 has quit [Remote host closed the connection]
<emersion>
i mean, it's nbd if the CONNECTOR prop isn't set for some uevents where it could be set
iive has joined #dri-devel
<emersion>
that could happen anyways if two connectors are updated at the same time
* emersion
gives up
<danvet>
emersion, so what I thought off would be roughly
<danvet>
1. every time we generate an uevent we cache the connector epoch
<danvet>
2. and compare against the previous one, if there's only one connector that's changed, we set that one in the CONNECTOR uevent as a hint
<emersion>
i've typed up (2), but i won't type up (1)
<danvet>
how do you do 2 without 1?
<danvet>
in each caller?
<emersion>
on amdgpu the uevents are in general not grouped, they are already per connector
<danvet>
ah right
<emersion>
in drm_helper_hpd_irq_event, you can easily do the fancy if (single connector updated) logic
<danvet>
so just drm_helper_hpd_irq_event left?
<emersion>
i haven't touched other drivers
<anholt>
daniels: is new gitlab-lava-runner going to be able to kill the lava job when we cancel the job in gitlab ui?
<emersion>
sorry for being lazy :P
<daniels>
anholt: ooh that’s a good point, must make sure it does
<anholt>
as someone who's submitted some pipelines that I've canceled, I've been thinking about it.
reductum has quit []
reductum has joined #dri-devel
<anholt>
(trying to get the expectations all sorted for piglit subtests)
<danvet>
emersion, so I've done a very quick look
<danvet>
most of the candidates beyond probe helpers are actually in drm/bridge
<danvet>
and then a few true horrors
<danvet>
like "let's hotplug a bridge" in exynos
reductum has quit []
<danvet>
so I'd say fix up probe helper and good enough
<emersion>
drm_bridge_connector_hpd_cb is easy too
<emersion>
since there's a single connector in there
reductum has joined #dri-devel
<danvet>
emersion, well I looked at bridge drivers
<danvet>
they do some funny stuff
<danvet>
pinchartl, ^^
<emersion>
i915 has its custom i915_hotplug_work_func func
<emersion>
do i need to hold a lock for a drm_connector?
libv_ has quit [Ping timeout: 480 seconds]
libv has joined #dri-devel
elongbug has quit [Remote host closed the connection]
soreau has quit [Quit: Leaving]
soreau has joined #dri-devel
<danvet>
emersion, where for what?
<emersion>
to iterate over the connector list, i lock the mode_config
<danvet>
not needed
<emersion>
once i've grabbed a pointer to a drm_connector, can i just use it after releasing the lock?
<danvet>
drm_connector_list_iter_begin and friends
<danvet>
no
<danvet>
so the lock actually does nothing for you
<danvet>
you need this iter thing
<emersion>
yeah yeah, so the iter thing locks automatically, but i still want to use the drm_connector outside of the loop
Asbestos_Vapor has joined #dri-devel
<emersion>
… and the existing uevent functions are spec'ed to be called "without any lock"
Asbestos_Vapor has quit [Remote host closed the connection]
<danvet>
drm_for_each_connector_iter <- kerneldoc here tells you what to do
<danvet>
we should probably duplicate this to _next() too
<danvet>
since that's where I looked first
<danvet>
beyond the refcount, no locking needed
<emersion>
ah, thanks
<danvet>
emersion, volunteering for the kerneldoc patch for drm_connector_list_iter_next()?
<danvet>
that's a pretty bad oversight I've done there :-(
rmaw has joined #dri-devel
rmaw has quit [Remote host closed the connection]
libv_ has joined #dri-devel
randomher0 has joined #dri-devel
mbrost has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
rasterman has quit []
shankaru1 has quit []
ngcortes has quit [Remote host closed the connection]
tagr has quit [Ping timeout: 480 seconds]
tagr has joined #dri-devel
tarceri_ has joined #dri-devel
tarceri has quit [Remote host closed the connection]
luzipher has joined #dri-devel
libv_ has quit [Ping timeout: 480 seconds]
libv has joined #dri-devel
ngcortes has joined #dri-devel
rasterman has joined #dri-devel
libv_ has joined #dri-devel
<daniels>
jenatali: amazing just-in-time save earlier, thankyou
<jenatali>
daniels: Hah, coincidence. Glad I happened to look just in time to catch an a630 flake
<daniels>
I was watching but think I might’ve been about 30sec too late had you not noticed!
libv has quit [Ping timeout: 480 seconds]
luzipher_ has joined #dri-devel
DrNick is now known as DrNick2
luzipher has quit [Ping timeout: 480 seconds]
DrNick2 has quit []
DrNick2 has joined #dri-devel
DrNick2 has quit []
DrNick has joined #dri-devel
<robclark>
jenatali, daniels: traces or piglit glx flake? !11278 should help
<jenatali>
robclark: It was a trace
<robclark>
so the glx tests and glmark2 traces are exposing a problem w/ async flush MR.. !11278 reverts it.. I'm becoming increasingly convinced that is the right solution
geonic17 has joined #dri-devel
geonic17 has quit [autokilled: spambot. Dont mail support@oftc.net with questions (2021-06-09 20:42:51)]
<alyssa>
the zmike solution seems to work
<zmike>
robclark: good sleuthing
Anorelsan has joined #dri-devel
mattrope has quit [Remote host closed the connection]
ScorchedMuffin has joined #dri-devel
ScorchedMuffin has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-09 20:52:30)]
<zmike>
robclark: btw have you had a chance to check out my tc rebind thing?
<robclark>
not yet.. had a kernel fire, and then a CI flake fire ;-)
<zmike>
kk np
Duke`` has quit [Ping timeout: 480 seconds]
<robclark>
zmike: ok, I'll slap on fixes tag if that is cool by you
<zmike>
robclark: 👍 and ab me
<robclark>
thx, done
<zmike>
nice
<zmike>
glad it wasn't something more complex
<robclark>
well, I did fine a driver issue or two as well in the process.. having multiple threads drawing to same render target with no synchronization exposed some interesting conditions
<zmike>
yea that test is kinda wacky
<robclark>
glmark2 is doing something similar with multiple contexts and one thread, which is I think why we saw similar flakes show up on those ones in a630-traces
<zmike>
huh really?
<zmike>
which case?
<robclark>
any of the glmark2 traces.. it seems to create a ctx, and do some clears, and then create a per-scene context drawing to same render target
<alyssa>
that might explain why glmark2 breaks so bad on macOS unless you pass --reuse-context
<zmike>
so just running glmark2 directly should trigger such things then?
<robclark>
(or at least I think that is what is going on, I didn't dig into glmark2 code)
<robclark>
I *think* you'd only noticed if you ran for a single or only a few frames.. otherwise later frames would cover up the mess
<zmike>
ah
NiksDev has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
<alyssa>
oh boy
<alyssa>
nothing like a race
<alyssa>
vroom vroom
shankaru1 has joined #dri-devel
pcercuei has quit [Quit: dodo]
Lucretia has quit [Ping timeout: 480 seconds]
Lucretia has joined #dri-devel
rasterman has quit []
rasterman has joined #dri-devel
Tuxel8 has joined #dri-devel
Tuxel8 has quit [Remote host closed the connection]
aswar002 has joined #dri-devel
aswar002 has quit []
aswar002 has joined #dri-devel
andrey-konovalov has quit [Ping timeout: 480 seconds]
Anorelsan has quit [Quit: Leaving]
<jekstrand>
zmike: Do you ever run Zink on a mobile tiling GPU?
<jekstrand>
zmike: Curious about the perf there
<zmike>
jekstrand: no
<zmike>
I've heard rumors that turnip perf is ok
<robclark>
I suppose I should try again, since it was quite a while back (before zink TC landed, I think).. but gl_driver2_off w/ zink on turnip was pretty bad
<alyssa>
zmike: jekstrand would like to write a Vulkan driver for Vivante RTXlake A628-GCN
<jekstrand>
alyssa: No, I would very much not like to do that.
<alyssa>
jekstrand: It's all the worst parts of all our hardware put together!
<airlied>
I'm going to guess for nearly any ARM platform it'll be better than the vendor drivers and close to mesa
<zmike>
robclark: bookmarked, though I'm not currently looking to expand my platform coverage
randomher0 has quit []
danvet has quit [Ping timeout: 480 seconds]
<robclark>
If you wait a bit, I'd recommend 8GB one instead.. or better the LTE one since they didn't cripple the cpu clock for silly reasons..
<alyssa>
robclark: Sorry, I don't want COVID
<robclark>
don't worry, it is just LTE, you'll have to wait a bit longer for 5G to make it's way into that price bracket
<jekstrand>
But if you had the LTE one, you could have it in CI while you hault it all over town.
<robclark>
exactly :-P
<alyssa>
robclark: But 8G is bigger than 5G, and if 5G already caused COVID-19, I heard 8G will cause COVID-22.
<alyssa>
You can't argue with that. It's science.
<zmike>
don't tell me what to do, that's restricting my freedoms
<robclark>
8G*B*
aswarup_ has joined #dri-devel
<alyssa>
robclark: SHUT UP, IT'S SCIENCE!
<alyssa>
:-p
<robclark>
QED :-P
libv has joined #dri-devel
aswar002 is now known as Guest1495
aswarup_ is now known as aswar002
libv_ has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
<airlied>
jenatali: got a better version of the stencil fallback fix in !11280
* jekstrand
should read more crocus code
<imirkin>
it'll just make you sad
<airlied>
I'm about to drop in some refactorings for gen4
<airlied>
it's all the worst bits of iris combined with all the worst bits of i965
<jekstrand>
Naturally!
<jekstrand>
I do think it's been good to read. I've cought a bunch of little stuff.
<jekstrand>
airlied: Feel free to copy+pasta !11235 now. I'm letting our CI chew through it one more time and then I'm sending it to Marge.
<imirkin>
airlied: probably better to apply the all-Y swizzle at sampler view creation time in the driver, no?
<imirkin>
airlied: the "ABI" is that stencil texture values are splatted across all channels...
<imirkin>
same for depth, iirc
<airlied>
imirkin: oh I forget you mentioned that before I'll look at that
<imirkin>
for depth, this matters in the stupid fixed-function case iirc
<alyssa>
as previously discussed - imirkin is correct and yes it's stupid and annoying in lots of drivers but at this point good luck trying to turn the titanic and break all the drivers without CI
aravind has joined #dri-devel
shankaru1 has quit []
shankaru1 has joined #dri-devel
Guest1495 has quit []
aswar002 has quit [Quit: Leaving]
aswar002 has joined #dri-devel
aswarup_ has joined #dri-devel
aswarup_ has quit [Remote host closed the connection]
aswar002 has quit []
aswar002 has joined #dri-devel
aswarup_ has joined #dri-devel
aswar002 has quit []
aswarup_ is now known as aswar002
<robclark>
and !11278 landed without a single flake.. that should fix recent -traces and glx flakes for drivers using TC
<zmike>
\o/
<alyssa>
woo!
<alyssa>
Do I have an excuse to grow my 100 patch stack on top of main instead of merging?
<robclark>
depends on how many flakes you are adding?
<alyssa>
Ah, dinner, that's a good excuse, ttfn
<alyssa>
:p
<alyssa>
robclark: TBD.
<robclark>
heheh
<alyssa>
I have a mode for CI that turns GPU faults (incl. page faults) into crashes
<alyssa>
so that eliminates a major source of flake
<alyssa>
(and is very useful locally for dEQP debug, since I frequently forget to check dmesg otherwise!)
<robclark>
a5xx has a mode that turns faults into crashes too.. it's call arm-smmu :-P
aswar002 has quit [Quit: Leaving]
aswar002 has joined #dri-devel
aswar002 has quit []
aswar002 has joined #dri-devel
aswarup_ has joined #dri-devel
aswar002 has quit []
<jekstrand>
One day, we'll turn that on. Unfortunately, our caches really like to over-fetch.
aswarup_ is now known as aswar002
pnowack has quit [Quit: pnowack]
<airlied>
imirkin: okay just fixed it in the backend now, so the mr just adds the sampler view now
iive has quit []
<imirkin>
airlied: i'm not a u_blitter expert, but sounds good to me