ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
camus1 has joined #panfrost
camus has quit [Read error: Connection reset by peer]
* icecream95
has found another ancient Midgard compiler bug, this one was added in October 2019
<alyssa>
Nice!
<alyssa>
icecream95: Register allocation?
<icecream95>
alyssa: swizzles
<alyssa>
ah
* icecream95
is wondering how to split up the 19 commits remaining in the push constant/sysval MR for review
rasterman has quit [Quit: Gettin' stinky!]
atler is now known as Guest1827
atler has joined #panfrost
Guest1827 has quit [Ping timeout: 480 seconds]
stano_ has joined #panfrost
<macc24>
this is my favourite hack: scp vmlinux.kpart root@192.168.0.227:/dev/mmcblk1p1
<alyssa>
macc24: I'm not even a little ok with that.
<alyssa>
But, er, yes I suppose that works.
<macc24>
alyssa: how about dd if=vmlinux.kpart | ssh root@192.168.0.227 dd of=/dev/mmcblk1p1 ?
<alyssa>
Oddly bothers me less even though it's more opaque
stano has quit [Ping timeout: 480 seconds]
<macc24>
tunneling dd like a pro™
<macc24>
good news is that i got anbox working(again)
<macc24>
most apps refuse to work tho
<macc24>
i'm kinda thinking of just straight up android
<icecream95>
macc24: emacs /dev/mmcblk1p1 ^X i vmlinux.kpart ^M ^X ^S
camus has joined #panfrost
camus1 has quit [Ping timeout: 480 seconds]
camus1 has joined #panfrost
camus has quit [Remote host closed the connection]
cphealy has quit [Remote host closed the connection]
camus1 has quit [Remote host closed the connection]
camus has joined #panfrost
WoC is now known as Guest1858
WoC has joined #panfrost
Guest1858 has quit [Ping timeout: 480 seconds]
<urja>
yeah the tunnel version i'm way more happy with (... not commenting on the emacs lol)
<urja>
(actually i use tar tunneled through ssh way more than scp, such flexibility and tar does pretty good with even special files, links etc by default)
camus has quit [Remote host closed the connection]
camus has joined #panfrost
rando258` has quit [Ping timeout: 480 seconds]
camus1 has joined #panfrost
camus has quit [Ping timeout: 480 seconds]
<tomeu>
bbrezillon: I'm thinking about taking the CmdCopyImageToBuffer impl from your blit+blend branch so I can more easily test
<tomeu>
that branch conflicts quite a bit with main right now
<bbrezillon>
tomeu: ok
rasterman has joined #panfrost
<tomeu>
bbrezillon: btw, do you have handy the tests you used for img2buf?
<bbrezillon>
tomeu: I was testing with dEQP-VK.api.copy_and_blit.*
<bbrezillon>
but you'll need more than just img2buf for that ;-)
<bbrezillon>
tomeu: there's no way we can have it all passing in one go, so let's just accept regressions for a while
<tomeu>
ack
<bbrezillon>
I mean, it doesn't matter if you can't test you ClearAttachments with upstream
<tomeu>
I have enough to have all ClearAttachments tests passing
<tomeu>
guess that's enough coverage for now
<tomeu>
dEQP-VK.api.copy_and_blit.core.image_to_buffer.* need CmdCopyBufferToImage as well
<tomeu>
bbrezillon: guess I could look next at the rest of your meta impls, now that I'm somewhat familiar with it
<bbrezillon>
tomeu: sounds like a good plan. do you have a way of testing on Midgard too?
<bbrezillon>
IIRC, all tests were passing on Bifrost
warpme_ has joined #panfrost
wwilly has quit [Remote host closed the connection]
wwilly has joined #panfrost
<tomeu>
bbrezillon: my nanopc is dead, would need to get something else for that
wwilly has quit [Remote host closed the connection]
wwilly has joined #panfrost
wwilly has quit [Remote host closed the connection]
<bbrezillon>
tomeu: ok, I'm tempted to merge the clearattachments MR without the cmd2buf patch, even if that means we can't really test it
<tomeu>
bbrezillon: I think the difficulty in testing is a major obstacle right now, so I'm for merging now what allows tests to run
<bbrezillon>
then it will require another round of review I fear
<tomeu>
bbrezillon: oh, I'm fine with merging it as you say, I have no problem in opening new MRs
<tomeu>
but your code is unchanged ;)
<bbrezillon>
tomeu: I know, but alyssa had concerns about this solution
<bbrezillon>
and reviewing my own code would be pretty useless
<bbrezillon>
tomeu: what's missing for the clearattachments+MRT test to work?
<bbrezillon>
*tests
<tomeu>
this, I think you said that I should be splitting the batch?
<bbrezillon>
like when you want to clear all layers of a 3D or 2D-array tex
<tomeu>
hmm, let me check what the test does to hit that assert
camus has joined #panfrost
<tomeu>
bbrezillon: ah, it happens when the framebuffer was created with an imageview with a layer range other than 0-1
camus1 has quit [Ping timeout: 480 seconds]
<tomeu>
but I don't see why a test that has cmdClearAttachments as its only command hits that
<bbrezillon>
because it's a clear on a multi-layer resource
<bbrezillon>
tomeu: we don't support that yet, but that's also orthogonal to MRT (which I think we support)
<tomeu>
bbrezillon: but, what vulkan command causes the clear that causes the assert to be hit?
<bbrezillon>
tomeu: CmdClearAttachments() is just a Draw (or a set of Draws), so you end up issuing fragment jobs, which need to have FB attached to them
<bbrezillon>
we can only render one layer at a time, so we basically expects FBs to be created with VkFramebufferCreateInfo.layers = 1, which I guess is not the case in this test
<bbrezillon>
for multi-layer rendering to work properly, we need to have one FB desc per layer (and incidentally on fragment job per layer)
<bbrezillon>
I guess that also means dispatching one draw per-layer everytime vkCmdDraw() is called
<bbrezillon>
and we might also want to consider chaining fragment jobs the same way we chain vertex/tiler jobs when doing multi-layer rendering
<tomeu>
so we can have more than one fragment job per batch?
<bbrezillon>
right
<tomeu>
bbrezillon: so emit the fragment job after emitting each tiler job?
<bbrezillon>
nope, not each tiler job
<bbrezillon>
emit all vertex/tiler jobs (submit the vertex/tiler job chain to the kernel driver), and then emit all fragment jobs (submit the fragment job chain with a dep on the vertex/tiler submission)
<bbrezillon>
that's already what we do right now, except the fragment job chain only contains one job
<tomeu>
oh yeah, I remember now from the gallium driver
<tomeu>
bbrezillon: it stills fails in the same way, but even if it did turn the test to Unsupported, that wouldn't help to test RT > 0 and MRT in clear attachments, right?
<bbrezillon>
tomeu: I posted a new version
<bbrezillon>
but you're right, it won't help with the RT > 0 test
<tomeu>
bbrezillon: oh, it doesn't cause any unsupported (the test doesn't seem to be testing for that), and we can run it without hitting the assert:
<bbrezillon>
tomeu: vkCmdClearAttachments() is passed a <baseArrayLayer,layerCount> tuple, so we really need several fragment jobs here, unfortunately
<bbrezillon>
this being said, I wonder if it's supposed to work when fb.layers == 1 and the cleared region goes beyond attachment_view.baseArrayLayer
floof58_ has quit [Ping timeout: 480 seconds]
nlhowell has joined #panfrost
nlhowell has quit [Ping timeout: 480 seconds]
camus1 has joined #panfrost
cphealy has joined #panfrost
floof58_ has joined #panfrost
camus has quit [Ping timeout: 480 seconds]
<macc24>
apparently nvidia used mt8195 to demo rtx on arm
<alyssa>
macc24: crap ~~do i~~ does bbrezillon need to implement ray tracing in panvk
<macc24>
alyssa: the bigger question is whether raytracing kills that poor little mali or not xD
<macc24>
mali g3060 rtx
<alyssa>
speaking of dead malis I'm going to need a new charger for my rk3288 chromebooks.
<macc24>
why
<alyssa>
there was a.. err... incident involving plugged in computers, an emergency trip to the washroom, and gravity
<macc24>
uh you are not getting 10 hours of battery life on your arm chromebooks?
nlhowell has joined #panfrost
nlhowell has quit [Ping timeout: 480 seconds]
<urja>
both of the C201 batteries i'm using are not as spicy as they were ... years ago ... anymore ... i know, shocking :P
<macc24>
ughhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh here i go optimizing battery life
camus1 has quit []
<alyssa>
Step #1: Turn off the GPU.
* macc24
considers anything below 8h in "normal" usage unusable
<urja>
one of them (the one in the chromeos one) is like an hour (or two, i mostly dont use it because the battery gauge cant make heads and tails of it anymore) lol (so, it's an UPS...)
<urja>
the other one is atleast 5 hours still i think, but also i dont need that for anything either really, since they're always withing range of a charger
<daniels>
alyssa: is it not type-C?
<urja>
RK3288
<urja>
it's a funny ASUS special square power connector
<urja>
or .. not square, but rectangular
<urja>
squished square lol
<urja>
i've re-terminated the connectors like 3 times on both of the chargers... the actual connector is fine, but the connection between the connector and the wires is not good by default :P
<urja>
classical wire problems tbh
<alyssa>
daniels: ^
<daniels>
yeesh
<daniels>
alyssa: well, feel free to expense :)
<macc24>
huh
<macc24>
it's probably possible to put usb-c port onto there
<urja>
hm
<macc24>
it's just 12v and there probably are usbc breakout boards that make charger put out 12v
* urja
owns 0 usb-c things
<urja>
i mean, not yet ... when the glasgow ships i'll have one device with the connector (that's still just a normal 2.0 device internally... *shrug ok*)
<icecream95>
alyssa: And yesterday I got a new USB-C cable to be able to charge duet again after an incident also involving gravity
<alyssa>
icecream95: Something has changed within me.. something is not the same...
<macc24>
y'all should try getting some extension cords to *not* trip over cables
<icecream95>
urja: "connection is not good by default". Is that why I've had to charge speedy at only 200mA for the past few years? (using ectool to limit the current)
<icecream95>
[Actually only 192mA because it's in 64mA increments]
<macc24>
icecream95: ??? my cheap-ass charger can do much more than 200ma
<icecream95>
macc24: Maybe *your* charger, by my charger has probably had some incidents involving gravity itself
<macc24>
how many times have you dropped it?
<urja>
hm. never had issues of that sort... just effectively stress fractures from all the wiggling at/near the connector, so it's either connected or not (or "it needs to be in this position to have power")
<urja>
that one does sound more like the 12V power supply having troubles ... that part has never failed me, even after an internal fault in the wire that caused repeated short circuits lol
<urja>
that one is fun tho, if the laptop is charging and you short the wires, the laptop will reset ... yeah, not fast enough to react to that are ya charger
<macc24>
TIL that you can bind tablet mode changes in sway to commands
<icecream95>
urja: When it first happened I could still charge at normal speed if I fiddled with the cable position, but over time it got harder and I eventually disovered the ectool subcommand and gave up
<icecream95>
I think I still have a script running that checks the battery charging current every few seconds, and if it is not charging as well as it should it decreases the limit
<icecream95>
macc24: The force between duet and the ground was enough to cause the metal-bit-on-the-outside to be at an angle it was not supposed to, and it came out completely when I tried to fix that
<macc24>
icecream95: damn this could have ended much worsely
<alyssa>
s/ly//
<macc24>
s#s/ly//##
<icecream95>
/ly/d
<alyssa>
adssa would like a word
<icecream95>
That deletes the whole line
<icecream95>
(so alyssa would *not* like a word?)
<macc24>
what
<icecream95>
a[l][y]ssa: Wait, have I deleted you completely? So sorry, I didn't mean to do that...