alyssa 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
jernej has joined #panfrost
jernej has quit []
jernej has joined #panfrost
jernej has quit []
jernej has joined #panfrost
atler is now known as Guest4698
atler has joined #panfrost
Guest4698 has quit [Ping timeout: 480 seconds]
_whitelogger has joined #panfrost
<cyrozap>
Dylanger[m]: GPU reverse engineering projects figure things out by giving the compiler some code, then looking at the output, then changing the code a little and looking at that output, and repeating that process a bunch. They also use the "flip bits in instructions" technique to find new instructions that haven't been emitted by the compiler, and they watch the ioctl calls the driver makes to the
<cyrozap>
kernel to figure out how job submission works. That way, there's no need to violate any EULAs by disassembling driver code. Black box reverse engineering is generally legal, since what lawyers (and judges) generally consider "reverse engineering" to be limited to picking apart the code to see how it works, and "providing inputs and observing outputs" is generally not considered RE (even though of course
<cyrozap>
we would call it RE).
<cyrozap>
(alyssa feel free to correct me on any of these points)
<cyrozap>
Dylanger[m]: Also, another clarification: The panfrost project started out with zero documentation--it had to be figured out from scratch using those techniques I mentioned.
<cyrozap>
Supposedly ARM is now providing Collabora with docs, but nobody has seen them publicly. Presumably they're under NDA, but to my knowledge no one from Collabora has spoken about any of the details of the NDAs (maybe the NDAs are under NDA?).
<macc24>
i really need to point my bouncer at oftc too...
<daniels>
(also, cryozap is right to say that the information Collabora has about Mali GPUs isn't directly redistributable given NDA, but our interpretations are, e.g. the ISA & descriptor XML we wrote to match the actual hardware rather than guesswork, and also the bits written with very long commentary ...)
<macc24>
daniels: would translation be considered "direct"?
<macc24>
like documentation put through english -> german translator
<daniels>
yep
<daniels>
generally, it's the same principle as clean-room reverse-engineering
<daniels>
just copying & pasting, whether it be through Google Translate or rot13, or whatever, is in violation of most NDAs (I'm not just talking about Arm here, but non-public vendor-provided specs more generally)
<macc24>
reverse engineering documentation?
<daniels>
for some literal lists of facts, then there is no way around encoding them directly, e.g. the descriptor/ISA XML is a pretty literal transformation of what's available
<macc24>
hmmmmmm
<daniels>
for textual documentation, the clean-room rule applies: read all the documentation and understand it, then provide _your own_ commentary based on your understanding of it, but don't just dump several paragraphs verbatim from the docs
<HdkR>
daniels: Is that a good heeeehh? :P
<daniels>
HdkR: depends if you count me being amused as 'good' :P
<HdkR>
🤌
<HdkR>
Seems like a good result
<macc24>
has anyone used filesystem compression on panfrost devices?
<icecream95>
macc24: Yes, and it's why my dmesg is filled with
<icecream95>
F2FS-fs (mmcblk0p2): sanity_check_inode: inode (ino=24b3c) extent info [3163730, 0, 2] is incorrect, run fsck to fix
<icecream95>
F2FS-fs (mmcblk0p2): Inconsistent error blkaddr:3163727, sit bitmap:0
<icecream95>
etc.
<macc24>
icecream95: ok... is it around as fast as with no compression?
<macc24>
if you are using internal emmc
<icecream95>
I haven't done any tests of speed, and only have compression enabled for file types that tend to be small anyway
* macc24
noted
_whitelogger has joined #panfrost
<macc24>
does panfrost work on android with mesa?
dante6913 has joined #panfrost
dante6913 has quit []
Danct12 has joined #panfrost
fahien has joined #panfrost
<fahien>
Hello
<macc24>
hello fahien?
<daniels>
macc24: yes*
<daniels>
*: gralloc/hwc might need work for your platform
<macc24>
when i get android running on a chromebook i will achieve full circle of os porting
<alyssa>
cphealy: ^
<alyssa>
macc24: I am not so eagerly awaiting the day someone starts doing Android for M1 builds
<macc24>
alyssa: get me a m1 machine and i will get android running on it when asahi linux has close to full support for hardware
* alyssa
feeling a bit stuck and not sure why
* macc24
is resisting very hard to not make a joke here
* alyssa
confused puppy dog
<urja>
yeah i'm also doing neck stretches here like "uhh? where's it?"
<macc24>
._.
macc24 has quit [Ping timeout: 480 seconds]
macc24 has joined #panfrost
<alyssa>
hey, does anyone here have a kevin running ChromeOS?
<alyssa>
macc24: maybe?
Matt_B has quit [Remote host closed the connection]
jernej has quit [Remote host closed the connection]
<alyssa>
macc24: unrelated, !10961 will probably benefit from some game playing, er, testing
pendingchaos has quit [Read error: No route to host]
pendingchaos has joined #panfrost
jernej has joined #panfrost
<icecream95>
Can I be bothered making unaligned UBO loads get pushed where possible on Midgard, or will I just hack nir_intrinsic_get_ssbo_size to use an aligned load?
<macc24>
alyssa: i can have kevin running chromeos tomorrow
<macc24>
and sure ill test !10961
<macc24>
tomorrow
<macc24>
oh fuck out of order scheduling on bifrost
<macc24>
LETS GOOOOOOOOOO
<alyssa>
macc24: results are underwhelming tbh
<macc24>
._.
<macc24>
performance plz
<alyssa>
how though
<HdkR>
Just overclock it ;)
<alyssa>
thanks
<macc24>
i actually thought a bit about overclocking