alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - https://gitlab.freedesktop.org/panfrost - Logs https://freenode.irclog.whitequark.org/panfrost - Transientification is terminating. Memory reductions in progress.
stikonas has quit [Remote host closed the connection]
<alyssa> So on the kmsro branch, we're not loading
<alyssa> Hmm
<alyssa> "failed to load driver: rockchip"
<alyssa> Oh, I see
<alyssa> --Okay, now what
<alyssa> I imported the "pipe-loader: fallback" patch which I think was missed
<alyssa> Still not loading uhh
<alyssa> Oh, meson configure
<alyssa> Not in allowed choices, *blink*
<alyssa> (...Do I need to rebuild everything? Ugh)
<alyssa> I mean I have ccache but still
<alyssa> Yeah okay just triggering a rebuild, this is annoying
<alyssa> Okay it's rebuilt, containing the right drivers, *now* what :V
<alyssa> pipe_loader_drm_probe_fd is not being called?
<alyssa> Oh!
<alyssa> I don't have any render nodes... for some.. reason
<alyssa> ...Do I usually have render nodes?
<alyssa> I usually have render nodes
<alyssa> Where are my render nodes?!
<alyssa> robher: ^^ Is it supposed to work without render nodes? :P
<alyssa> (Do I need vgem? --Wait, how did this code work before then?!)
<alyssa> I have a /dev/dri/card0 but not render
raster has quit [Read error: Connection reset by peer]
<robher> alyssa: yes, it opens /dev/mali0
<alyssa> So what the hay is happening her'?
<alyssa> Ahhh the issue is "failed to bind extensions"
<alyssa> -----That elucidates little
<alyssa> The probe methods aren't being invoked, ahh
<alyssa> This is tested, yes?..
<alyssa> It's failing extensions DRI_Core and DRI_DRI2... that is, all the extensions
<alyssa> Theeere we go
<alyssa> We need a DEFINE_LOADER_DRM_ENTRYPOINT(rockchip)
<alyssa> Alright, tasty, 0 open MRs
<alyssa> Doing the Mesa rebase now
<alyssa> Alright, did a rebase... mesa should become a lot sooner... still need to debug going forward, argh
<alyssa> WHAT
<alyssa> gsdfgdfs
<alyssa> I.. have.. to.. resolve.. it.. all.. over.. again...
<alyssa> *faints*
<alyssa> We really need to get Panfrost merged upstream, oy
<alyssa> Fixed... again... rebuilding...
<alyssa> We're... missing.. files.. from.. git.. gah
<alyssa> Well, it's been nearly 2 months since the last rebase, so most of mesa is recompiling
<alyssa> Guess I'll let that stew until it gets to driver files and I find a dozen NIR APIs broke
* alyssa blinks
<alyssa> $ git diff upstream/master | wc -l
<alyssa> 26981
<alyssa> That's.. not good
<alyssa> Here there are, lovely, lovely
<alyssa> Alrighty
<alyssa> Latest panfrost/mesa master is rebased on latest upstream mesa master
<tomeu> robher: hi there, have you pushed your 5.0 rebase somewhere?
<alyssa> Eh, well, let me figure out how much work it is to get some code upstream
<tomeu> alyssa: amazing :)
<alyssa> tomeu: Not like.. real usable code
<alyssa> But at least some stubs so I can stop going crazy with rebase
<alyssa> Going through the diff of master/us and cherrypicking, essentially
<alyssa> (Implicitly squishing history)
<alyssa> Things I'm skipping: buffer age (should be its own thing, I didn't write it), blend lowering (should also be its own thing, I did write it tho :P), ..
<alyssa> NIR vectorize (already submitted upstream, I didn't write it)
<tomeu> sounds good!
<alyssa> Lyude: HdkR: tomeu: etc: ^^
<alyssa> About to sleep, but does that look sane?
<tomeu> alyssa: what functionality is there?
<alyssa> tomeu: Nothing
<alyssa> Yup. 3000 lines to do.. nothing
<alyssa> :p
<alyssa> That's the headers, the winsys, and pan_screen, basically
* tomeu looks
<alyssa> Just exits immediately rn
<alyssa> But upstream can merge that as-is (no blockers) and we at least have a "reservation" in the build system :p
<alyssa> Next patch in the series will be adding the Midgard compiler
<alyssa> Then comes the actual driver-driver. Probably inoperable
<alyssa> Leaving out anything related to:
<alyssa> - buffer age (see above)
<alyssa> - blend shaders (ditto)
<alyssa> - non-DRM legacy driver (licensing issues etc)
<alyssa> - Bifrost (it's just a stub rn)
<alyssa> - panwrap (it's a lot of code, most of it of questionable quality, and it's not needed upstream, at least not yet)
<alyssa> What's left has no real blockers to merge, but is also not useful since kernel :p
<alyssa> Well, there'll be the standalone Midgard shader toolchain, which is useful in and of itself
<tomeu> looks good to me!
<alyssa> But anyways, the point of this rn isn't getting it shipping, it's just having the code upstream to make rebasing breezy again
<tomeu> alyssa: what's going to contain the first series to be submitted?
_whitelogger has joined #panfrost
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
pH5 has joined #panfrost
robertfoss_ has quit [Ping timeout: 244 seconds]
robertfoss_ has joined #panfrost
raster has joined #panfrost
<robher> tomeu: pushed panfrost-5.0 to my fdo tree. There wasn't much to it. It all just applied and one function changed.
<tomeu> robher: ok, are you planning to work on gem shmem helpers?
<robher> tomeu: yes, or give up and just copy the etnaviv code...
<tomeu> robher: I have started copying the etnaviv code :)
<robher> tomeu: perhaps look at the MMU. My first question is freedreno uses the iommu api and etnaviv does not.
<tomeu> robher: which iommu api are you referring to?
<robher> tomeu: the kernel's...
<tomeu> robher: but etnaviv does use the iommu subsystem
<tomeu> oh wait, maybe I mixed things
<robher> tomeu: NM, I was confused...
<robher> tomeu: msm calls iommu_map_sg and uses iommu_domain for example. etnaviv doesn't.
<tomeu> yeah, I was looking at both as well and somehow came to think that it was etnaviv that was using it... :/
<tomeu> robher: I think I will keep banging on etnaviv's for now
<tomeu> I really want to get to command submission as soon as possible, as I think at that point is easier for more people to work on this in parallel
yann has joined #panfrost
Elpaulo has quit [Quit: Elpaulo]
Elpaulo has joined #panfrost
BenG83 has joined #panfrost
<alyssa> tomeu: Mali Midgard+ is unlike a lot of GPUs in that its "command stream" is composed of descriptors in (shared/mapped) memory... so you really do need MMU going before you can think about job submission..
jolan has quit [Quit: leaving]
<tomeu> robher: didn't get any far today, but FWIW: https://gitlab.freedesktop.org/tomeu/linux/commits/panfrost
<tomeu> the idea was to implement enough of PANFROST_GEM_NEW to get panfrost_drm_allocate_slab working
<robher> tomeu: hum, that's what I'm reworking on etnaviv...
<robher> BTW, AFAICT none of the userptr stuff in etnaviv is used anywhere.
<tomeu> robher: reworking?
<robher> tomeu: to use shmem lib. I was taking the approach to rework in etnaviv and then copy rather than copy and then rework.
<tomeu> ah, cool
<tomeu> are you having to write a iommu driver as well?
cwabbott has quit [Quit: cwabbott]
<robher> things like etnaviv_gem_ops can be replaced with the standard GEM funcs struct. Like any new driver, what's recommended practice has changed since any in tree driver was written...
<robher> tomeu: As soon as we want h/w to touch any GEM buffer, we'll need it. I've only looked at it in the sense of what GEM obj data does the MMU code use.
<tomeu> ok, sounds great!
<HdkR> alyssa: Nice. Fix the typo in the commit message but I approve :)
yann has quit [Ping timeout: 250 seconds]
BenG83 has quit [Quit: Leaving]
stikonas has joined #panfrost
pH5 has quit [Quit: bye]
pH5 has joined #panfrost
raster has quit [Remote host closed the connection]
Elpaulo has quit [Remote host closed the connection]
Elpaulo has joined #panfrost
yann has joined #panfrost
Elpaulo has quit [Quit: Elpaulo]
cwabbott has joined #panfrost
NeuroScr has quit [Read error: Connection reset by peer]
NeuroScr has joined #panfrost
<stikonas> hanetzer: you need to rename rockchip -> kmsro in your gentoo ebuild.
<stikonas> it compiles with that change
<hanetzer> stikonas: compilation wasn't a problem as far as I knew, just its not getting the mali regulator for me :<
* alyssa updates instructions
<hanetzer> stikonas: I assume you mean the use_enable bits?
<alyssa> Instructions updated
<HdkR> alyssa: btw, is that a patch for upstream that you posted?
<alyssa> HdkR: Will be
<HdkR> :)