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
atler is now known as Guest1699
atler has joined #panfrost
Guest1699 has quit [Ping timeout: 480 seconds]
<macc24>
alyssa: do you have time to do some experimentation on s21?
<macc24>
may or may not be postmarketos related
jambalaya has quit [Remote host closed the connection]
camus1 has quit [Remote host closed the connection]
<icecream95>
alyssa: Is the strategy for swizzles on Midgard really "randomly compose swizzles and hope the types match up"?
<icecream95>
(I suppose from complaining about it last it's now my job to clean that all up...)
<tomeu>
bbrezillon: don't we need the shaders too be indexed as well per num of components?
<bbrezillon>
tomeu: you can set a write mask at the blend desc level, so I'd say no, but maybe I'm missing something
<tomeu>
hmm
<tomeu>
will give that a try
<bbrezillon>
tomeu: vkCmdClearAttachments doesn't let you clear a specific component on a color buf, does it?
<tomeu>
no, only color vs depth vs stencil
<tomeu>
bbrezillon: I was thinking of the out var of the shader having to match the number of components of the format of the attachment, but I guess it doesn't need to if the blend descriptor has a mask for that
<bbrezillon>
no, just set it to 4 components, the blend logic will pick only the actived components based on the format+mask
<bbrezillon>
tomeu: indeed. I guess we can keep MALI_BLEND_OPERAND_A_SRC, since the component will be discarded anyway
wwilly has quit []
warpme_ has joined #panfrost
<tomeu>
Failed: 20/715 (2.8%)
<tomeu>
getting there :)
<tomeu>
Failed: 0/715 (0.0%)
<tomeu>
\o/
<bbrezillon>
yay!
camus has joined #panfrost
camus1 has quit [Ping timeout: 480 seconds]
<alyssa>
icecream95: The strategy for Midgard is to hope it works and close any bug reports as wontfix ...
<macc24>
...
<alyssa>
but yes midgard swizzles/types were done before understanding how that worked at a hardware level and by the time that was clarified bbrezillon and I were 100% bifrost
wwilly has joined #panfrost
warpme_ has quit [Quit: Connection closed for inactivity]
camus has quit [Remote host closed the connection]
camus has joined #panfrost
<tomeu>
would be a pity to lose midgard support, specially as can CI it, but it would probably be a bigger pity if it slowed down panvk, or valhall support
<bbrezillon>
tomeu: thanks, I'll try to review it tomorrow morning
<tomeu>
bbrezillon: deqp tests don't pass on that branch though because they need cmdCopyImageToBuffer
<tomeu>
I could pull it from your blit branch
<bbrezillon>
tomeu: I don't think that's a problem
<bbrezillon>
at least not until we start enabling CI on panvk
<alyssa>
tomeu: midgard isn't going anywhere :)
<alyssa>
i would sooner delete bifrost support than midgard and daniels says I can't do that
urja has quit [Read error: Connection reset by peer]
urja has joined #panfrost
<robmur01>
heh, "this probably lets the Mali toolchain build under Windows, but I refuse to test that"
* robmur01
has a weekend coming up...
<alyssa>
robmur01: icecream95 reports it works, at least under wine
<robmur01>
the idea of trying MSVC for the full "native cross-compile" experience is too much of a giggle to ignore, though :D
<alyssa>
robmur01: oh no
warpme_ has joined #panfrost
<macc24>
alyssa: "midgard isn't going anywhere" <- does that mean if someone fixes t6xx you'd maintain it? xD
<alyssa>
macc24: Probably
<alyssa>
I'm still maintaining T720 support and I don't even /have/ T720 hardware
<alyssa>
Handling immediates efficiently on Valhall will require nontrivial effort ... probably not suitable for pre-breakfast work
<alyssa>
I should eat something 😋
* macc24
throws apple at alyssa
<HdkR>
alyssa: Still can't encode full 32-bit immediates in to every instruction? :<
wwilly has quit []
<alyssa>
HdkR: Definitely not :<
<HdkR>
Dang
<alyssa>
you could on Bifrost but it was filled with caveats up to the--- err
<alyssa>
and could on Midgard without caveats
<HdkR>
At least have a move with immediate though?
<alyssa>
Yeah
<alyssa>
ACtually have add immediate in every type/size
<alyssa>
canonical move immediate is iadd_imm.i32 #0
<HdkR>
ah neat
camus1 has joined #panfrost
camus has quit [Ping timeout: 480 seconds]
<Lyude>
alyssa: would it help to have some?
<Lyude>
access to hw, I mean
camus has joined #panfrost
camus1 has quit [Ping timeout: 480 seconds]
<urja>
:D
<alyssa>
Lyude: hardware is cheap, time/attention is not
<Lyude>
gotcha
* macc24
]noted
<HdkR>
Never waste people time on flakey hardware that can be solved by throwing a bit of money at the problem. People time is worth significantly more than hardware.
<HdkR>
Same thing with flakey software. If one piece of software is wasting someone's time and another option is available that would immediately solve it, buy it and stop burning time :)
<Lyude>
HdkR: ?? is this aimed at me?
<HdkR>
It's aimed at everyone. everyone is worth more than some crummy hardware or software :D
<urja>
nobody is paying for my time -.-
<urja>
oh well, hopefully that'll change (and well, in a couple of weeks ... well, i'll have less time but still nobody really paying for it lol, aka education...)
<HdkR>
Surely even without monetary compensation, you're still spending time. Don't devalue what your time is worth
<urja>
anyways the point was, the exception is: money 404
<macc24>
urja: we're in this together my shitbox pc randomly hangs for no reason xD
<urja>
i mean, my FX8320 is mostly stable... but no way would I have that as a PC if i'd have extra money lol
<urja>
it's a ridiculous heater disguising as a CPU
<macc24>
*lga771 xeon silence*
<macc24>
btw
<macc24>
if i'm reading dts memory node correctly, some asurada machines might have 8gb of ram lol
<HdkR>
Good
<HdkR>
4GB of ram isn't viable these days
<macc24>
now it only should support 3 external monitors, native gigabit ethernet, pcie and 6 usb ports and it can replace my desktop system
<HdkR>
uh huh
<macc24>
i miss my thönkpad
rasterman has quit [Quit: Gettin' stinky!]
wwilly has joined #panfrost
<icecream95>
alyssa: On the topic of T720 support, IIRC spilling on SFBD GPUs has been broken for a while (see pan_emit_tls, note the size of "TLS Size" in the XML)
<alyssa>
I'd believe it
<alyssa>
Oh yeah that's real broken
camus1 has joined #panfrost
camus has quit [Ping timeout: 480 seconds]
<icecream95>
alyssa: The original code there was effectively MAX2(shift, 5), but I wouldn't be surprised if that was broken too...
<alyssa>
Probably.
<alyssa>
Either there was some hw errata and I was playing monkey see monkey do with the DDK, or it was just straight up always broken.
<icecream95>
"Nevertheless it's enabled on RK3399 at least". Somehow I misread that, and have spent the last year wondering why people using RK3399 never complained about the lack of DXTn texture support... (that was from !5856)
<alyssa>
yeah, RK3399 enables All the formats while RK3288 doesn't ... not sure why
* robmur01
still has a vague intention of re-testing the outstanding T720/T820 bug reports
<alyssa>
these are integration decisions
<macc24>
alyssa: rk3288 is missing formats?
<alyssa>
macc24: yeah
<macc24>
alyssa: which ones?
<alyssa>
as I understand, RK3288 has all the silicon but it's fused out in hardware because patents
* macc24
smells hardware bugs
<alyssa>
robmur01: is about to correct that statement for being obnoxiously false
<robmur01>
I have now bodged the Juno to the point where it boots and I can log in again, but `file /usr/local/bin/glmark2-es2-drm` says it's a Git packfile, that's how trashed the disk is...
<alyssa>
macc24: DirectX formats. DXTn, RGTC, etc
<robmur01>
IIRC RK3288W has DX formats enabled (like RK3399), but original RK3288 doesn't
<alyssa>
i.e. any compressed formats that's not AFBC or ASTC
<daniels>
RK3288W is a variant of RK3288 where they paid the extra license fees for those formats
<macc24>
alyssa: wait, rockchip is based in china, so why do they even care about patents?
<alyssa>
macc24: As of RK3399 it seems they do not :p
<icecream95>
alyssa: Does RK3399 support even BC6H and BC7?
<icecream95>
(G72 does not)
<macc24>
alyssa: what if i just fed rk3288 gpu s3tc textures xD
<icecream95>
G72 as in MT8183
<robmur01>
RK3288W also has a newer revision of T760 altogether
<daniels>
from what I understand, Rockchip isn't subject to the patents per se, but the license fee is paid for by Arm for each Mali unit shipped, so the integrator decides whether or not to enable those pieces, and if they do then they pay Arm more $$ per unit
<robmur01>
macc24: it won't understand them if they're not enabled
<macc24>
huh
<alyssa>
icecream95: BC6H and BC7 are architecturally defined in G72
<alyssa>
so that's a matter of MediaTek not flipping th bit
<cphealy>
Didn't the patents for S3TC expire?
<macc24>
cphealy: iirc they did
<cphealy>
a few years back, IIRC.
<cphealy>
That's why Mesa started supporting it.
<macc24>
"Some (e.g. US 5956431 A) of the multiple USPTO patents on S3 Texture Compression expired on October 2, 2017"
<cphealy>
Or am I confusing it with ATITC...
<macc24>
oops i think they all expired
<macc24>
(s3tc patents)
<alyssa>
icecream95: As for rk3399 texture support let's see if I can remember the incantation to check
<alyssa>
nope
* alyssa
adds a pritnf to mesa so she doesn't have to learn sysfs
<alyssa>
Textures 0: 1FFFFDE
<alyssa>
so... yes, that includes BC6H and BC7
<cphealy>
alyssa: which GPU support BC6H and BC7?
<alyssa>
RK3399 apparently
<macc24>
icecream95: if texture support touches drm display driver in mt8183 it might be fault of mediatek_drm being pure wtf :p
<icecream95>
macc24: nope, encoding those formats is far too slow for a display driver to want to have anything to do with it
<alyssa>
^ indeed
<HdkR>
ooo, Valhall MRs
<macc24>
\o/
<macc24>
i have a feeling that one of those MRs breaks g72
<alyssa>
macc24: A reasonable assumption, I only tested them on AGX 😋
<macc24>
that's it
<macc24>
i'm testing it
<alyssa>
I need to write tests for my tests :V
<macc24>
CI
<alyssa>
macc24: You joke but !12025 will test the valhall disassembler and assembler in mesa CI
<macc24>
i should make cadmium CI to check if stuff still boots up fine xD
rasterman has joined #panfrost
warpme_ has quit [Quit: Connection closed for inactivity]
<macc24>
alyssa: !12026 and !12025 both work on g72
<alyssa>
I miss G72 CI.
<macc24>
lol why it's offline?
<alyssa>
Instability, likely kernel related
* macc24
sighs
<macc24>
fun fact: logind thinks that your device is docked if it has tablet mode switch and it won't suspend by default on lid closing
<macc24>
lol duet is providing power and kinda maintaining communication on usb so poking keyboard can wake it up
camus has joined #panfrost
camus1 has quit [Ping timeout: 480 seconds]
<icecream95>
alyssa: While I'd say f'that {f_strings}' are fine in developement tools, for Python code used in the actual build process maybe stay away from them in case people are trying to build Mesa with ancient Python versions
<alyssa>
f'strings' are new?
* alyssa
doesn't pretend to know Python
<icecream95>
in 3.7 I think
<alyssa>
looks lik3 3.6, which was released at the end of 2016
<alyssa>
PEP 478 says that 3.5 reached EOL in September 2020
<macc24>
if someone hasn't updated their python from 5 year old version they shouldn't build freshest mesa version
<alyssa>
so I think it should be fine
<alyssa>
Current Debian stable has 3.7
<alyssa>
(and we're in the freeze anyway so will soon get the 3.9 bump)
<alyssa>
I'm not aware of any good reason to run anything older than Debian stable 😋
<macc24>
alyssa: nostalgia
<alyssa>
macc24: I agree Mesa 19.2 is nostalgic for me
<alyssa>
and that is the version I would build 😉
<macc24>
mmm mmm broken panfrost
<macc24>
why the fuck krane sku176 dts has spaces instead of tabs
<icecream95>
Hmm.. I have two dEQP failures. Do I look at the one related to the code I'm touching, or the one that's testing completely unrelated functionality?
<alyssa>
If you're touching uniforms everything is implicated
<alyssa>
Note to self: page 103 of valhall docs is missing secondary opcode, it's in the xml though