<kinkinkijkin>
does the T628 work on 32-bit hosts yet?
<kinkinkijkin>
by work i mean "not crashing and can display anything"
<kinkinkijkin>
anything at all, not everything
<kinkinkijkin>
if there's some level of function i can provide some time to testing
davidlt has quit [Ping timeout: 264 seconds]
kinkinkijkin has quit [Remote host closed the connection]
kaspter has quit [Ping timeout: 258 seconds]
<daniels>
karolherbst: both Panfrost and rockchip-drm (plus the others) always do linear for shared buffers in the absence of modifiers to instruct otherwise, so it's fine
<karolherbst>
ahh
<daniels>
tegra has really unfortunate ambiguity and also the need for shadow buffers
<daniels>
etnaviv has that as well, since textures are tiled-only, RTs are supertitled-only, and scanout is linear-only
<karolherbst>
I am wondering if we could away by also always doing linear.. but I don't think that would work that nicely as I am not sure if we can always render into linear
<karolherbst>
ughh
<karolherbst>
okay, then we kind of need a solution I guess
<karolherbst>
it's just annoying that "relevant" software is not useable at all :)
<karolherbst>
(and I see xorg 1.21 as unrelevant until it gets released)
<karolherbst>
*irrelevant
kinkinkijkin has joined #panfrost
<daniels>
you can't win at all with X11, since it can just dump stuff into the frontbuffer with no sync boundary to schedule detiling blit
<daniels>
sorry just going into the tube, bbl
<daniels>
but really I think linear is the only thing you can do without explicit modifiers, since you'll get dmabufs from sources like media who won't even necessarily be able to do tiling
<daniels>
but the kernel won't take those as new uABI ;)
<daniels>
if you want to do magic non-linear things for perf, and not have modifiers, you need to have an equally-magic kernel side channel
<karolherbst>
daniels: gnome/wayland also doesn't work
<daniels>
yes, exactly because tegra wants to do tiled or linear depending on magic non-modifier context, so you can't reason about it ... really GNOME just needs to be fixed to fall back to non-modifier paths
<karolherbst>
of course you can flip some option around to make it use modifier where we expect them
<daniels>
because Intel is the only platform more or less where using modifiers is less likely to work
<karolherbst>
if you enable modifiers in mutter, it works
<karolherbst>
but that's also besides the point
<karolherbst>
right....
<karolherbst>
and then intel is used as an excuse why using modifiers is bad
<karolherbst>
mutter experimantel-feature is called "kms-modifiers" btw... the annoying part really is just that we have all the bits already to make it work (Xorg 1.21, kms-modifiers support in mutter, ...) but none of that seems to arrive at the user, so it's not really useful to point any of that out as the current stack is not working
<daniels>
I know this story much more well than I would like to
<daniels>
ultimately Mutter just needs to be smarter
<daniels>
so if you enable the 'best' modifier you get a really hard cap on number of displays and/or resolution before you exhaust the FIFO
<daniels>
but I understand where they are, it's very hard due to technical debt and realistically not working for 4K external monitors on the most common platform just isn't an option for them
<daniels>
the core issue is that the most optimal modifier is Y-tiled (column-major tiling), but their display controller plane FIFO is scanline-oriented, and it's also tiny ... even by Arm standards
<karolherbst>
ehhh :/
<daniels>
I know this very well :( I spent a long time working on modifiers. unfortunately because of the way Mutter's designed it's really hard for them to fix it to fall back to blacklist modifiers
<daniels>
and from the Intel side, it's measurable perf gain on fullscreen games, and they need every bit of help they can get
<daniels>
so there's no obvious answer that's acceptable to everyone
<daniels>
Mutter are working on it but it really is a gradual rewrite ... X11 is a different story tho
<karolherbst>
yeah.. I mean at this point I'd go for anything that works reliably.
<karolherbst>
and we have patches to make it sort of work? but still X is pain
<nhp[m]>
How is KWin doing with this?
<karolherbst>
didn't try
<karolherbst>
but plasma on wayland is so broken, it's not worth checking it out
<nhp[m]>
True, plasma on wayland still has too many little issues that add up, and performance also seems quite bad with panfrost
<karolherbst>
I am sure the "FHD single display" case sort of works, but the reason to switch to wayland (like multiple displays with different dpi scalings) show a couple of bugs
<karolherbst>
like cursor suddenly upsaling and are super huge on wayland applications, but fine when hovering over X ones...
<karolherbst>
yeah..
<karolherbst>
I have to use wayland, so I run into all of them
<daniels>
rewriting your entire compositor is hard ...
<karolherbst>
right
<daniels>
who knew? :)
<karolherbst>
I am not blaming them, just saying it's not worth considering at this point
<karolherbst>
yes, it would be nice if it works, but if it doesn't work, I don't mind as much
<nhp[m]>
It sounds like 5.20 is getting some pretty solid Wayland improvements though, idk if it's enough to fix everything but it's going in the right direction for sure
<karolherbst>
daniels: best thing is, all compositors need to be completly rewriting again anyway...
<karolherbst>
I think mutter devs are slowly at the point where they actually want to do the proper rewrite
<karolherbst>
but none of the others are
<karolherbst>
afaik
<karolherbst>
even wayland compositors don't do the right thing
<daniels>
Weston is perfect
<karolherbst>
nope
<daniels>
it just doesn't have an actually usable UI
<karolherbst>
does weston use multiple render contexts for each GPU?
<karolherbst>
if not, it's not fine and needs to be rewritten :)
<nhp[m]>
(Wayland compositors can use multiple GPUs?!)
<daniels>
no, because there's no good answer to that - X11 had hard per-Screen divergence originally, then it had to merge all the screens into one Screen so you could drag your windows between screens
<karolherbst>
right
<karolherbst>
but that's a huge problem
<karolherbst>
and it will be even bigger if 8k displays and stuff become a thing
<daniels>
yes, but what's the answer?
<karolherbst>
4k is already.. ugghh
<karolherbst>
daniels: you render local to the GPU
<karolherbst>
aways
<daniels>
I mean they use separate surfaces
<daniels>
right
<karolherbst>
applications might be somewhere else
<daniels>
that makes sense but you need to migrate the clients too to be at all useful
<karolherbst>
but the compositor + desktop and everything has to be local
<karolherbst>
migrating is a second step
<karolherbst>
but yes
<daniels>
but the kernel can't describe placement constraints ..
<karolherbst>
it's part of the problem
<daniels>
sales@collabora.com :P
<karolherbst>
not saying the solution is easy, just whatever rewrite people are doing, it's still not the solution and just requires a new rewrite
<daniels>
we've been chipping away at some of the core foundation parts
<karolherbst>
which makes it all very frustrating
<daniels>
Weston is very well placed for it
<daniels>
but it's a really unsexy problem
<karolherbst>
yeah.. some compositors might need smaller changes
<karolherbst>
but something like kwin?
<karolherbst>
just start from scratch imho
<daniels>
and as someone whose business model involves directly exchanging time for money ...
<daniels>
starting from scratch will never happen as long as we have X11 clients (forever) and hosts (NV)
<karolherbst>
we've been discussing this "how should compositor look like in the future" a few times internally and I think most people involved have the right vision on things
<karolherbst>
daniels: yes.. which is just part of the problem
<karolherbst>
you just have two compositors then, one for X, one for wayland
<karolherbst>
or rewrite from scratch in a way it works on both
<karolherbst>
but porting the X one over?
<karolherbst>
ughh
<karolherbst>
but I am sure peopel can abstract enough stuff to make a full rewrite way easier though
<karolherbst>
it's just... we don't have enough people/money/whatever to actually do it
<karolherbst>
which makes it really furstrating
<daniels>
reimplementing the X11 WM semantics is impossible; it would probably be quicker & easier to replace NV proprietary with nouveau tbh
<daniels>
and I know you know how much effort _that_ involves :)
<karolherbst>
:)
<karolherbst>
but I don't think it's an easy anymore
<karolherbst>
people are becoming more pragmatic it seems
<karolherbst>
sure there are nice features we still lack with wayland, but a lot of the things nvidia just has to care of themselves anyway
<karolherbst>
anyway...
<karolherbst>
it would be nice if at some point we have this modern desktop which just works :)
<karolherbst>
and displays on secondary GPUs don't suck
<karolherbst>
if I would have to guess, it will take like 10 years
<karolherbst>
(the first desktop to do it properly will be around much sooner, but then you need to convince others it's the only soltuion, etc..)
<daniels>
and, eh, you've got a lot more people & money than we do haha
<daniels>
one day tho ...
<daniels>
then I can retire
<karolherbst>
yeah...
<daniels>
you're not allowed to retire until nouveau is finished tho :P
<alyssa>
kinkinkijkin: you'd have to compile from source and patch in the GPU ID... I expect some things to be broken but there's a good chance there's enough to run a basic desktop. Not tested though.
<kinkinkijkin>
I'll get to testing soon then
<kinkinkijkin>
memeka did some testing in the past and found kmscube loadable a year ago so I am hopeful
<alyssa>
Can't promise anything (and it may well be "black screen, dmesg spammed with faults, that's it")... but if you're bored on a Saturday, it's worth a try
<alyssa>
And yeah, things worked at one point. But bisecting a year's worth of commits is probably not your idea of fun.
<alyssa>
mesa/src/galium/drivers/panfrost/pan_screen.c has the ID detection code
dstzd has joined #panfrost
<kinkinkijkin>
wait a sec, project was moved from linux into mesa or?
<alyssa>
?
<kinkinkijkin>
base tree, i might just be misreading you
<alyssa>
the kernel driver is in linux, the OpenGL driver is in mesa
<alyssa>
you need both
<dstzd>
does anyone happen to know what "AFBC format[3231564e]" is?
<alyssa>
Linux 5.2+ should work for t628, it's mesa that's more delicate (and most of the code is in mesa)
<alyssa>
dstzd: context for the [...]?
<kinkinkijkin>
alright
dstzd has quit [Quit: dstzd]
<kinkinkijkin>
might take me a while to get the testing environment together though as the sd adapter for my mmc card broke, and I'm not testing this from my sd card
<alyssa>
dstzd: AFBC on rk3399 is broken on mainline fwiw
<alyssa>
so panfrost doesn't use it without debug flags
<dstzd>
I even built with your patch
<alyssa>
ok, in that case..
<dstzd>
i guess i could be missing some extra stuff that is in next/dri-devel/5.9 though i'm on 5.8.3
<alyssa>
"3231564e" parse that as "32 31 56 4e", swap since little-endian, hex->ASCII
<alyssa>
"NV12"
dstzd has quit [Client Quit]
<alyssa>
...better question is why you're getting an NV12 format at all, since panfrost doesn't support yuv framebuffers (afaiu the hw does but we don't pipe it through)
dstzd has joined #panfrost
<dstzd>
could it be the compositor (wayfire/greetd(gtkgreet))? I think it happens earlier then display-manager.service though
<urjaman>
you missed this message as you bailed out in the middle of things: 20:59 <@alyssa> ...better question is why you're getting an NV12 format at all, since panfrost doesn't support yuv framebuffers (afaiu the hw does but we don't pipe it through)
<dstzd>
this connection kind of sucks but i saw it on whitequark
<kinkinkijkin>
rebooted into the device to get to work setting up the testing environment
<HdkR>
Lemme know how it goes
<kinkinkijkin>
alyssa, for the test desktop (if i get to a desktop) what environment would you recommend? wayland with weston, or sway, or gnome3?
<kinkinkijkin>
i will, hdkr
<alyssa>
start with weston
<alyssa>
if weston works, sway probably will
<alyssa>
if both work, gnome3 wayland hopefully will
<alyssa>
and if all of the above works, maybe gnome3 x11 will
<alyssa>
good luc k:P
<kinkinkijkin>
alright, yeah thats what i was thinking too, just had to make sure
<kinkinkijkin>
im not going to test x11 unless i have to
<kinkinkijkin>
okay, rebooting into the test environment
kinkinkijkin has quit [Remote host closed the connection]
raster has quit [Remote host closed the connection]
Depau has quit [Ping timeout: 258 seconds]
dstzd has joined #panfrost
<hanetzer>
yech, gnome3
davidlt has quit [Ping timeout: 246 seconds]
<dstzd>
so any ideas why it might be choosing NV12?
kinkinkijkin has joined #panfrost
<kinkinkijkin>
alright, I'm in the test environment with the kernel I will be using installed and the system fully working so far
<kinkinkijkin>
how exactly should I go about modifying mesa and installing the modified mesa? I'm not in a gui rn
<kinkinkijkin>
(i also don't have the log of the file you told me to modify since that's on another computer)
<kinkinkijkin>
oh should probably mention alyssa since that's who i was speaking with previously
<kinkinkijkin>
should i just clone the (forked?) mesa repo and then modify the file, build normally? if so i need to know which file to modify and where the repo is
<kinkinkijkin>
i meant configure the build as in alter the configuration
<kinkinkijkin>
nevermind, ill just figure out how to get libdrm >=2.4.102 on armbian, 2.4.96 is what was installed
<kinkinkijkin>
wanted to see if there were a switch to drop nouveau so i could see if that alleviated it
<kinkinkijkin>
do I need to compile libdrm with the exynos api?
<kinkinkijkin>
nvm did anyways
<HdkR>
I guess you'd need it for display output
<HdkR>
Mali-G isn't a display controller
Depau has joined #panfrost
<kinkinkijkin>
weston confirmed working
<kinkinkijkin>
hdkr alyssa
<kinkinkijkin>
ran with drm backend
<HdkR>
neat
<HdkR>
I guess I should probably flash one of my XU4 devices with the latest ubuntu image and panfrost
<kinkinkijkin>
lots of flickering
<kinkinkijkin>
oop flickering stopped when i switched to this vt then back
<kinkinkijkin>
gonna try opening a window of firefox
<kinkinkijkin>
it works but there's some flickering still and some sticking regions
stikonas_ has joined #panfrost
kinkinkijkin has quit [Read error: Connection reset by peer]
buzzmarshall has quit [Remote host closed the connection]
buzzmarshall has joined #panfrost
Depau has quit [Ping timeout: 258 seconds]
karolherbst has quit [Quit: duh 🐧]
karolherbst has joined #panfrost
kinkinkijkin has joined #panfrost
<kinkinkijkin>
yeah this is almost usable
<kinkinkijkin>
just got sway running
<kinkinkijkin>
still having flickering, the flickering is always the next item back showing through
<kinkinkijkin>
but it's in regions
<kinkinkijkin>
okay, it's a little late for me compared to when I usually sleep, so I will go, but I will keep this open and test/message more when I wake