<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"
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