alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - Transientification is terminating. Memory reductions in progress.
ric96 has joined #panfrost
stikonas has quit [Remote host closed the connection]
mearon_ is now known as mearon
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #panfrost
TheKit has quit [Ping timeout: 268 seconds]
TheKit has joined #panfrost
TheKit has quit [Ping timeout: 245 seconds]
TheKit has joined #panfrost
TheKit has quit [Ping timeout: 272 seconds]
TheKit has joined #panfrost
TheKit has quit [Ping timeout: 246 seconds]
TheKit has joined #panfrost
<alyssa> Oh, interesting, I was debugging the wrong thing :P
<alyssa> It's something from the FS onward that's broken
<alyssa> Either writeout or blending or something, I bet
<alyssa> ...Let's peak at blending, actually
<HdkR> alyssa: Looking at t6xx?
<alyssa> HdkR: Yupyup
<alyssa> color_mask = 0x0
<alyssa> Sussspect lol
<HdkR> woo
<alyssa> Got kmscube working
<alyssa> (On RK3288, our mali_kbase, upstream Panfrost, smallish patchset)
<alyssa> Awkward performance problems though
<alyssa> I do also want to get MFBD 32-bit going
<alyssa> Deja vu, seriously
<alyssa> I had this bug on T860 too.. and I'm not totally sure how that got resolved..
<alyssa> Oh aaa tiler is really messed up
<alyssa> That would explain the perf issues, but kmscube was functionally fine. It's really obvious on glmark tho
<alyssa> Thing is, I'm not sure I _ever_ fixed this bug on T6XX, since I didn't do samples harder than test-textured-cube at that point..
<alyssa> Fixed, at least one of the bugs is
<alyssa> Performance is now... par with RK3399
<alyssa> Which means we're doing something stupid :p
<alyssa> Jellyfish looks visually wrong but I can't place my eye on what..
<alyssa> Maybe blending
<alyssa> glmark status seems the same, minus tests involving FBOs
<alyssa> Weston is notably not working but there're a lot of reasons why that could be
<memeka> alyssa: what branch? :D
<alyssa> Not totally pushed and not ready but uhh
<alyssa> nondrm branch "nah"
<alyssa> mesa branch fixes-32 on my personal fork (alyssa/mesa)
<alyssa> So many things to cleanup to get this actually mergeable but I digress
<alyssa> This was the hard part anyway
<alyssa> Aside: MFBD works just fine on T760 32-bit
<alyssa> So FBO samples work here
<alyssa> (That doesn't apply to y'all T600 boards, which is honest-to-goodness T6XX and not just T760 pretending to be T6XX)
<alyssa> ...and weston works now. Wonder if it depends on FBOs or something silly
<tomeu> hmm, I don't think weston itself does FBOs
<tomeu> and good morning :)
<alyssa> Morning
<alyssa> Evening
<alyssa> S'all the same anyway
<alyssa> Anyway, super happy with all this since it means we're at feature parity between 32-bit T760 and 64-bit T860
<alyssa> So everything can kinda flow from there
<tomeu> simply amazing :)
<tomeu> on what hw are you testing?
<davidlt> do you have some CI to keep it working?
<tomeu> oh, rk3288 has that one, right?
<tomeu> davidlt: don't think so, would you like to work on that? :)
<davidlt> don't have the board
<alyssa> tomeu: RK3288 laptop
belgin has joined #panfrost
<tomeu> davidlt: I think there have been several offers of hw for people interested in contributing to panfrost
<tomeu> ezequielg: do you know of such an offer that still holds firm?
<davidlt> tomeu, do you do any CI at all right now, incl. some QA?
<tomeu> davidlt: no, but I worked on CI for virgil and I think some of that could be easily adapted
<tomeu> I'm not sure how that could be done within gitlab without bothering the !panfrost parts of mesa, now that we are in mainline
<tomeu> daniels: any ideas?
<belgin> hello
<belgin> is the T760 still supported?
<belgin> i remember reading alyssa moved to a T860
anarsoul_ has joined #panfrost
anarsoul_ has quit [Client Quit]
<tomeu> belgin: per the above, alyssa has worked on restoring support for it
<daniels> alyssa, tomeu: weston doesn't do fbo btw
<daniels> tomeu: ideas for what, panfrost CI? could set up some allowed-to-fail jobs using a custom runner tag
<tomeu> daniels: what about the .gitlab-ci.yml file? could we have our own for now? or would we need to share it with other folks?
<daniels> tomeu: you'd need to share it with the one which already exists
pH5 has joined #panfrost
mifritscher has joined #panfrost
raster has joined #panfrost
pH5 has quit [Remote host closed the connection]
belgin has quit [Quit: Lost terminal]
<tomeu> davidlt: are you familiar with lava? I could give you access to collabora's instance so you can submit jobs
<tomeu> once those work manually, we could look at having gitlab's CI submit those jobs
<davidlt> tomeu, I am not (well, I attended a few talks on it at Linaro Connect, but that's it)
<tomeu> davidlt: ok, there's quite a bit of docs out there, if you are willing to put the time
<tomeu> we have devices with rk3288 and rk3399 there
<tomeu> and are generally happy to add more devices to it
<davidlt> at this point in time, I don't even know how to properly build panfrost and how to CI it, what kind of metrics needs to tracked, etc.
<tomeu> yeah, so so far people have been running weston or so and looking if things look right
<tomeu> guess it would be more practical to run deqp and/or piglit
<davidlt> The last SBC running at home is Snapdragon based, so I don't even have Mali GPUs at home :/
<tomeu> that shouldn't be much of a problem provided you have a fast connection from where you hack :)
<davidlt> e.g. in Fedora QA infra you also get pictures from tests
<davidlt> I usually have 400Mbps / 1Gbps depending where I stay
<tomeu> though well, artifacts (kernel, images, etc) should be built also somewhere in a server
<davidlt> e.g., here are some tests from Fedora QA with pics:
* davidlt is leading Fedora/RISCV efforts
<tomeu> davidlt: this job that is running right now shouldn't be that different from what we'd need for panfrost:
<tomeu> cool!
<tomeu> we could run weston headless and take screenshots, but then we'd be testing a lot of stuff that isn't panfrost
<tomeu> I think as a start, a subset of piglit could be best
<davidlt> is rk3288 (32-bit) and rk3399 (64-bit) with different Mali T provides full coverage?
<tomeu> yes, these two are supported atm (well, once alyssa pushes)
<tomeu> and also an amlogic soc that has the same GPU as the rk3399
<tomeu> davidlt: this is the lava job description that executes igt:
<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> nice screen, nice chassis, decent keyboard
<davidlt> properly working Type-C USB
<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> Even patched sdl2 with a hybris backend
<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]
stikonas has joined #panfrost