<tomeu>
but even then, we should probably put a limit on the size of the cache
<tomeu>
alyssa: regarding use of glReadPixels to composite webgl surfaces, that seems to be because gtk only supports non-shared ES2 contexts
<tomeu>
and creation of GL contexts fails, I guess due to some missing format or so
<tomeu>
next step would be finding out why exactly context creation fails
<tomeu>
guess that will reduce the amount of memory needed as well
raster has joined #panfrost
yann has joined #panfrost
<guillaume_g>
tomeu: using master, panfrost is not selected anymore and it tries to use llvmpipe (tested with kmscube). So, we have a regression compared to 19.1.2
<tomeu>
guillaume_g: on what hw?
<guillaume_g>
tomeu: snow (exynos5250 + t604)
<tomeu>
guillaume_g: yeah, you will have to whitelist that GPU
<raster>
which is the same as on the odroid xu3/4 which is why it just smells so similar
<rtp>
5250 has 604. that's what the HW is saying :)
<raster>
not sure what t604 is about?
<raster>
hmm
<raster>
wikipedia thinks otherwise :)
<raster>
oh wait
<raster>
no 5420
<raster>
not 5250
<raster>
never mind
<raster>
yeah - wikipedia agrees 604.
<raster>
sorry - messed up the number-soup :)
<rtp>
yeah, 5420 is 628 (r0p1 iirc)
<daniels>
snow is exynos 5250 / mali t604, peach-pi is exynos 5420 / mali-t628, peach-pit is exynos 5800 / mali-t628
<daniels>
sorry, got pi and pit the wrong way around
<daniels>
the 5800 in the peach-pi is _almost_ exactly the same as the 5422 in the odroid-xu3
<raster>
too many numbers, code names and ... soup :)
<rtp>
I only remember that because I've a snow and a peach pit. otherwise, I surely won't :)
<daniels>
those devices used to work really well with mainline, but then every release they got broken by tizen changes
<raster>
rtp: haha :)
<raster>
daniels: i notied they partly worked way back - but not that well and it didn't improve so it ended up a good dust collector. :(
<raster>
err i noticed
<rtp>
daniels: yeah but no 3D
<raster>
i ened up having to hit ctrl-d every boot to boot into linux as opposed to chrome-os and that was very irritating.
<daniels>
rtp: indeed
* rtp
thinks it's ctrl-u :)
BenG83 has joined #panfrost
* guillaume_g
removed chromeOS (as it is no more supported) and installed openSUSE Tumbleweed on internal eMMC :) => no more ctrl-u on boot
jcureton has joined #panfrost
<jcureton>
alyssa: thanks for the explanation! i'll try to hunt down that patch today and find some time to try it out
<alyssa>
tomeu: Derivatives are doable (it's ES3.0), just haven't had an app using them to justify
<alyssa>
fdph should have been lowered by NIR so I dunno what's up there
<alyssa>
BO cache eviction is supposed to happen from a madvise() from trhe kernel but that needs kernel help.
<alyssa>
raster: guillaume_g rtp; Ctrl-U for USB, Ctrl-D for internal
* alyssa
hits Ctrl-D every boot for Debian on her internal eMMC
<alyssa>
jcureton: Good luck!
<raster>
from memory it was ctrl+d to boot from sd card
<raster>
i never tried usb :)
<alyssa>
eMMC is just a silly SD card.. ;)
<raster>
well kind of - but i needed ctrl+d to boot from sd card i think as oppose to internal emmc
<guillaume_g>
on snow, ctrl-d is for Internal eMMC, ctrl-u for external (SD and/or usb)
guillaume_g has quit [Quit: Konversation terminated!]
guillaume_g has joined #panfrost
somy has quit [Quit: Leaving...]
<daniels>
you can use crossystem to autoboot without ctrl-d/u
<alyssa>
daniels: Doesn't that defeat the security model?
<daniels>
only in as much as disabling vboot etc does in the first place
<daniels>
i mean, yeah it does lessen security, but it is your own device after all
<alyssa>
daniels: Yeah, but disabling vboot causes big scary warning hence the ctrl-d
<alyssa>
ChromeOS's security model, not mine
BenG83 has quit [Quit: Leaving]
* alyssa
just did some SFBD toying
<alyssa>
(For T600/T720)
<alyssa>
Back to compiler core
guillaume_g has quit [Quit: Konversation terminated!]
megi has joined #panfrost
<alyssa>
Making progress on the compiler but.. I didn't know how much I didn't know, haha
<HdkR>
Knowledge is power
pH5 has quit [Quit: bye]
<alyssa>
You got to be kidding me
* alyssa
just implemented the scheduler change to accomodate this new thing.. still broken..
<alyssa>
"27 work registers"
<alyssa>
That might be related, lol
<alyssa>
......................Yup
<alyssa>
Just needed that one line change
<alyssa>
All the scheduler changes I can drop.
<alyssa>
Sigh, that's how you learn!
<alyssa>
C'est la vie
<alyssa>
Alrighty, with my new RA branch I have -bbuild working
<alyssa>
Next up will be special register spilling, for -bshading:shading=phong as the next test
* alyssa
break
<rtp>
alyssa: guillaume_g gave me a link to your sfbd commits. fyi, I think I'll have time to test them tonight.
raster has quit [Remote host closed the connection]
stikonas has joined #panfrost
<alyssa>
rtp: Good luck!
MistahDarcy has quit [Quit: Leaving]
calcprogrammer1 has joined #panfrost
<rtp>
alyssa: bad luck. black screen and a lot of status=DATA_INVALID_FAULT (it was with mesa head and the three patches). Sorry, but I prefer my hack then :)
<alyssa>
rtp: Mind sending the output with PAN_MESA_DEBUG=trace? Both with those 3 patches and without them (but with your hack)
<alyssa>
(And then diff the two from running the same app for one-frame ideally, and see where the problem is)
jcureton has quit [Remote host closed the connection]
<rtp>
alyssa: the problem is at least with the first patch. If I apply only the third one, it's working (my hack is even not applied)
<Lyude>
hey narmstrong, sorry for the slow reply, some stuff came up and I've been MIA for a couple days. I'll grab you the details of the issue I was hitting today
<alyssa>
rtp: Weiiiiiird?
<alyssa>
The frist patch (`require_sfbd` moveabout) was supposed to be a no-op refactor :/
<alyssa>
Bunch of regressions on my RA series. Fun.
<rtp>
I'm sure you'll fix them :)
<alyssa>
:)
<alyssa>
rtp: Regressions don't usually involve uncertainty, just tests of patience ;)
hlmjr is now known as herbmilleriw
<alyssa>
rtp: Sorted out. I hope.
<alyssa>
At least a bunch are. We'll hear back from CI on the rest in about 20min.
<rtp>
btw, while now it's working without crashing, the output of glmark2 is not perfect with -bbuild and -bshading. I see black triangle(?)
<alyssa>
rtp: *flashbacks*
<rtp>
but it's not a regression. without your patches it was already like that
* alyssa
can't remember if she ever figured out the cause of that nightmare
<alyssa>
Did I ever? Or did I just switch to T860 and it went away...?
<rtp>
no idea. I only tried glmark2 this week so I've no idea if it worked correctly before
<alyssa>
rtp: I think I saw that with T760 at one point, I mean
<rtp>
ohhh
davidlt has quit [Ping timeout: 248 seconds]
<Lyude>
alyssa: you still need access to that t820 btw right/
<alyssa>
Lyude: Yes, please :)
<alyssa>
For helping debug chewitt's issue with Kodi
<Lyude>
alyssa: alright, sorry it's taking a while - i've been mia for a bit
<rcf>
On the T760 glmark2 was having issues, but when I pulled from the latest git (rather than release) to try and debug things the issues went away and it completed without any OOM or serious glitches.
<rcf>
glmark2-es2, at least.
<alyssa>
Lyude: No worries :)
yann has quit [Ping timeout: 245 seconds]
<alyssa>
rcf: Yeah, master is *MUCH* more stable than 19.1 (which wasn't supposed to be a Panfrost release, so to speak)
<rcf>
I meant glmark2, not mesa. I was using their ancient 2014 release before.
<alyssa>
Oh, alright
<alyssa>
Wel, it also goes for mesa ;)
<rcf>
(and yes mesa master makes panfrost actually usable as a normal desktop for the most part)
<alyssa>
19.2 is prophecied to be the real first release for Panfrost, a 1.0 so to speak
<alyssa>
Which is.... less than two weeks away now. Shoot.
<rcf>
Memory use has shot way down in the past week or so, which is nice.
<alyssa>
rcf: We'll be working to get it down a lot more in the next weeks as well :)
<rcf>
In any case thank you for making hell freeze over and allowing these ARM GPUs to run on mainline :)
<alyssa>
rcf: My pleasure!
<alyssa>
Update: CI came back, no functional regressions.
<alyssa>
Still tracking down a performance regression introduced (noticed in shader-db) but we'll get it
<alyssa>
Got that regression solved
<alyssa>
Only perf regression remaining is an odd interaction between class spilling and use lowering
<alyssa>
It would be easily enough solved with a copy prop run after RA, but that's not really feasible
<alyssa>
Next best would be coalescing
<alyssa>
I guess I can ignore it, it doesn't matter right now
stikonas has quit [Remote host closed the connection]
robert_ancell has joined #panfrost
<alyssa>
Trying to get perspective projection ops wired in
<alyssa>
Simple cases work, but there are issues with how we're forcing the r27 register (the mechanism is related but distinct from how st_vary is done)
<alyssa>
set_node_reg doesn't work, I need to create a new interfering register class
herbmilleriw has quit [Remote host closed the connection]
herbmilleriw has joined #panfrost
<alyssa>
There we are
<alyssa>
My shiny GPU feels slow today
<alyssa>
What could possibly be up
<alyssa>
And it's not just this branch ummmmm
<alyssa>
devfreq is somehow to blame probabl
<alyssa>
It's maxxed um
* alyssa
shrugs
<alyssa>
Rebooted and it's fine now
yann has joined #panfrost
<alyssa>
Alright, have quite a bit of a day's work here
<alyssa>
Time to do the _delightful_ task of rebasing everything
<alyssa>
Of course, it'll be easy since I already finished my git rebase hazing ritual ;)