<airlied>
strace seems to show it doing something, but it can stay there for a long time
<airlied>
though it's probably up to 1GB in the cache, so maybe its just churning through it all
mbrost has quit [Remote host closed the connection]
<pinchartl>
airlied: do you still accept pull requests for v5.14 ?
<airlied>
pinchartl: in theory no, in practice it depends on how bad it is
<airlied>
like hey I fixed a few things, yeah no problems, hey I rewrote the driver from scratch, less likely
<pinchartl>
it's tiny
<pinchartl>
I'll try my luck :-)
<airlied>
pinchartl: should be fine then
<pinchartl>
I've been really overwhelmed lately, and I'm feeling bad about two patches that have been in my tree for too long, I've missed a merge window already, it's not very nice for the authors
<pinchartl>
but if they cause issues, I'll take the blame
<pinchartl>
I'm currently running tests after a rebase and will send the pull request shortly
ddavenport has quit [Remote host closed the connection]
NiksDev has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
Lightkey has quit [Ping timeout: 480 seconds]
Lightkey has joined #dri-devel
boistordu has joined #dri-devel
plastico has joined #dri-devel
plastico has quit [Remote host closed the connection]
khfeng has joined #dri-devel
boistordu_ex has quit [Ping timeout: 480 seconds]
qtch2 has joined #dri-devel
qtch2 has quit [Remote host closed the connection]
cyberz has joined #dri-devel
nifker has joined #dri-devel
cyberz has quit [Remote host closed the connection]
nifker has quit [Remote host closed the connection]
ddavenport has joined #dri-devel
gpoo has quit [Remote host closed the connection]
gpoo has joined #dri-devel
<tarceri>
airlied: A couple of devs has reported a corrupt cache size in there index file recently resulting in things getting evected even though the actual cache is much smaller than 1G
<airlied>
tarceri: this is still chugging away
<airlied>
I wonder if there is some race condition in theere
<tarceri>
If this has happened to you also I've got not idea what might have caused it. Seems to have been happening over the past month of so
<airlied>
tarceri: it's happened a lot on this machine, but it's a fairly broken machine in terms of having no RAM, a slow disk and btrfs
<tarceri>
airlied: able to go back a few months in git and see if it still happens?
<airlied>
not really, since I only see it testing crocus
macromorgan_ has quit [Remote host closed the connection]
<mareko>
that gfx acronym in intel drivers is confusing, I guess that was Raja's idea
ddavenport has quit [Remote host closed the connection]
<airlied>
tarceri: nope not seeing that
<airlied>
tarceri: I have a full cache
naveenk2 has joined #dri-devel
<airlied>
tarceri: if I get some time I'll try adding some debug prints
xp4ns3 has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
ordnanceman[m|gr has joined #dri-devel
ordnanceman[m|gr has quit [Remote host closed the connection]
<pinchartl>
airlied: actually, the pull request can wait for the next version. sorry for the noise
shankaru1 has joined #dri-devel
thellstrom has joined #dri-devel
SergeyLitvinov-t has joined #dri-devel
SergeyLitvinov-t has quit [Remote host closed the connection]
ddavenport has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
ddavenport has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
pnowack has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
bcarvalho_ has joined #dri-devel
mlankhorst has joined #dri-devel
vivijim has quit [Remote host closed the connection]
itoral has joined #dri-devel
mattrope has quit [Remote host closed the connection]
thellstrom has quit [Remote host closed the connection]
Pavr has joined #dri-devel
thellstrom has joined #dri-devel
Pavr is now known as Guest2489
Guest2489 has quit [Remote host closed the connection]
imre has quit [Remote host closed the connection]
imre has joined #dri-devel
pekkari has joined #dri-devel
shankaru1 has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
skered has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
skered has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-17 06:16:18)]
naveenk2 has quit []
psu-arrays[m|gr] has joined #dri-devel
psu-arrays[m|gr] has quit [Remote host closed the connection]
andrey-konovalov has joined #dri-devel
NiksDev has quit [Ping timeout: 480 seconds]
zyffer has joined #dri-devel
zyffer has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-17 06:45:56)]
dviola has joined #dri-devel
ddavenport has joined #dri-devel
pcercuei has joined #dri-devel
lynxeye has joined #dri-devel
juns has joined #dri-devel
juns has quit [Remote host closed the connection]
naveenk2 has joined #dri-devel
post-factum19 has joined #dri-devel
post-factum19 has quit [Remote host closed the connection]
andrey-konovalov has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
xp4ns3 has quit []
<tarceri>
airlied: I guess we could try deleting more items when the cache is full to avoid thrashing. It's never really been identified as a problem before
<MrCooper>
I was just thinking in a similar direction :)
bcarvalho_ has quit []
bcarvalho has joined #dri-devel
asix has joined #dri-devel
asix has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
ddavenport has quit [Remote host closed the connection]
aravind has joined #dri-devel
rasterman has joined #dri-devel
benpa[m]2 has joined #dri-devel
benpa[m]2 has quit [Remote host closed the connection]
vivijim has joined #dri-devel
DennisSmith47 has joined #dri-devel
DennisSmith47 has quit [Remote host closed the connection]
gimmemahlulz has joined #dri-devel
gimmemahlulz has quit [Remote host closed the connection]
aligator123 has joined #dri-devel
aligator123 has quit [Remote host closed the connection]
autra_tl has joined #dri-devel
RobertC has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
autra_tl has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-17 09:51:27)]
nemanjan00 has joined #dri-devel
MrCooper has joined #dri-devel
nemanjan00 has quit [Remote host closed the connection]
dviola has quit [Quit: WeeChat 3.2]
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
djinni has joined #dri-devel
djinni has quit [Remote host closed the connection]
cetchmoh has joined #dri-devel
cetchmoh has quit [Remote host closed the connection]
gouchi has joined #dri-devel
gouchi has quit []
Laskolnyk has joined #dri-devel
Laskolnyk has quit [Remote host closed the connection]
andrey-konovalov has joined #dri-devel
<tjaalton>
any idea what's going on with 21.0.x?
naveenk2 has quit [Ping timeout: 480 seconds]
<tjaalton>
ton of commits on the staging branch but no release in two months now
jernej_ has joined #dri-devel
jernej has quit [Read error: Connection reset by peer]
Ark-M has joined #dri-devel
Ark-M has quit [Read error: Connection reset by peer]
itoral has quit [Remote host closed the connection]
<bbrezillon>
the thing is, all drivers I've looked at have the fence context created globally (one context per HW-queue), so all open-FD share the same context. Now say you have a queue that has 2 slots, the first slot is filled with a faulty job coming from FD N, and the second slot is filled with a valid job coming from FD M. Since the fence context is global, the second job will be evicted
<bbrezillon>
to
<bbrezillon>
*too
itoral has joined #dri-devel
<bbrezillon>
is that expected?
<bbrezillon>
(just to clarify, what I call slots is the ->hw_submission_limit value in this context)
itoral has quit []
<lynxeye>
bbrezillon: The karma is per sched_entity and every FD should have its own instance of that.
<bbrezillon>
right, but the fence context is global, so, if the first job on the HW queue cause a HW fault, the HW queue context will be marked as guilty, and the job coming from a different file context will be considered as guilty too (this is what I see when setting hw_submission_limit to 2 in panfrost)
<bbrezillon>
this being said, the sched timeout seems to be reset after each job submission, so I guess the core expects both jobs to have expired if a timeout occurs
naveenk2 has joined #dri-devel
<bbrezillon>
that doesn't work well with how Midgard/Bifrost deal with HW queueing though, because the second job only starts after the first one is finished
<bbrezillon>
lynxeye: maybe I'm missing something
khfeng has quit [Remote host closed the connection]
khfeng has joined #dri-devel
<lynxeye>
bbrezillon: This sounds wrong. The job should get a fence context from the sched_entity, so if a job times out only the this sched_entity should be marked as guilty.
<lynxeye>
The HW queue fence context should have nothing to do with throwing out jobs.
<mripard>
danvet: assuming that we need to access a CRTC state that isn't part of the state being committed, and for any commit, no matter the flag
<mripard>
is it valid to just access the crtc->state in that case?
<lynxeye>
bbrezillon: See drm_sched_job_init. Each job gets a fence on the timeline/context of the submitting sched_entity. If each FD has its own entity (which it should have, as otherwise you don't have runqueues to schedule), different FDs should not have an influence on each other.
<mripard>
one use case that we currently have is that we have to raise and lower a clock for the controller that does the composition
<mripard>
so it tries to estimate the load generated by the planes and crtcs for each commit
<mripard>
but it really doesn't need anything else from all the CRTCs than their current mode
<danvet>
mripard, uh
<danvet>
mripard, I think the answer is "it's complicated"
<danvet>
we should probably have a howto section in the docs explaining this
NiksDev has quit [Remote host closed the connection]
<danvet>
but the usual trick if you need to have some aggregate data, but don't want to just always take all the locks (because that's bad due to overserialization, of which spurious ebusy is just one)
<danvet>
is that you do a read-only copy of everything you need in a private state object
<danvet>
so 1) create private state for your clocks/bw limit/whatever
<danvet>
2) put copies of any derived state you need to compute you bw into that private state
<danvet>
3) every time a source state (plane, crtc, whatever) changes some value that impacts what you store in 2) you grab that private state in atomic_check and update it
<danvet>
4) at the end of your overall atomic_check you validate that private state stuff, and check whether there's anything you need to change
<danvet>
5) the usual lolz about synchronizing private state correctly applies
<danvet>
for the case where you do have to change hw, i.e. you need to have a drm_crtc_commit or so and subsequent commits need to wait for this
<danvet>
it all gets rather messy
<mripard>
danvet: ok, so that would be fairly easy, we already have most of the infrastructure in vc4 to deal with this
<bbrezillon>
lynxeye: what I see here is that `s_job->s_fence->scheduled.context == guilty_context` is true for 2 jobs coming from 2 different FDs
<danvet>
mripard, the "I just read ->state" is the yolo solution that relies on userspace not doing untimely nonblocking commits of stuff spawning crtc or planes or whatever
mlankhorst has quit [Ping timeout: 480 seconds]
<mripard>
my understanding was that we couldn't have multiple commits in parallel once drm_atomic_helper_wait_for_dependencies has run, so anything after that was fine?
<bbrezillon>
lynxeye: ok, nvm, drm_sched_fence_create() passes an entity context to dma_fence_init(), so I don't know what's happening in my case
<bbrezillon>
I'll keep digging
<lynxeye>
bbrezillon: Hm, are those fds dup'ed?
<bbrezillon>
lynxeye: actually no, I was just not using the second FD in my testcase :facepalm:
<bbrezillon>
no it fails, but for a different reason
<lynxeye>
bbrezillon: He, good luck!
<bbrezillon>
lynxeye: thanks for your help
pq has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
AimHere has joined #dri-devel
AimHere has quit [Remote host closed the connection]
T_UNIX has joined #dri-devel
<T_UNIX>
hi
macromorgan has joined #dri-devel
<T_UNIX>
am I understanding correctly, that after closing the fd, the video memory is reset to its former content when using libdrm+dumb buffer, while it's not when using `/dev/fbX` directly?
vawl[m|gr] has joined #dri-devel
vawl[m|gr] has quit [Remote host closed the connection]
aravind has quit []
<MrCooper>
video memory is never reset to former content; do you mean whether or not the FB being scanned out is restored?
alyssa has left #dri-devel [#dri-devel]
<danvet>
T_UNIX, with drm interface you should get cleared memory only (exceptions apply with amdgpu and maybe nouveau, not sure)
<danvet>
while /dev/fbX keeps the same memory between all users and never clears it
<danvet>
ofc if fbcon clears it then it also gets cleared, but fbcon is just another (in-kernel) client
<T_UNIX>
hm.. okay.. then fd passing it is, I guess.
<T_UNIX>
danvet: thank you
<T_UNIX>
but then the content should stay until another client opens the device, correct?
<danvet>
T_UNIX, for fbdev or drm?
<danvet>
also I strongly recommend to not build new userspace on top of fbdev
hch12907 has quit [Remote host closed the connection]
<T_UNIX>
<danvet "also I strongly recommend to not"> for drm
<T_UNIX>
sure. That's why I mentioned fd passing. A subsequent application is taking too long to start up.
<danvet>
mripard, two crtc can run in parallel still
<danvet>
if they don't share anything else
<mripard>
ah, right
<danvet>
but if you use your private share to order them, then not
<danvet>
order with a drm_crtc_commit
hch12907 has joined #dri-devel
idr has joined #dri-devel
mattrope has joined #dri-devel
<mripard>
yeah, we have that in place in vc4 already, it's why I forgot about it
<mripard>
thanks :)
SayanChowdhury[m has joined #dri-devel
SayanChowdhury[m has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-17 14:58:54)]
mbrost has joined #dri-devel
<Venemo>
jekstrand maybe I misunderstand what vectorized means, but I think that sad_u8x4 isn't vectorized
<Venemo>
maybe I made a mistake when I added it
luzipher_ has joined #dri-devel
<cwabbott>
Venemo: i think jekstrand misread sad_u8x4 as usadd_8x4
<cwabbott>
the first isn't vectorized, the second is
<Venemo>
okay, that's possible
luzipher has quit [Ping timeout: 480 seconds]
<jekstrand>
Venemo: I also made a bit of a mistake in my first is_vectorized()
<Venemo>
what does it mean, though? I assumed that it means that the op works on vec types
<jekstrand>
There's now a glossary and I just updated the link in the subject to a new build. :)
<Venemo>
would be nice if we could figure out a way to add some textual documentation to each opcode too. but what you have is already very nice
<jekstrand>
Yeah, I'd like to get there. The problem is mechanics.
jernej_ is now known as jernej
<jekstrand>
Python has docstrings where there's a """string""" in a specific place and we tools can scrape that out somehow.
<jekstrand>
Maybe we could do something like that? I don't know.
<jekstrand>
I'd like to at least have the option to put in such docstrings. We just need to figure out the mechanics.
<HdkR>
Oh. Apparently the llvmpipe issue where it created threads in every vulkan context was fixed?
Duke`` has joined #dri-devel
minecrell has quit [Quit: Ping timeout (120 seconds)]
<imirkin>
jekstrand: fwiw the docstring has nothing to do with """ -- it's just the first string in the function. """ is a convenient way to make multi-line strings
<imirkin>
if it's a short docstring, you can just do "foo", and the tools should still pick it up
<cwabbott>
wouldn't it be tricky to identify the function with the entry in nir_opcodes?
<cwabbott>
usually the function name is the same, but it's not like anything enforces that
<jekstrand>
cwabbott: I was just referring to a semantically nice way to do it
<jekstrand>
cwabbott: We could also have a named doc= parameter
<cwabbott>
actually, we don't really have functions anyways
<cwabbott>
every opcode is just a call to opcode() or something else that calls it
<cwabbott>
and sometimes functions generate multiple opcodes...
sdutt has joined #dri-devel
minecrell has joined #dri-devel
Martin[m]12 has joined #dri-devel
yanmaani6 has joined #dri-devel
yanmaani6 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-17 15:58:03)]
Martin[m]12 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-17 15:58:14)]
alyssa has joined #dri-devel
<alyssa>
Xorg crashes with `Killed` whenever I try to start x11vnc
<alyssa>
ugh...
<imirkin>
alyssa: try running X with -noreset
<alyssa>
imirkin: no dice
<imirkin>
that's the end of my bag of tricks
<alyssa>
heh
<imirkin>
more of a sachel...
<alyssa>
X11 was crashing whenever trying to start a DE too, or a web browser, or...
<alyssa>
not sure if this is a gfx driver thing or I just corrupted my rootfs that badly
<alyssa>
oh man, if I disable glmaor it crashes on startup
<alyssa>
gonna say not a gfx driver bug...
GloriousEggroll has joined #dri-devel
<alyssa>
SIGKILL on start-up, wat.
<imirkin>
are you accidentally hitting ^C?
<imirkin>
every time :)
<alyssa>
I don't.. think so?
<imirkin>
(and if you were, it'd a SIGTERM...)
<urja>
lol (that'd be SIGINT also)
Duke`` has quit [Read error: No route to host]
<alyssa>
no, it's immediate on start-up with glamor disabled. wat.
<imirkin>
alyssa: gdb time? although word of advice ... do it over ssh
neonking has joined #dri-devel
<alyssa>
I am over ssh
<alyssa>
gdb doesn't show anything other than SIGKILL
<alyssa>
Program terminated with signal SIGKILL, Killed.
<alyssa>
The program no longer exists.
<imirkin>
while true; do killall -9 Xorg; done
<imirkin>
left one of those running somewhere?
<imirkin>
:)
<imirkin>
(sorry, i just have nothing useful to add. i'll keep quiet.)
<alyssa>
heh
<alyssa>
fsck says the rootfs is clean, dunno how much that really means
<alyssa>
there's not much on the rootfs other than, like, deqp and piglit and stuff
<alyssa>
I guess I could try reinstalling
<alyssa>
and if it's /still/ broken ... well idk what then
<alyssa>
then again if the eMMC is sketchy...
* alyssa
debootstraps
naveenk2 has quit []
luzipher__ has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
luzipher_ has quit [Ping timeout: 480 seconds]
shankaru1 has joined #dri-devel
gouchi has joined #dri-devel
* ccr
slowly spins around, like a progress indicator.
shankaru1 is now known as shankaru
<imirkin>
that's like 95% of being a software engineer ... watching progress bars
<alyssa>
the other 5% is LARPing in the hallway while ignoring a progress bar
<imirkin>
heh
<ccr>
you stare at the screen long enough, you become a progress bar
<alyssa>
that's dark
<alyssa>
The Maccabeats foreshadowed Windows installers by thousands of years.
<alyssa>
For 8 nights the progress bar remained at 99%
* ccr
shudders
<jekstrand>
alyssa: Hezekiah's got that beat. It went backwards for him. :)
<alyssa>
heh
<alyssa>
Now for today's dose of "why won't this board boot?"
<danvet>
jekstrand, did you see the doc polish idea from pq?
<alyssa>
Answer: Internal storage was removed
<ccr>
hmmm :D
<alyssa>
Question: why can't I log in ?
<alyssa>
Answer: did not set a password
khfeng has quit [Ping timeout: 480 seconds]
<karolherbst>
uhm.....
<karolherbst>
simple_mtx_t isn't data race free :/
<alyssa>
uh oh
<alyssa>
oh cool this thing has 3D acceleration out of the box
<alyssa>
20.3 is ancient but like, it works :-p
<karolherbst>
simple_mtx_unlock mtx->val = 0; and simple_mtx_lock race obviously :)
<HdkR>
Good enough for some basic windows
<karolherbst>
although it shouldn't be an actual race?
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<jekstrand>
danvet: Yeah, I saw that. Haven't fixed up the patch yet.
<danvet>
mauld, just realized that there's no include directive in i915.rst to pull in your kerneldoc
<danvet>
would be good to fix that (but I guess it's going to be some work to replace all the /** from misformatted comments to /* until we can fix them)
<danvet>
mauld, also I guess the temporary fake headers in gpu/rfc should be deleted now
<danvet>
mauld, I'd say the entire lmem uapi section can probably be deleted from i915_gem_lmem.rst
<danvet>
and just leave the upstream plan there
<danvet>
except if we haven't done it all yet
* danvet
not sure about set/get_caching
Duke`` has joined #dri-devel
pcercuei has joined #dri-devel
<alyssa>
ok. This is a clean install of Debian, a clean build of Mesa, everything straight from apt. Why won't X11 start?!
<imirkin>
i think it's trying to tell you something.
<alyssa>
lol
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
<alyssa>
Ok, err
dllud has quit [Remote host closed the connection]
<alyssa>
If I just start `X` alone that's fine
dllud has joined #dri-devel
<alyssa>
and over ssh, I can manually start glxgears or mate-terminal and that works fine
<alyssa>
but -- again manually over ssh -- trying to start i3 or openbox crashes X
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
ngcortes has joined #dri-devel
pcercuei has quit [Quit: Lost terminal]
pcercuei has joined #dri-devel
imirkin has quit [Quit: Leaving]
DrNick has quit []
spudly has joined #dri-devel
spudly has quit [Remote host closed the connection]
DrNick has joined #dri-devel
chjj has joined #dri-devel
chjj has quit [Remote host closed the connection]
ngcortes has quit [Ping timeout: 480 seconds]
enilflah has left #dri-devel [#dri-devel]
halfline has joined #dri-devel
pekkari has quit []
notgull has joined #dri-devel
imirkin has joined #dri-devel
beefcadet has joined #dri-devel
luzipher_ has joined #dri-devel
beefcadet has quit [Remote host closed the connection]
bcarvalho has quit [Quit: Leaving]
rasterman has quit [Quit: Gettin' stinky!]
luzipher__ has quit [Ping timeout: 480 seconds]
jernej_ has joined #dri-devel
jernej has quit [Read error: Connection reset by peer]
jernej_ is now known as jernej
ngcortes has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
rasterman has joined #dri-devel
thellstrom has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
sh_zam has quit []
sh_zam has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Duke`` has quit [Read error: No route to host]
pnowack has quit [Quit: pnowack]
andrey-konovalov has quit [Ping timeout: 480 seconds]
<airlied>
danvet: I'll try to avoid backmerging it then
jernej has joined #dri-devel
luzipher__ has joined #dri-devel
luzipher_ has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
<jekstrand>
daniels, kusma: Could I get either an ack or an opinion on the first patch of the ISL docs MR? We had a thread going but it sort-of died.
illwieckz has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
<alyssa>
is -1 necessarily an eperm issue or am i just doing something stupid.
<alyssa>
questions ....
<airlied>
-1 as ret or -1 as errno?
<alyssa>
as ret
<airlied>
if from an ioctl, it just means check errnor
<alyssa>
though maybe also errno? idk it's been a long day filled with android, I am not a happy camper
<alyssa>
errno 11
danvet has quit [Ping timeout: 481 seconds]
<airlied>
EAGAIN?
<alyssa>
errno 11
<alyssa>
:-p
<Kayden>
alyssa: you usually don't want to call ioctl directly for drm stuff, you want to use drm_ioctl which is copy/pasted as intel_ioctl in mesa if you want to steal it
<Kayden>
it just handles the EAGAIN loop
<alyssa>
Kayden: trying to bitbang the proprietary driver on android phone