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
robmur01_ has joined #panfrost
robmur01 has quit [Ping timeout: 480 seconds]
ezequielg has joined #panfrost
karolherbst has quit [Quit: Konversation terminated!]
atler_ has joined #panfrost
karolherbst has joined #panfrost
Xalius has quit [Quit: Leaving]
atler has quit [Ping timeout: 480 seconds]
karolherbst_ has joined #panfrost
karolherbst has quit [Ping timeout: 480 seconds]
karolherbst_ has quit []
karolherbst has joined #panfrost
<cphealy>
Does Panfrost support GL_OES_get_program_binary?
* robmur01
gives up trying to fight with OFTC's nickserv...
<HdkR>
Did it win?
<macc24>
alyssa: i will test !10961 later today when i try to get filesystem compression to work better and ultimately fail
Xalius has joined #panfrost
<HdkR>
Need that PanVK driver so we can run big games :>
<macc24>
need fex to run on armv8.0 hardware so we can use panvk to run big games :>
ckeepax has quit []
<HdkR>
I'm sure there's some Cortex-A55 board somewhere with Mali right? :)
<macc24>
pleaaaaaase
<Xalius>
there are some boards with A55, like Pine64 QuartzA/B and Firefly
<macc24>
isn't rk3566 and rk3588 valhall?
<HdkR>
3566 isn't
<macc24>
oh
<Xalius>
3566 is G62/Bifrost
<Xalius>
*G52
<Xalius>
RK3588 is something else, but not sure if it was confirmed yet
ckeepax has joined #panfrost
<robmur01>
IIRC, Amlogic S905X3 (or X4?) is A55 + G31
<robmur01>
although I'd expect both that and RK356x to probably struggle with anything more than little games ;)
<HdkR>
hehe
<macc24>
*laughs in sc7180*
<HdkR>
Adreno is in really good shape. I've only encountered one visual bug...Which I should repro in a renderdoc capture
<macc24>
yea it's in good shape
<macc24>
except people with epilepsy shouldn'e be allowed to use firefox on adreno 618
chewitt_ has joined #panfrost
chewitt has quit [Ping timeout: 480 seconds]
robmur01 has quit [Remote host closed the connection]
robmur01 has joined #panfrost
shadeslayer has joined #panfrost
<daniels>
robmur01: thanks for the clarification :)
<daniels>
and yeah, there are patches on the list + in MRs to support the homeopathic G52 in RK3566
<daniels>
but I wouldn't want to be doing much more than simple-egl on it
<macc24>
daniels: "homeopathic G52"?
<urja>
yeah that sounds like "the wafers were stored next to some GPU wafers" :P
<macc24>
uhh
<macc24>
daniels please elaborate on the homeopatic G52
<daniels>
G52 goes up to 6 cores, and each of those 6 cores has 3 'execution engines' i.e. quads
<daniels>
the G52 in the RK3566 is the only one yet seen to have 2 EEs instead of 3, and it also only has a single core
<macc24>
daniels: so g52 in rk3566 is slowest g52 on the market?
* macc24
is waiting for G31 MP1 1EE at 1mhz
<daniels>
yep
<macc24>
looooooooooooooooooooooool
<cyrozap>
G11 MP1 0.5EE at 32 kHz
<cyrozap>
- Runs off the RTC clock for super low power
<cyrozap>
- Half an EE, so it only does half the work (for more power savings)
<macc24>
feature list:
<macc24>
- triangles
<robmur01>
daniels: actually it's more fun than that - 3EE can only goes up to 3 cores (because above that is G76), but 2EE goes up to 6
<daniels>
robmur01: oh yeah, that's right
<macc24>
lul
<robmur01>
At least RK356x chose 128K cache rather than 64K, so it's not the absolute lowest-possible spec
<daniels>
ah yes, for all those many memory accesses you'll have in flight simultaneously ...
<cyrozap>
macc24: Can't wait for the G01 MP0 0.1EE at 1 Hz--feature list: - pixel (just one)
<macc24>
robmur01: uhh, do you happen to know how to put on screen as many pixels as possible per second on rk3399?
<robmur01>
to be fair, all my Bifrosts are MP1 at 40MHz with ~250MB/s memory bandwidth. FPGA FTW! :D
<robmur01>
macc24: dunno, but for one thing I'd suspect that outside the BSP stack, nobody's tuning the memory and interconnect clocks/QoS/etc.
<robmur01>
on RK3328 you can visibly interrupt display scanout by running a memory benchmark...
<macc24>
i need to push *plucks numbers into calculator* 230400000 pixels per second
<macc24>
may or may not be ke
<macc24>
kevin*
<macc24>
robmur01: ill try that
<robmur01>
maximum memory bandwidth on my RK3399 seems to be around 7.8GB/s (at the CPUs), so you're already nudging 25% of that (assuming you're writing those pixels as well as scanning them out)
<macc24>
robmur01: like, rendering user interface at 60 frames per second can't be that hard on kevin
<macc24>
i get the "famous last words" vibe from my last message, not sure why
<robmur01>
tabs not spaces, and I'd squash the first two (unless there's some weird uapi policy I'm not aware of)
<alyssa>
-----tabs?
<alyssa>
that's it back to mesa
<alyssa>
:p
<macc24>
alyssa: why would you be using spaces instead of tabs?
<alyssa>
idk
<macc24>
tabs are easier to go through, consume less space and are variable length
<alyssa>
Tabs are harder
<urja>
mmmm
<macc24>
how tabs are harder
<robmur01>
to be fair there are hard tabs and soft tabs /runs
<HdkR>
FEX uses spaces :)
<alyssa>
robmur01: hard tabs linux is?
<macc24>
HdkR: if i ever make fork of fex i will run s/ /^T/g on it ;)
<robmur01>
sorry, it's Friday++ for me so you get '90s word processing jokes
<alyssa>
hnnnnngh
<HdkR>
macc24: Hope you don't like upstreaming then
<macc24>
HdkR: i'm the new upstream
<macc24>
:p
<alyssa>
it seems to be tabs? confused
<macc24>
upstream is relative
<alyssa>
oic
<robmur01>
only the alignment in the first two patches - the indentation elsewhere is fine
<alyssa>
ack
<alyssa>
updated, thanks
<alyssa>
i'm only mostly sure the atomics use is wrong
<alyssa>
checkpatch is happy :p
<robmur01>
the other nitpick beyond whitespace is some commit messages are a little sparse - general kernel style is that the body should be self-contained, rather than be read as a continuation of the subject (for the long story see submitting-patches.txt)
<alyssa>
Uhhh ok
<robmur01>
I'd probably use atomic_fetch_inc() > 0 and atomic_dec_return() > 0 (or just !) for pleasing symmetry, but either way it doesn't look particularly wrong
<robmur01>
consider using refcount_t if you're literally reference-counting a thing and want some free robustness if it goes wonky
<alyssa>
refcount_t uhh ok
<robmur01>
"args_requirements &&" looks redundant (since the 2nd condition is no longer !=)
<robmur01>
s/_/->/, bleh
<robmur01>
IRC patch review proves to be surprisingly fun, but unsurprisingly vague
<alyssa>
IRC patch review seems more efficient than email ;P
<robmur01>
certainly for the small stuff. There's perhaps a debate about the exact naming of things, but that's one for review proper on the lists
<alyssa>
yeah, for sure
<alyssa>
PERMON is the kbase name but I kinda agree it's silly
<alyssa>
and easy to get confused with perf cnts
<alyssa>
PANFROST_JD_CYCLE_COUNT is the most natural since that mirrors the hw reg
<alyssa>
but it's also a misnomer (in the hw) since it's also for timestamps
<robmur01>
tricky indeed...
* alyssa
boots machine
<alyssa>
*no output*
<alyssa>
sigh
<alyssa>
how did I get this working the first time?
<alyssa>
this is why I delay kernel upgrades if it's ont in debian
<robmur01>
if you're hacking on a driver that's a removable module, a neat trick is to run a distro kernel that's "close enough" to your development base, then build just that one module against the system headers and insmod the .ko manually
<robmur01>
iterate until you make the next stupid bug and have to wait 10 minutes for a crashed AWS instance to force-reboot...