<tomeu>
we'd need something similar that runs piglit instead
<davidlt>
yeah, I just looked at that
<tomeu>
the other three things that lava needs for you to provide is a DT, a kernel and a disk image
<tomeu>
in this case, I think it would be best to run the tests off NFS
<davidlt>
NFS usually creates some problems you want them or not
<tomeu>
yeah, we use ramdisks for kernelci, but piglit is really big
<tomeu>
and I think we'd have more problems with local storage
<davidlt>
capacity related or SD/eMMC limits?
<davidlt>
On riscv64 boards we either use SSDs (highly expensive to attach) or NBD instead of NFS
<tomeu>
kernelci doesn't use NFS mainly because it's important to test that things work across suspend and resume cycles, and with usb eth things just break
<tomeu>
nbd could be fine I guess, not sure it is supported already by lava though
<davidlt>
again, never run piglit, so no idea what are requirements
<tomeu>
a good first step would be running it locally and seeing what passes
<davidlt>
but I was surprised how good NBD was in the last year
<tomeu>
then write a lava job that runs only what is currently passing, hardcoded
<davidlt>
exactly, but I don't have anymore any Mali-based stuff
<davidlt>
everything is now Snapdragon :)
<tomeu>
ah, true
<davidlt>
Panfrost might change this in the future
<tomeu>
well, guess we can do an initial whole run on lava
<tomeu>
it will take a good while :)
<davidlt>
I hate to do that because it might take significantly more time
<tomeu>
well, you can cull afterwards
<tomeu>
the first run is to know what would make sense to run at this stage
<tomeu>
in the future, I guess we could do some kind fo sharding across devices
<tomeu>
but I'm not sure we'll be passing much of piglit atm, maybe I'm wrong though :)
<tomeu>
as an alternative to piglit, we could run deqp, the virgl folks have a runner that makes things much faster than otherwise
<tomeu>
another question is which distro to use for the rootfs
<tomeu>
guess you would be more comfortable with fedora than with debian?
pH5 has joined #panfrost
<davidlt>
yeah, I am Fedora guy :)
<davidlt>
otherwise I wouldn't be doing Fedora/RISCV as that's a huge-time-killer brain-killing project
<daniels>
tbh, rendering a screen-aligned textured quad and making sure the output is sane would already be a vast improvement on where we are today :)
<tomeu>
yeah, I think the most important thing with CI is to do baby steps
<davidlt>
true
<tomeu>
specially as the simplest CI is already much better than zero CI :)
<davidlt>
I pinged pbrobinson (manages Fedora ARM stuff), he uses Rock960 and Ficus boards for Fedora rk3399 testing :/
<davidlt>
apparently is not using ROCKPro64
BenG83 has joined #panfrost
<tomeu>
davidlt: hmm, why do you mention rockpro64?
* tomeu
may be missing something
<davidlt>
tomeu, because that's rk3399 board and cheapest one
<davidlt>
and also it's gonna be used in Pinebook Pro
<davidlt>
I am definitely buying Pinebook Pro in 2019 H2
<tomeu>
ah, got it
<tomeu>
yeah, it's looking very promising
<davidlt>
yeah, I geeked with TL Lim at FOSDEM and have some pictures of Pinebook Prop internals
<tomeu>
I think panfrost is going to shine in those machines :)
<davidlt>
we have discussed rk3399 based pinebook back in FOSDEM 2018 and it was nice to see it finally at FOSDEM 2019
<davidlt>
and you will be able to attach M.2 NVMe with 4 lanes
<davidlt>
hm... so basically I am going back to Mali in 2019 H2 :/
<memeka>
tomeu: any chance in adding odroid xu4 as well?
<tomeu>
memeka: adding to where?
<memeka>
Lava
<tomeu>
for kernelci?
<tomeu>
or for panfrost's ci?
<memeka>
Panfrost
<tomeu>
well, we first need to get panfrost running there, right?
<memeka>
I thought you have some at Collabora
<tomeu>
or maybe it does already?
<memeka>
Well if it runs on 32bit t7xx it might work on that too?
<tomeu>
nice, something should test it :)
<tomeu>
maybe we have already plans to add one, don't know, that would be more of a question for sjoerd
<tomeu>
you can find him in a bunch of channels in freenode, for example in #kernelci or #etnaviv
<memeka>
I’ll test it when I get the time, hope alyssa pushed everything :D
<tomeu>
not yet, afaics
<memeka>
Ndufresne was saying there was somebody getting them for testing
<tomeu>
could very well, I'm not aware of that
<daniels>
we already have xu3 in our lab
<daniels>
that has the same Exynos 5422 SoC
<tomeu>
excellent, three device types that can run panfrost :)
<davidlt>
is XU4 well supported by distros by now?
<davidlt>
I had a number of Exynos ODROID devices which are dead now, because no distros properly supported them for a long time
<daniels>
i personally gave up on exynos when mainline kept breaking on publicly available boards because samsung pushed changes which only worked when running tizen on non-public boards
<daniels>
but maybe it's better now
<davidlt>
yeah, all those ODROID and similar went to graveyard
<davidlt>
that was like 5-8 boards
<Lyude>
davidlt: didn't know you worked on Fedora!
<davidlt>
Lyude, yeah, full-time Fedora/RISCV
<davidlt>
before that I focused 4 years on AArch64 server stuff
<Lyude>
Ahh
afaerber has quit [Quit: Leaving]
<Lyude>
I work on desktop engineering at RH, but still can't convince work to give me the time for panfrost quite yet
afaerber has joined #panfrost
<tomeu>
davidlt: so, when are we writing a GPU driver for a RISC-V SoC? :)
<davidlt>
tomeu, hopefully never :)
<davidlt>
We use Radeon GPUs to run GNOME Desktop ;)
<davidlt>
Lyude, most likely some time after Panfrost is usable
<davidlt>
probably at that point even ARM gonna start doing small bits
<Lyude>
davidlt: doesn't help with trying to get panfrost on bifrost ATM though :/
<tomeu>
davidlt: was kind of expecting a GPU with open IP
<davidlt>
tomeu, I am not aware of any these problems, well something like that:
<davidlt>
- Esperanto AI chip also has shader compiler and could render Crysis
<davidlt>
- there is libre soc project that has ISA extension to accelerate graphics
afaerber has quit [Quit: Leaving]
afaerber has joined #panfrost
<memeka>
tomeu davidlt dunno what was getting broken on your xu3/4s, but mainline got better and better on them, and I’ve been running gnome3/wayland for almost the past 2 years on them, can’t say there was another arm board to run gnome3 2 years ago
<memeka>
Although the drm driver is incomplete, since Samsung just adapted the exynos4 driver so some exynos5 stuff is not implemented
<davidlt>
I think, I had ODROID-U2 and XU+E or whatever it was called at a time
<davidlt>
I had to build custom distros for a long time to use them
<memeka>
davidlt: those are different soc
<davidlt>
One was Exynos 4XXX, the XU+E was 5422 IIRC
<memeka>
Xu+e was 5410 davidlt
<memeka>
U2 was exynos 4412
<memeka>
Xu+e didn’t even have mali, it had powervr
<davidlt>
ah, XU+E was Samsung Exynos 5410
<memeka>
I remember hacking lib hybris on it everywhere
<memeka>
Don’t know any other arm board to run gnome3 at that point in time
<memeka>
Afair Eric A was barely hired then, there was no rpi driver yet
<davidlt>
I think, XU+E was something like 2013?
<memeka>
Yeah xu+e was long time ago
<davidlt>
that's the one I had, until it stopped working
<memeka>
It’s the buggy soc which could never run hmp
<davidlt>
U2s survived longer
<memeka>
Because of cci issue
<memeka>
Xu3/4 are also old, but they aged better :) mainline support grew nicely
<davidlt>
yeah, I recall that
<memeka>
Now I just add mali, hmp, and some dts changes to add 2ghz to them
<memeka>
But basically mainline has everything working
<memeka>
With hmp, you’ve got 8cpus and 2gb ram, still outperforms everything up to RK3399
<memeka>
Also Samsung was one of the first to have v4l2 vpu, and first to have the new cec driver
<memeka>
Wasn’t a smooth ride, but it was in front seat
<memeka>
:)
raster has quit [Remote host closed the connection]
chewitt has joined #panfrost
<alyssa>
tomeu: Technically the amlogic chip we support is T820, whereas rk3399 is T860, but I'm aware of exactly zero differences between the two visible to userspace sooo :p
<ezequielg>
tomeu: i am not sure tbh :-)
<Lyude>
tomeu: winsys is different
<Lyude>
oh wait-sorry, had a brain fart
<Lyude>
not all T820 systems are meson :)
<Lyude>
(also meant to @ alyssa , coffee must still be waiting to kick in)
<alyssa>
Anyways, tomeu davidlt etc: for now for CI, honestly just running through glmark's known-working scenes, screencapping the first frame, and making sure the screencaps are the same as known good would be.. a vast improvement
<alyssa>
I already have the scripts setup for that (from September/Octoberish), I can resurrect them from git history if you'd like
<tomeu>
awesome, looks like tomorrow will be my panfrost day \o/
<robher>
Does anyone have a register access trace? One delineated by ioctls would be ideal.
<tomeu>
robher: would be great if you shared your test program, I could extend it as I add more stuff to mesa
<tomeu>
will be easier for both to test the same thing
<robher>
alyssa: the vendor driver does export all the feature registers and I think the base_hw_feature and base_hw_issue enum to userspace. So who know what the blob does with any of those.
<robher>
tomeu: yeah, will do. I really wanted to move it to IGT though.
<robher>
tomeu: And I have a few more kernel commits to push. I've wired in the gpu scheduler (but no guts). I've been out the past 3 workdays.
pH5 has quit [Quit: bye]
chewitt has quit [Remote host closed the connection]
chewitt has joined #panfrost
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #panfrost
pH5 has joined #panfrost
ente has quit [Read error: Connection reset by peer]
ente has joined #panfrost
stikonas has joined #panfrost
chewitt has quit [Quit: Adios!]
_whitelogger has quit [Remote host closed the connection]
afaerber has quit [Quit: Leaving]
_whitelogger has joined #panfrost
afaerber has joined #panfrost
sphalerite_ is now known as sphalerite
BenG83 has quit [Quit: Leaving]
raster has quit [Read error: Connection reset by peer]
<alyssa>
robher: I think hanetzer had some code a while back to do register traces with a modified mali_kbase?
<hanetzer>
it was really poopy
<Lyude>
stinky
<alyssa>
robher: If you want to recreate yourself, the functions are in midgard/backend/gpu/mali_kbase_device_hw.c
<alyssa>
Though presumably you want to do macro magic to get the names to expand nicely
<robher>
alyssa: I know how, just lazy if it already exists. I'm fine with just addresses and values.
<alyssa>
robher: Laziness is good, sometimes ;P
<Lyude>
what is programming but just automating laziness
stikonas has quit [Remote host closed the connection]