<chewitt>
using the same combination of reverts and changes that had Kodi working (with black text) before
davidlt has joined #panfrost
guillaume_g has joined #panfrost
davidlt has quit [Ping timeout: 248 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
guillaume_g has joined #panfrost
chewitt has quit [Ping timeout: 245 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
guillaume_g has joined #panfrost
raster has joined #panfrost
raster has quit [Remote host closed the connection]
<guillaume_g>
While trying kmscube on exynos, it fails with "MESA-LOADER: failed to open exynos (search paths /usr/lib/dri)" but I guess it should try to load panfrost, no?
<daniels>
guillaume_g: panfrost (for the GPU rendering) needs integration with exynos (for the display output) through the mesa 'kmsro' driver
<daniels>
atm this requires patching mesa so that the kmsro driver also exposes panfrost; you will probably also need to port changes from a downstream vendor tree so the kernel driver knows how to power on and reset the GPU
<daniels>
ah wait, exynos already has kmsro support. did you build Mesa with -Dgallium-drivers=panfrost,kmsro?
<guillaume_g>
daniels: I do not have kmsro part
<daniels>
guillaume_g: ok, you need to enable kmsro in your build
raster has joined #panfrost
<guillaume_g>
daniels: added it now, it is rebuilding. Thanks for this info :)
raster has quit [Quit: Leaving.]
raster has joined #panfrost
raster has quit [Quit: Leaving.]
guillaume_g has quit [Ping timeout: 245 seconds]
guillaume_g has joined #panfrost
raster has joined #panfrost
davidlt has joined #panfrost
davidlt has quit [Read error: Connection reset by peer]
davidlt has joined #panfrost
raster- has joined #panfrost
raster has quit [Quit: Leaving.]
raster- has quit [Remote host closed the connection]
<tomeu>
I think you need some of the stuff that was guarded by is_t6xx, because you are running on 32bit
<tomeu>
that branch should take care of that
<alyssa>
chewitt: I'm building latest Kodi master now
<chewitt>
tomeu: so that branch should run 32-bit without our hacky sed(s)?
<chewitt>
or we need to config something?
<alyssa>
Yeah
<alyssa>
chewitt: With that branch, you can just drop the panfrost patching entirely
<alyssa>
And itought to just work
<chewitt>
ohh .. shiny
<chewitt>
i'll test this evening
<alyssa>
...What time is it where you again? :p
<chewitt>
i'm in the UK at the moment so 4.16pm
<chewitt>
back to the sandpit in ~8 days
<alyssa>
:+1:
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
<alyssa>
Kodi takes a long time to build, huh
<chewitt>
depends what you build it on :)
<alyssa>
My RK3399 laptop that I use to build Mesa round the clock ;p
<chewitt>
I can normally re-spin an LE image with a Kodi change in ~60 seconds
<alyssa>
Yeah, but that's a partial rebuild
<alyssa>
I'm going from clean
<chewitt>
full OS image (240 packages) takes 28 mins
<chewitt>
clean build
<chewitt>
clean Kodi is ~2 mins
<jernej>
chewitt: which CPU you have?
<chewitt>
AMD TR2 with 16x Cores (32 Threads)
<chewitt>
plus fast I/O
<jernej>
ok, then I will certainly look into buying AMD 3900X in a month or two + NVMe
<chewitt>
cross-compile is the way to go
* alyssa
rathers like working all on-board
<alyssa>
Except for building Kodi, I guess
<alyssa>
63% blues
<alyssa>
74%, I guess this might be speeding up? :P
raster has joined #panfrost
<chewitt>
i'm definitely not as patient as you :)
<alyssa>
chewitt: Build finished (I had to patch a tiny GBM thing but no rendering changes)
<alyssa>
Latest Kodi master works fine on RK3399 with latest Panfrost master
<chewitt>
white text?
<alyssa>
(Text is the correct colour)
<chewitt>
okay, thanks
<alyssa>
So that rules out Kodi changes as the cause
<alyssa>
And means it's specifically something related to T820 or 32-bit
<alyssa>
So I think tomeu/always-64 may well fix things for you
<chewitt>
I'm picking the patches to prep a test image .. it will be a few hours before I can unpack a board and connect it to a TV though
<alyssa>
OK
<alyssa>
I'll be here :)
<alyssa>
I will note, Kodi 19 / master / GBM is *substantially* slower than Kodi 18 / Debian / X11
<alyssa>
(Latest Panfrost for both)
<alyssa>
Not sure what that's about
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
<chewitt>
@alyssa: I can't see whether white text is working (Federer vs. Nadal at Wimbledon is monopolising the single TV) but I booted an image with the 32-bit changes and Kodi runs .. so that's a good sign
<chewitt>
I'll be allowed to switch sources on the TV once one of them loses :)
<alyssa>
Priorities ! :D
<chewitt>
current mesa HEAD (or thereabouts) + 3x commits in the always-64 branch + my hacked kernel driver
<chewitt>
Q: What's the difference between your mother and a terrorist?
<chewitt>
A: You can negotiate with terrorists
<chewitt>
"we will not be switching the telly over"
<alyssa>
Your mum?
<chewitt>
indeed
<alyssa>
"We all have mothers" -robclark
<alyssa>
I never had much luck with perf for various reasons,
<alyssa>
but daniels suggested sysprof, and that is working quite well
<alyssa>
(hello from GNOME, blah blah)
<alyssa>
Findings from Supertuxkart on master:
<alyssa>
- We're spending an obnoxious amount of time computing the scoreboard
<alyssa>
- That's a good bottleneck to have since it's well-understood CPU code; algorithmic improvements are possible to get it down to linear time, I think
<alyssa>
( It's accidentally O(N^2) right now)
<alyssa>
- Creating and releasing bo's seems to happen a lot. That's slow. Don't do it
<alyssa>
- Easy enough to handle since memory usage is sane. We can pool/cache BOs and save a lot of grief.
<alyssa>
- Often times these are transient internal BOs. A huge chunk of time is spent creating BOs for u_vbuf_draw_vbo
<alyssa>
- Does STK use user vbufs and then Gallium is uploading? We might benefit from doing the upload ourselves since transient memory is specially optimized
<alyssa>
Also, given how helpful that was, let's try sysprof on the memory management branch (which is a step forward but regresses perf hence why it's not merged)
<alyssa>
Gotta say, this is a super exciting capability to have
<alyssa>
If we can tackle CPU side bottlenecks and CPU-GPU shared bottlenecks, that's... 80% of the battle
<chewitt>
@alyssa: black text :(
<alyssa>
chewitt: Fudge.
<chewitt>
(they left the room to make tea)
<alyssa>
chewitt: What am I missing here.... Hrm
<alyssa>
RK3399 64-bit is perfectly happy on identical Kodi
<alyssa>
chewitt: Well, if it doesn't outright regress everything, that's still a good sign
<alyssa>
Text colour aside, dropping the LE patches is a win for both of us
<alyssa>
Let's see if my graphics nerd eyes see something you don't uhhh
<alyssa>
Hum
<alyssa>
This is the fix-64 branch hh
<chewitt>
it's mesa master + the last three commits from that branch (which look like the only changes)
<alyssa>
Okay, hm
<chewitt>
I'm also missing a load of kernel driver commits .. I'm basically running the initial 5.2 merge commit and the WIP "soft reset" patch from narmstrong
<alyssa>
chewitt: This is almost certainly a userspace bug, so old kernel is ok :)
<chewitt>
but I don't think those are relevant as this issue was present on 5.1 before
<alyssa>
I just don't understand how this could've worked fine before and regressed without regressing T860
<alyssa>
robher: Not sure if you saw / if this affects you, but tomeu got two things working today (kinda tied)
<alyssa>
- T720 support (good enough to run Weston, FBOs are missing)
<alyssa>
- 64-bit descriptors on T7xx
<alyssa>
The upshot is that in the next few weeks (before the 19.2 branch point in early August), we'll be switching to 64-bit job descriptors everywhere
<robher>
alyssa: nice. Though I only have rk3399.
<alyssa>
Same (well, and RK3288 but out of service right now)
<chewitt>
rebuilding..
<chewitt>
[ 9.536160] panfrost d00c0000.gpu: Fatal error during GPU init
<chewitt>
[ 9.536309] panfrost: probe of d00c0000.gpu failed with error -12
<chewitt>
^ robher
<jcureton>
chewitt: shot in the dark without knowing your full setup off my head, but the line "if (cfg-ias != 48 || cfg-oas > 40)" in io-pgtable-arm.c also has to be changed to "if (cfg-ias > 48 || cfg-oas > 40)" for devices with a smaller mmu bus width
<jcureton>
there was a patch with it on the mailing list at one point but I never saw it merge
<robher>
jcureton: the one I just pasted above...
<jcureton>
robher: the one you posted above ensures a full 4-level pgtable is always returned, it doesn't change the sanity check in allocating a pgtable