alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - Transientification is terminating. Memory reductions in progress.
_whitelogger has joined #panfrost
_whitelogger has joined #panfrost
stikonas has quit [Remote host closed the connection]
<alyssa> Alright! Save for the non-DRM overlay (kernel headers and about 500 lines of code), we're merged upstream!
<alyssa> panfrost/mesa is now deprecated, dev should happen off upstream mesa/mesa
<alyssa> I'm writing up instructions now about using the overlay
<alyssa> Userspace dev can resume, of course :) -- but should now be sent as squashed MRs to mesa gitlab, I guess
<alyssa> Or do we want a mailing list? I dunno!
<alyssa> If people have an idea on what the least painful way to do dev is going forward, do tell
<alyssa> Both MRs and mailing list seems annoying
<alyssa> cwabbott: Lyude: HdkR: ezequielg: tomeu: chewitt: robher: ^^
<Lyude> MRs
<alyssa> Lyude: Adding in the reviewer tags makes everything 20% less cool..
<Lyude> mailing lists get old pretty quickly
<alyssa> I imagine, yes
<alyssa> Is MRs-without-tags an option? :/
<alyssa> (For stuff that's purely intra-panfrost)
<Lyude> tags don't need to be used, we can just name branches things descriptively. but honestly-mailing lists aren't good for inexperienced contributors, merging patches with git am can get pretty annoying sometimes, patches are a lot more likely to get ignored/lost if there's traffic
<alyssa> (By tags I mean "Reviewed-by" "Acked-by" etc amended into the commit message itself)
<Lyude> what's wrong with having that?
<Lyude> tags are p important imo
<Lyude> at least for a project like this
<Lyude> (sorry-thought you meant like labels when you said tags)
<alyssa> Adds more hassle to getting stuff merged when all that information is already in gitlab for people who want it
_whitelogger has joined #panfrost
<HdkR> alyssa: Awesome
<chewitt> I'd vote for MR's as it's simple to keep tabs on what's changing, who from, when it's merged
<chewitt> mailing lists are harder to track when you're not on the list
<chewitt> (and I'm not on any.. I get hideous amounts of mail without that fun)
<ente> whoa, it's full here
<alyssa> Hum?
<ente> [04:12] *** Irssi: #panfrost: Total of 77 nicks (6 ops, 0 halfops, 0 voices, 71 normal)
<alyssa> We've been creeping up in numbers, yes :)
<HdkR> There's some people in here
<HdkR> Creepers
<HdkR> Hissing and exploding
<ente> that's cool. and here I thought panfrost was hopelessly niche and irc is a dead medium :)
<alyssa> Ouch.
<HdkR> Right in the feels
<ente> I like being wrong about this
<alyssa> I'm wrangling a compiler here, can't have my feelings hurt rn
<alyssa> :p
<alyssa> Once I finish up this patch, feel free to insult me all you want, tho
<alyssa> ;)
<ente> didn't mean it as an insult, just.. #netbsd on ircnet has 103 people in it
<alyssa> Yeah, but... BSDs ;)
<alyssa> Sorry, is my Linux fangirl showing?
<ente> no I think it's cool that people care about panfrost
<ente> (BSD, but also IRCnet)
<ente> nevermind, I should sleep. I say the words but they come out all wrong
<HdkR> I think we've just mostly kidnapped people from #dri-devel
* ente tries to remember how he found panfrost for the first time
<robher> alyssa: you'll probably still need to maintain a branch outside of mesa mainline because it will take some time to finalize the kernel ABI. Or maybe the mesa community has gotten less strict about that.
paulk-leonov has quit [Ping timeout: 240 seconds]
<alyssa> robher: I mean, for the vendor kernel, that's in the overlay repo which is small and will get smaller
<alyssa> For the new DRM stuff, I mean, that's not on me ;P
<robher> alyssa: fair enough. Though I'd guess we want one tree with both if possible.
paulk-leonov has joined #panfrost
<alyssa> robher: Hm?
<alyssa> Unless there's a mesa policy I'm not aware of, once DRM stuff comes along we'll just push that straight to mesa mainline
<robher> surely there will be some need to switch between the 2.
<alyssa> robher: If the overlay is present, it'll prefer the DRM device but if that's not loaded it'll fallback on /dev/mali0
<alyssa> (Same binary supports both)
<alyssa> (The overlay adds an interface, it doesn't replace anything)
<robher> There's the kernel policy that we don't break the ABI with userspace.
<robher> Yes, one binary is a good thing.
<robher> In any case, we can worry about the DRM part when we have something working...
<alyssa> robher: Sure, but I don't think there's a userspace policy that we don't break kernelspace ;P
<alyssa> I'm just a little confused what your concern is
<alyssa> The kernel can't be mainlined until the ABI is stable, but the userspace pieces to talk to the kernel can be since that's easy to change later (since nobody will consume that code until the kernel is mainlined)
* HdkR clones panfrost on XU4 quick
<robher> alyssa: If upstream is okay with that, then great. They used to be stricter about it I think.
<Lyude> I don't really think there is an ABI to honor until it's upstream, no?
<alyssa> robher: Upstream seems to be "if it only touches drivers/panfrost and it doesn't break other drivers, it's your call"
paulk-leonov has quit [Ping timeout: 250 seconds]
paulk-leonov has joined #panfrost
<alyssa> iadd can run on vmul
<alyssa> Wat.
<alyssa> "I don't see how this code can possibly work"
<alyssa> Normal day in gfx
indy has quit [Quit: ZNC -]
<alyssa> Yuck, kmscube/NV12 regressed at some point
memeka has quit [Quit: Connection closed for inactivity]
indy has joined #panfrost
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
<chewitt> @alyssa which branch/repo should I be targeting to get a working panfrost?
<alyssa> should have been updated why didn't that update
<alyssa> TL:DR "mesa/mesa master, but with caveat"
<chewitt> urgh.. symlinking
<alyssa> chewitt: 's better than the alternative, no?
<chewitt> what is/was the alternative?
<alyssa> chewitt: Not being able to upstream the driver at all
<chewitt> so there's no downstream panfrost/mesa development branch with everything included now?
<chewitt> e.g. branch that tracks mesa/master + current un-upstreamed changes
<chewitt> from a build-system perspective I need to pull *a* branch with everything
<chewitt> I can add patches to a branch
<chewitt> but then I need to manage patch sets
<chewitt> the usual way is tracking a branch with everything in it, and generating patches for each change since a specific base commit
<alyssa> Erm, no, I'm trying not to be a downstream
<alyssa> Be an upstreamer, not a bistreamer
<alyssa> Actually, also be a bistreamer if that's who you are #pride
<chewitt> :)
<chewitt> hmm.. maybe it's no so bad
<chewitt> I can pull the main mesa branch from mesa/master .. and generate patch-sets from panfrost/nondrm
<alyssa> OK..
<alyssa> I guess I don't see how this is worse than before, per se?
<chewitt> there's less work when you just pull the sources direct from git
<chewitt> we'll see how it goes
<chewitt> I haven't rejigged things since the kmsro change .. so there's probably something that breaks :)
<alyssa> Oop
<alyssa> Well, I just test Kodi on here and it's working aight :)
<chewitt> any improvements to memory usage?
<alyssa> Not yet
<alyssa> Been distracted by upstreaming
<chewitt> an easy way to replicate the problem is leaving the Kodi settings > system info screen open
<alyssa> I'm well aware of the proeblem ;P
<chewitt> cool
<HdkR> "DRI2: failed to create dri screen" gah
<alyssa> Relatable
<alyssa> Oops, had unpushed stuff in the overlay breaking the non-DRM build. Pull that again I guess
memeka has joined #panfrost
MoeIcenowy has quit [Changing host]
MoeIcenowy has joined #panfrost
pH5 has quit [Quit: bye]
pH5 has joined #panfrost
BenG83 has quit [Ping timeout: 240 seconds]
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 -]
MoeIcenowy has joined #panfrost
afaerber has quit [Quit: Leaving]
afaerber has joined #panfrost
chewitt has quit [Quit: Adios!]
afaerber has quit [Quit: Leaving]
afaerber has joined #panfrost
indy has quit [Quit: ZNC -]
memeka has quit [Quit: Connection closed for inactivity]
indy has joined #panfrost
<HdkR> btw. I'm taking a look at the midgard 1st gen job submission problem as well
<HdkR> I've repro'd the error. Will need to get traces of the blob to see how submissions are different later
<rtp> oh, sounds great !
<HdkR> Already found a couple of locations where we are hardcoding 64bit job submission types. Didn't solve the problem. Need the trace to see what is breaking now :P
<alyssa> HdkR: If it helps, the mali-job.h file from July panfrost (I guess that'd be in the dedicated panfrost repo back in history) did work
<alyssa> So if you can find differences where fields got messed up since, that's probably a big part
<HdkR> ah, maybe
<HdkR> That's quite a while ago though, might be painful
<alyssa> HdkR: Wonder why nobody else has done it? ;P
<HdkR> Better things to do?
<HdkR> :P
<rtp> alyssa: uh. Using an old mali-job.h make things work ?!
<alyssa> rtp: Hm?
<rtp> "16:53 <@alyssa> HdkR: If it helps, the mali-job.h file from July panfrost (I guess that'd be in the dedicated panfrost repo back in history) did work"
<alyssa> We used to develop for 32-bit t6xx, then when I switched to focusing on 64-bit t8xx nobody maintained the old stuff and it regressed
<HdkR> I need 32bit t6xx working anyway if I want the CI farm to ever get off the ground :P
<rtp> alyssa: I know but I (wrongly?) understood you were saying that t6xx not working was only related to the .h file. Regression may always happen, it's human :)
<rtp> HdkR: is your t6xx work available somewhere ?
<HdkR> I mean, you saw work. It hasn't changed behaviour
<HdkR> you say work*
<rtp> so, s/work/changes/ if you find this wording better ?
<HdkR> It's effectively memeka's patch atm with a couple changes
<rtp> thanks
<rtp> from a quick look, looks similar to what I have
<mmind00> alyssa: rk3288 is T760, not T6xx though?
<alyssa> rtp: Oh, not at all, but that .h file contains most of the cmdstream definitions so that's the most obvious source of blah
<alyssa> mmind00: Yeah, but we were running it in some wack compat mode thingy since we were using a t6xx blob
<alyssa> The bigger issue is 32/64-bit anyway
<HdkR> Which I fixed two problem sites for that at least :P
<alyssa> Woop
<alyssa> HdkR: You're using upstream mesa tho, yes?
<HdkR> Dunno, I grabbed a branch :P
afaerber has quit [Quit: Leaving]
stikonas has joined #panfrost
pH5 has quit [Quit: bye]
pH5 has joined #panfrost
memeka has joined #panfrost
BenG83 has joined #panfrost
raster has joined #panfrost
belgin has joined #panfrost
raster has quit [Remote host closed the connection]
belgin has quit [Quit: leaving]
jernej has quit [Remote host closed the connection]
paulk-leonov has quit [Ping timeout: 252 seconds]
jernej has joined #panfrost
paulk-leonov has joined #panfrost
BenG83 has quit [Quit: Leaving]