<alyssa>
icecream95: I just used the network manager gui and it worked :o
<macc24>
alyssa: ok il rebuild
<macc24>
alyssa: btw icecream uses void linux
<macc24>
oh and sway works now
<macc24>
alyssa: dmenu colors are good \o/
<macc24>
and supertuxkart works \o/
<macc24>
particles still missing tho
<alyssa>
:)
<macc24>
poke me when you update merge request with newest commits so i can put tested-by there
<alyssa>
fighting unreliable wifi
<macc24>
haha i feel that
<macc24>
realtek?
<alyssa>
meh
<HdkR>
All wifi is unreliable
<macc24>
after switching from wifi to ethernet cord my internet speed went up 40 times
<alyssa>
this is worse
<alyssa>
time=3034 ms
<macc24>
i had like 4mbps on wifi
<HdkR>
That's some pretty nice latency
<alyssa>
connection dropping
<alyssa>
i just
<macc24>
rip
<alyssa>
i am just trying to do a damn apt update
<urjaman>
wifi reminds me to mention, not that anyone here cares of such cards here :P, but the C201 broadcom wifi is no longer a horrible laggy experience to ssh into in 5.10
<urjaman>
just something i noticed after the update
<macc24>
urjaman: they fixed it? :o
<macc24>
nice
rando25892 has quit [Ping timeout: 264 seconds]
raster has quit [Quit: Gettin' stinky!]
<icecream95>
I somestimes get >1s latency across the LAN even without unreliable wifi...
<alyssa>
Oof.
<HdkR>
icecream95: Network switch buffer bloat?
<HdkR>
and switches without full throughput support?
<macc24>
HdkR: on my switch with no fancy features(it's a openwrt router) i have no issues
<HdkR>
A lot of consumer grade switches are pretty bad :P
<macc24>
old and consumer grade is even worse hehe
<macc24>
i still have 100base-t switch for low-badwidth compud
<macc24>
bandwidth*
<icecream95>
old and consumer grade and from a terrible ISP is even worse
<macc24>
icecream95: it is not from isp
<macc24>
it's netgear with bcm53115skfbg
<HdkR>
icecream95: Yeet all ISP provided garbage
<HdkR>
I'm still annoyed that I couldn't remove the NPON->RJ45 converter from the ISP, but it seems fine
<macc24>
HdkR: npon?
<HdkR>
fiber line
<macc24>
,_,
<HdkR>
er sorry, GPON
<icecream95>
macc24: Is the top left corner of the touchscreen ever unreliable for you?
<macc24>
icecream95: i don't use touchscreen that often tbh
<macc24>
how much top left?
kaspter has joined #panfrost
<macc24>
icecream95: good for me
* icecream95
installs kruler
<macc24>
wev
<macc24>
make it floating and move to top left
<macc24>
that's how i tested it
stikonas has quit [Remote host closed the connection]
vstehle has quit [Ping timeout: 264 seconds]
rando25892 has joined #panfrost
kaspter has quit [Ping timeout: 264 seconds]
kaspter has joined #panfrost
<icecream95>
It seems to actually be an L shape instead of just a rectangle
<icecream95>
libinput debug-gui shows random jittering of the touch points
<macc24>
icecream95: nothing like that on my machine
<icecream95>
macc24: It doesn't happen all of the time, only occasionally
<br_>
seem depends on the level, i.e. amount of objects around the motorcyclist
nlhowell has joined #panfrost
<nlhowell>
br_: yup, they're ok
<nlhowell>
(rinet)
<br_>
nlhowell: I think their CTO is a FreeBSD committer
<nlhowell>
oh cool
nlhowell has quit [Remote host closed the connection]
nlhowell has joined #panfrost
<macc24>
finally, my usbc breakout boards arrived
agrisis has joined #panfrost
<bbrezillon>
alyssa: quick update (and a bunch of questions) on the blend shader save/restore regs stuff (AKA MRT)
<bbrezillon>
I tried implementing caller-based save/restore but it's kind of ugly for several reasons:
<bbrezillon>
1/ We have to use the caller stack, and thus need to be passed the offset where we should start saving the regs (that means passing an extra arg, and add ADD ops to the blend shader to calculate the store/load offset)
<bbrezillon>
2/ We don't know the registers used by the caller which forces us to save/restore all regs in the r4-r15 range that are used by the blend shader
<bbrezillon>
3/ We force the save/restore even for terminal blend calls
<bbrezillon>
The callee-based solution seems simpler to implement: I just need a pass spilling any of the r4-r15 regs that are live before a non-terminal BLEND and restore those after the BLEND.
<bbrezillon>
That'd be even better if I could let the RA know it should avoid putting live data in r4-r15 before a non-terminal BLEND instruction, but that's way beyond my skills :slightly_smiling_face:
<bbrezillon>
any opinion/suggestion/comment?
<bbrezillon>
alyssa: just pushed the bifrost-mrt branch
<alyssa>
1. I agree that having to offset everything in the blend shader is really ugly. It does come up with the blob if *both* the fragment and blend shaders actually spill. But even then there's instruction keying and it's just a mess and... yeah, best avoid...
<alyssa>
2. That'll be a perf issue no doubt. Of course, that would apply in the other direction if we aren't careful about reg alloc.
<alyssa>
3. Agreee that's bad.
<alyssa>
4. We can definitely teach RA some tricks :)
<bbrezillon>
hehe, that's where I need your help :)
<alyssa>
Right, so you can model that as interference.
<bbrezillon>
(see the ugly hack I came up with :P)
<alyssa>
eyes
<alyssa>
bbrezillon: Conceptually, RA's goal is to avoid interference, when two nodes are simultaneously live that means they can't overlap in the register file.
<alyssa>
Meanwhile you want the constraint "don't put anything live in r4-r15"
<alyssa>
But step back and ask why? It's because there's interference between those and some other node in the other shader.
<alyssa>
So... modeling that as actual interference in the frag shader isn't even a hack.
<alyssa>
Add some "pseudo nodes" for the purpose of RA that don't actually exist in the shader that are precoloured (l->solutions[_] = _) to r4-r15 and make them interfere with everything live where the blend could execute.
<alyssa>
It seems like a hack, but if you think about it, it really isn't :)
<bbrezillon>
the problem is, there's no node represening r4-r15, when an u16 is not wide enough to represent the r0-r15 range
<alyssa>
Right, add multiple of them then
<alyssa>
3 nodes for r4-r7, r8-r11, r12-r15, have them all interfere with what you don't want alloc'd there
<alyssa>
I think that should work but I haven't thought this through yet.
<alyssa>
bbrezillon: bi_{src,dest}_num_regs -- thank you for adding these, long term I'd like to do away with the random masks everywhere and just use those I think :)
<bbrezillon>
alyssa: you might also want to merge "pan/bi: Only copy the components we need when emitting blend ops" into "pan/bi: Workaround BLEND precolour with explicit moves"
<bbrezillon>
it saves a few moves
<alyssa>
bbrezillon: I merge whatever shows up as an MR in my inbox ;)
<alyssa>
bbrezillon: See midgard_ra.c L408 for a similar hack being done with r1
<bbrezillon>
no, I meant squash the content of this patch into your original patch, since it's not been merged already
<alyssa>
which original patch?
<bbrezillon>
pan/bi: Workaround BLEND precolour with explicit moves
<alyssa>
That was just for your MRT branch, I don't intend to submit it until you do :)
<alyssa>
I'm maintaining the scheduelr and vec2 branches, the other stuff is just support etc :)
<bbrezillon>
ack
<alyssa>
(aka squash/rewrite/burn that patch if you want, i won't be offended :p)
<raster>
alyssa: what is this with your M1 gpu funtimes? :)
<raster>
isn't it a bit soon.. we don't even have a frembuffer... hell not even a booting kernel :)
<alyssa>
raster: I'm allowed to have hobbies and expensive toys! :p
<raster>
hehehe
<raster>
i know. i'm taking the opportunity to poke some fun :)
<raster>
at this rate you'll know how the GPU works long before linux can even boot... :)
<raster>
hehe i know. i joined #asahi today ... :)
<alyssa>
Too noisy for me, #-gpu is where the cool kids are ;P
<raster>
keeping up with "stuff" :)
<raster>
well i noticed ... booting will be the first challenge so... focusing on that
<raster>
interesting read on the boot process. seemingly so ,much cleaner than many places...
<raster>
i like it
<raster>
well as much as i can like any boot processes today...
<alyssa>
depthcharge is pretty slim itself
* raster
misses the days when your rom loaded the first 512bytes from your floppy and started running it. that was it. your problem now
<macc24>
alyssa: i wouldn't call it slim
<alyssa>
macc24: not by iBoot standard i suppose
<macc24>
for me slim is just linux payload in coreboot
<raster>
alyssa: i never looked at the IMG GPUs... this is a custom apply gpu - not based in part on IMG right?
<raster>
or it seems it might be...
<raster>
(custom)
<alyssa>
raster: 🤷
<raster>
because as you describe it... it's almost... sane.
<alyssa>
yeah, I haven't seen anything scary yet
<macc24>
raster: sane or not, i will never buy m1 laptop
<alyssa>
and not that I don't love Mali GPUs but uh
<raster>
macc24: one will be turning up here anyway... if i like it or not :)
<raster>
alyssa: :) :P
<macc24>
raster: for me it makes no sense to give more money to company that is hostile towards linux
<raster>
macc24: i have no choice in that... :)
<raster>
but i am curious what this gpu of apple's is. what is smells like.
<pmjdebruijn>
raster: you mean, whether it's truely a new design, or something rebadged/pimped?
<raster>
yeah
<raster>
i'm curious
<raster>
did they buy IP from imgtec "outright" with some big pay-off so they can piggy-back on it then extend?
<raster>
or do their own entirely?
<raster>
or buy something else i don't know of?
<pmjdebruijn>
imgtec?
<pmjdebruijn>
oh the PowerVR peeps
<raster>
yeah
<raster>
they used to license imgtec gpu's
<raster>
news was a little while back that they dropped imgtec
<pmjdebruijn>
yeah I know, the abbreviation wasn't familiar to me
<raster>
so either they paid them off with a big fat blob of $ to "fork" the gpu
<pmjdebruijn>
that must have hurt, losing their biggest customer (I presume)
<raster>
or they were doing their own in the background and once it managed to equal the img part.. they dropped them. i don't know.
<pmjdebruijn>
over the years though Apple has amassed quite a bit of silicon expertise, so it's not unthinkable they really rolled their own
<raster>
if its img based.. it means we might eb able to re-use some other sw stacks/drivers to gain insight as imgtec did ship binary blobs for linux at times - certainly on android.
<raster>
if it's not ... then different ballgame
<raster>
but right now - i'm simply curious.
<raster>
unrelated to panfrost tho so definitely OT for here other than alyssa being involved :)