<alyssa>
Got the stuff for constant patching wired in
pH5 has quit [Quit: bye]
afaerber has quit [Ping timeout: 250 seconds]
afaerber has joined #panfrost
cwabbott_ has joined #panfrost
afaerber has quit [Quit: Leaving]
pH5 has joined #panfrost
anarsoul|2 has joined #panfrost
unoccupied has quit [Quit: WeeChat 2.2]
<alyssa>
System upgrade and now I have to recompile mesa from scratch, again
* alyssa
grumbles
<alyssa>
Didn't I do this.. yesterday?
<anarsoul|2>
:)
<HdkR>
That's always a pain
* alyssa
is itching to get panfrost upstreamed
<anarsoul|2>
alyssa: go for it!
<alyssa>
There's still too much -crap- in the driver for it to hit upstream tho
<alyssa>
Mostly winsys related but that's.. out of my control
<HdkR>
Winsys isn't in a great shape D:
<alyssa>
I could maybe send just the compiler/disassembler/assembler? but that doesn't help much
<Lyude>
alyssa: that's why I'm thinking of just getting this to work with the current mali_kbase driver
<alyssa>
That wouldn't solve the winsys issue?
<Lyude>
alyssa: would it not?
<Lyude>
sorry-i assumed the mess was just from the kernel stuff since you said "out of my control"
<alyssa>
Yeah,
<alyssa>
But remember how many hacks the blob does for winsys? ;)
<alyssa>
AFAIU it.. ---needs--- to at least pretend to be a DRM driver
<Lyude>
I mean, if we need hacks to get it to display stuff I think that's fine, since we're not planning on this being permanent
<alyssa>
with renderonly/X11/etc stuff
<anarsoul|2>
alyssa: I believe etnaviv did it
<anarsoul|2>
I don't think they had kernel driver from the very beginning
<alyssa>
anarsoul|2: how?
<anarsoul|2>
alyssa: check git log?
<anarsoul|2>
I can be wrong, but the first time I tried etnaviv - it used vendor's kernel driver
<Lyude>
yeah, I don't really think upstream will have a problem with that
<Lyude>
hardware working is better then hardware not working
<Lyude>
I think the only thing we need to be wary of is just making sure that it actually "works" on people's systems, without having to do anything different from a normal mesa build and getting the vendor kernel working
<Lyude>
*kernel mod working
<Lyude>
that, and fix the memory issues you mentioned
<alyssa>
again, as far as winsys is concerned... it -doesn't- really "work" in any real sense
<anarsoul|2>
hint: you may also want to put your kernel driver in staging... It'll require some clean up, but can be used as interim solution
<alyssa>
anarsoul|2: Was the vendor driver DRM?
<anarsoul|2>
alyssa: nope
<anarsoul|2>
:)
<alyssa>
you sure?
<anarsoul|2>
yes
<anarsoul|2>
well, 95% sure
<anarsoul|2>
5% doubt
<alyssa>
[citation needed]
<Lyude>
ask the etnaviv people yourself!
<alyssa>
Because the first commit for etnaviv was adding the renderonly library
<alyssa>
...which requires DRM it looks like?
<anarsoul|2>
alyssa: yeah, ask etnaviv people
<anarsoul|2>
I'm lima guy, we have drm driver written by yuq :P
<alyssa>
something I guess I should do is reformat everything to be mesa style
<anarsoul|2>
I noticed that some drivers use different code style
<Lyude>
i'd at least say have shorter lines
<Lyude>
imo we should try to match the mesa style but anarsoul|2 is correct-I know radeon uses their own style
<Lyude>
...granted, amd kind of does that for everything
<HdkR>
clang-format ftw? :)
<Lyude>
^ also that
<Lyude>
i'd just run clang-format and skim through the changes
<HdkR>
clang-tidy is useful as well if you want to do some more reworking of code style
<Lyude>
we should also start moving everything you need to build for panfrost into the mesa repo we have instead of having two; since we will need to do that eventually anyway
<alyssa>
I don't want to do that until we're ready to actually upstream since it makes rebases more painful
<Lyude>
alyssa: fair enough
<Lyude>
we'll save that for last then
<alyssa>
I also want to get panwrap merged into the main driver (so we get debugging nicely) but I haven't figured out how to do that in a way that's not insane
<Lyude>
alyssa: so; panwrap currently handles both tracing and also pandev, right?
<alyssa>
pandev?
<Lyude>
or whatever we call the actual interactions between the kernel and the mesa driver
<Lyude>
I haven't looked at panwrap in a while
<alyssa>
panwrap is just tracing these days
<alyssa>
and the bifrost assembler is there
<Lyude>
oh; then why don't we just make it an optional library that you can build against
<alyssa>
I want the code in-tree so I can get first-class decoding
<Lyude>
hm
<alyssa>
In the same way we have the Midgard disassembler in-tree
<Lyude>
maybe ask #nouveau how they did that; I think we have something similar for nouveau's mesa driver
<alyssa>
nothing special, just need to... do the move, I guess
<alyssa>
Task #1 is to gut as much code from panloader as possible (in a branch)
<alyssa>
-543 lines in one swoop
<alyssa>
Upon further thought, with that stuff gutted out, panwrap is fast enough for real-time tracing. Wat.
BenG83 has joined #panfrost
pH5 has quit [Quit: -_-]
<robclark>
alyssa, freedreno, vc4/v3d, and I think even etnaviv were upstream in mesa long before kernel existed.. I'm not 100% sure about etnaviv/vc4/v3d.. for freedreno I kinda abstracted the kernel interface in libdrm_freedreno (although for mali that is something that should live in mesa).. but in early stages as long as you don't break mesa build for others I think it is fine to get things landed in mesa and start pushing patches directly
<robclark>
upstream.. if nothing else it avoids pain when gallium apis change
<robclark>
if there is a sane way to abstract the kernel interface so it both works on current mali and eventual upstream driver.. that is possibly a useful thing from a logistical standpoint (since some users will be stuck on devices with only vendor kernel)
<robclark>
but don't feel you need to keep panfrost out of mesa tree until you have kernel ;-)