<bbrezillon>
alyssa: right now we add an exclusive fence to all BOs passed to the submit ioctl, which means jobs reading the same BO can't run concurrently, but that also means userspace has to wait for all jobs reading this BO to finish (because of the wait_bo() call in transfer_map())
<bbrezillon>
if we add the concept of access type (rw or readonly), we can avoid useless waits in such situations
_whitelogger has joined #panfrost
_whitelogger has joined #panfrost
vstehle has joined #panfrost
fysa has quit []
fysa has joined #panfrost
fysa has quit [Read error: Connection reset by peer]
mani_s has quit [Read error: Connection reset by peer]
mani_s has joined #panfrost
warpme_ has joined #panfrost
guillaume_g has joined #panfrost
warpme_ has quit [Quit: warpme_]
yann has quit [Ping timeout: 246 seconds]
NeuroScr has quit [Quit: NeuroScr]
davidlt has joined #panfrost
yann|work has joined #panfrost
davidlt has quit [Ping timeout: 245 seconds]
warpme_ has joined #panfrost
<alyssa>
Right, okay
<eballetbo[m]>
alyssa, bbrezillon: I saw some patches around panfrost on linux-next for next merge window, there is any possibility that one of them fixes my issue with the artefacts on my external display?
<bbrezillon>
eballetbo[m]: I can't tell, I guess it's worth a try :)
* eballetbo[m]
was trying to avoid build linux-next after few days of holidays :-P Yeah, worth give a try
guillaume_g has quit [Quit: Konversation terminated!]
<narmstrong>
tomeu: but I needed to tweak the job definition, we use u-boot boot method
<narmstrong>
but now I have a weird `[ 16.014376] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038` in drm_sched_increase_karma :-/
megi has joined #panfrost
<tomeu>
narmstrong: guess it could be a regression in gpu-sched
<tomeu>
tomorrow I need to do some mesa and kernel debugging I guess
<tomeu>
one goes away a few days and everything starts breaking
<alyssa>
Relatable
<alyssa>
TBF everything is breaking when I'm not away too
<mmind00>
tomeu: easy solution, just don't go away :-P
adjtm has quit [Ping timeout: 276 seconds]
<HdkR>
Or the sad alternative, be the only person working on a project
<alyssa>
HdkR: Doesn't help when regressions come from common code
<HdkR>
Just write all the code in a vacuum :P
<bbrezillon>
alyssa: ok, I think I filled the gap in -bideas
<alyssa>
Yeah?
<bbrezillon>
there are these wait bo changes I was talking about, plus I now cache the BO status (keep track job accesses so I don't need to call the ioctl() when no job touching this BO is in flight)
<bbrezillon>
and I made the fence gc less agressive
<alyssa>
So kernel update then?
<bbrezillon>
yes
<alyssa>
Ah
<bbrezillon>
but it still works without the kernel changes
<bbrezillon>
(haven't checked the perf penalty in that case though)
<alyssa>
Ok
<alyssa>
I still am not sure why there's a perf penalty without the changes
<alyssa>
The kernel changes should allow even better perf, but why does perf regress between serialized jobs and pipelining/old kernel?
<bbrezillon>
alyssa: because we were lacking flushes
<bbrezillon>
since the BO is never written by the GPU
<alyssa>
Okay..
<bbrezillon>
but removing the exclusive fences when we can is still a good thing
<alyssa>
bbrezillon: Let me make sure i understand -- the perf gap in -bideas was solely due to the overhead of the extra ioctls() which turn out to be no ops, so the solution is to skip the ioctls()
<alyssa>
*not* due to the kernel *actually* waiting on BOs that weren't ready?
<bbrezillon>
alyssa: not only
<alyssa>
(Hence no kernel change is needed to fix the regression?)