<remexre>
if I wanted to write a bare-metal program for an soc with a mali t-864, is there a link dump of docs I should read on getting the GPU up and running?
<remexre>
mostly just need a framebuffer and blitting, definitely not reimplementing mesa or anything
WoC has joined #panfrost
<HdkR>
and now you get to implement a full job chain as well :P
<macc24>
remexre: 3d cores don't matter in this case
<macc24>
mali t860mp4 doesn't do display
<macc24>
you may be able to use framebuffer that was already there, set up by boot firmware
<remexre>
okay, I'll give the soc docs a harder look; when it boots Linux, the display doesn't get turned on until fairly late in boot, so I was assuming there was some hard GPU init to be done
<macc24>
are you trying to write os for a chromebook?
<remexre>
HdkR: job chain? is this "just" vulkan barriers?
<remexre>
something like that, for a pinebook
<remexre>
much much much less than a "real" os
<macc24>
oh you can probably ommit framebuffer init
<macc24>
and use fb that u-boot left
<remexre>
basically just an allocator, dynamic loader, and some message-passing primitives
<macc24>
linux calls this simple-framebuffer
<remexre>
hm, okay, I'll look into that; would the screen not being on be a matter of a separate device for controlling the actual display that needs to be inited?
<macc24>
no idea, i only do chromebooks
<HdkR>
ah yes, just getting a display up means tinkering with display controller, not GPU
<remexre>
hm, any chance you know what bus that'd be on?
<macc24>
>bus
<HdkR>
AXI probably :D
<remexre>
so it's labelled something weird in the TRM then :P lovely
<remexre>
there is a block in the memory layout diagram for eDP, but no section about it (in my copy)
<remexre>
time to dig through the devicetree ig
<remexre>
oh huh, it's rockchip-specific; well, found it anyway
<remexre>
thanks all
<urjaman>
Just initializing the display controller is not exactly a one-liner either, and also a thing with lots of possible complications (tho, for the rockchip things it does fit into u-boot just fine)
<remexre>
yeah, I've got a forth repl running over the serial port, so I can at least prod it interactively
<urjaman>
you need the clock subsystem to be ready to give you the appropriate display clock, you need to know the mode you want to put the display in, etc
<HdkR>
Display controllers in mobile space are fun. Every SoC vendor has their own thing :P
<macc24>
i wish display was unified in arm
<macc24>
but if it was, i would have one laptop less lol
<HdkR>
I don't see ARM breaking legs to get people to use their display IP
<urjaman>
btw: mousepad doesnt like it if you use xdotool to close its window as soon as it appears ...
cphealy has joined #panfrost
<remexre>
maybe nvidia will be more willing to break legs, heh
<urjaman>
nvidia does both themselves...
<urjaman>
(in their existing hardware that is ... afaik atleast)
<HdkR>
I completely expect Nvidia to kill the ARM display IP and just use the Tegra one
<remexre>
^^ is what I meant
<macc24>
at least risc-v is slowly taking off
<HdkR>
Who needs AFBC support in the DC when you have *Tegra Block Linear*? :P
leah has quit [Quit: WeeChat 2.8]
<macc24>
there was a tegra chromebook
<HdkR>
It's true, there was one
<macc24>
i wonder if it's got faster gpu than rk3399 or mt8183
<kinkinkijkin>
i had someone on discord that cpu architecture makes no actual difference to perf in any way and everyone should be using AMD64 because one study found that pure aarch64 is similar in size to codeswitched x86_64 recently
<macc24>
oh god
<macc24>
i bet they use pentium 4
<HdkR>
Quick number checking seems to show that Tegra K1 GPU would be up to 4x more powerful
<macc24>
on 4ghz with barely any IPC xD
<HdkR>
than rk3399 or mt8183 GPUs :P
<macc24>
:O
<HdkR>
Although Kepler, so probably wouldn't be able to stretch quite that far due to no tiling
<alyssa>
HdkR: what about M1 gpu? :P
<HdkR>
M1 GPU would stomp K1 in to the ground
* macc24
throws out his duet and gets acer 13 311
<alyssa>
also, technically mali can do block linear too
<alyssa>
but why on earth would you :p
<macc24>
speedy gpu time
<alyssa>
(midgard anyway can, IIRC bifrost dropped it because nobody would ever use it)
<HdkR>
alyssa: I believe the only integrated GPU that the M1 doesn't quite beat could be Xavier, but that is automotive market, and M1 should only loose by a small amount :P
<alyssa>
👿
<alyssa>
wonder how new qcm stuff will fare
<macc24>
HdkR: but, does m1 run linux?
<HdkR>
Only in a VM atm
<macc24>
that's cheating
<HdkR>
alyssa: 8cx/8cx2/888 will all lose to M1 :P
<macc24>
HdkR: but they run linux. therefore they win. slow soc is better than soc running something that's not linux :P
<HdkR>
aaahhh....They kind of don't run real linux atm
<macc24>
hold my beer
<alyssa>
macc24: there's an effort to get real linux on M1
<macc24>
alyssa: yeah i know,
<HdkR>
Upstream DT support on these devices are still a nightmare
<HdkR>
(and 888 isn't even out yet)
<macc24>
new qcom and mtk devices will be my next target if my patreon ever takes off
<HdkR>
I'll immediately buy an M1X class laptop once it supports Linux. :P
<macc24>
define "M1X class
<alyssa>
HdkR: what if there's no working 3D
<macc24>
alyssa: software acceleration is faster than G31 ;D
<alyssa>
Shhh
<HdkR>
hmmm, depends on how fast llvmpipe is at running alacritty on it :P
<macc24>
HdkR: real performance killer will be compositor
<HdkR>
Who runs a compositor?
<HdkR>
i3 lyfe
<macc24>
try switching to sway
<macc24>
touch support in wayland is so much better
<HdkR>
Not until it fixes whatever bugs I hit last year and I don't remember what they are :P
<macc24>
i run sway everywhere and it's 100% fine
<HdkR>
For your use case sure
<HdkR>
I also disable touch screen on this laptop, don't need it :)
<macc24>
why would you do that
<HdkR>
I'm an old fogey that doesn't want it
<macc24>
okay
<kinkinkijkin>
when m1 runs linux i will bow to the greedy kings of the lands of apple
<kinkinkijkin>
and then they'll make it no longer run linux
<kinkinkijkin>
and ill retract my bow
<macc24>
noooo my userbase is melting
<kinkinkijkin>
macc24 dont worry im not gonna sell the duet or anything any time soon :p
<kinkinkijkin>
im too poor to buy... uh...
<kinkinkijkin>
anything i dont already own
<macc24>
kinkinkijkin: i think now i'm done with breaking backwards compatibility
<macc24>
in cadmium
<macc24>
haha me too
<kinkinkijkin>
oh cool that'll be nice when i have the ability to reflash
<macc24>
featuring unbrickability that hopefully works, shady firmware changes and sway config that doesn't suck
<kinkinkijkin>
did i not show you how i have this looking right now?
<chewitt>
noticing all of them are tagged as fixes .. are they queued somewhere?
vstehle has joined #panfrost
kaspter has quit [Remote host closed the connection]
kaspter has joined #panfrost
austriancoder has quit [Ping timeout: 264 seconds]
austriancoder has joined #panfrost
nlhowell has joined #panfrost
icecream95 has quit [Ping timeout: 260 seconds]
warpme_ has joined #panfrost
camus has joined #panfrost
kaspter has quit [Read error: Connection reset by peer]
camus is now known as kaspter
camus has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
camus is now known as kaspter
nlhowell has quit [Ping timeout: 240 seconds]
listen_ers has joined #panfrost
camus has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
camus is now known as kaspter
maciejjo has quit [Remote host closed the connection]
mixfix41 has quit [Quit: Lost terminal]
raster has joined #panfrost
listen_ers is now known as mixfix41
<alyssa>
alright
thecycoone has joined #panfrost
mixfix41 has quit [Remote host closed the connection]
kaspter has quit [Quit: kaspter]
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
mixfix41 has joined #panfrost
mixfix41 has left #panfrost [#panfrost]
kaspter has joined #panfrost
<macc24>
can anyone test if cursor is getting corrupted on mesa master + sway 1.5 + firefox 84.0 and kernel 5.10 on kevin?
<macc24>
or other rk3399 board
<macc24>
solidhal?
archetech has joined #panfrost
yann has joined #panfrost
yann has quit [Ping timeout: 256 seconds]
<macc24>
AreaScout_: hey
<AreaScout_>
I am a logbot, you can leave messages and AreaScout will get back to you asap :)
<macc24>
pm me please
yann has joined #panfrost
yann has quit [Ping timeout: 272 seconds]
raster has quit [Quit: Gettin' stinky!]
nlhowell has joined #panfrost
kaspter has quit [Ping timeout: 264 seconds]
unoccupied has joined #panfrost
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
unoccupied is now known as leah
nlhowell has quit [Ping timeout: 272 seconds]
nlhowell has joined #panfrost
nlhowell has quit [Ping timeout: 260 seconds]
raster has joined #panfrost
yann has joined #panfrost
yann has quit [Ping timeout: 260 seconds]
tomboy64 has quit [Write error: Broken pipe]
tomboy64 has joined #panfrost
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
Green has joined #panfrost
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
davidlt has quit [Ping timeout: 272 seconds]
nlhowell has joined #panfrost
Prf_Jakob has quit [Ping timeout: 268 seconds]
Prf_Jakob has joined #panfrost
yann has joined #panfrost
icecream95 has joined #panfrost
<icecream95>
macc24: I've seen cursor corruption sometimes on rk3288, and also on duet once or twice
yann has quit [Ping timeout: 260 seconds]
<icecream95>
alyssa: ISA.xml seems to be missing a number of 64-bit instructions
<alyssa>
icecream95: yeah//
<alyssa>
v6 (G71 and G72) supports "64-bit clauses", for doing extremely limited int64 arithmetic at half-speed, in a special clause
<alyssa>
with extremely complex scheduling requirements ( cwabbott r/e'd some of this if you want an idea)
<alyssa>
v7 (every other bifrost chip) drops support for 64-bit clauses because it's horrible (in hardware, in software, and ... mostly useless)
nlhowell has quit [Ping timeout: 260 seconds]
<alyssa>
G72's 64-bit clauses support 64-bit bitwise operations, mov.i64, integer multiply, count less zero, conversions to/from 32-bit integers, integer add/sub/etc, integer abs, and comparisons
<alyssa>
That seems like a lot, but it's really not
<alyssa>
Except some details of shifting, 1 64-bit bitwise op = 2 32-bit ops
<alyssa>
likewise for mov
<alyssa>
zero-extension is completely trivial (just mov #0 the top)
<alyssa>
sign-extension is also trivial (MUX.i32 on the top, with the bottom as the source, ~0 and 0 as the options to mux between, and .neg mode)
<alyssa>
integer add, and integer shifts, are supported with the address calculation instructions (SHADDXL and friends)
<alyssa>
Bottom line is the only thing 64-bit clauses can do in 2 cycles (1 instruction) that can't be done efficiently in 32-bit is 64-bit multiplies
<alyssa>
v7 solves this by adding IMULD/IMOV_HI for accelerating that pattern
<alyssa>
I don't expect anyone to be benchmarking panfrost on g72 for 64-bit integer multiplication performance so... it seemed like a tiny feature to drop in exchange for *dramatic* simplification in *every* part of the compiler and disassembler
<alyssa>
(Oh, I guess shifting is somewhat nontrivial, since SHADDXL only does small immediate shifts)
<alyssa>
I hope that answers that.
<macc24>
icecream95: i have never noticed something like that on duet
<macc24>
anyway, i updated mesa to latest git revision and it seems to have helped on kevin
<alyssa>
icecream95: As for FPK bits, working on it™, would respond sooner but I don't understand them myself yet.
<icecream95>
"clause_366:" I guess lowering 64-bit multiplies works, but it is not anything approximating fast
<alyssa>
that seems... big
<alyssa>
(in nir_lower_int64, imul64 gets lowered to 5 instructions, all of which have native versions on v7... but umul_2x32_64 is one, and that corresponds to IMULD which is new to v7 since v6 would use a 64-bit clause for it... ugh)
<alyssa>
if it makes you feel better, look at what fp64 multiplication gets lowered to 😇
* icecream95
sets PIPE_CAP_DOUBLES
<alyssa>
mesa/src/compiler/glsl/float64.glsl
<chrisf>
alyssa: in <gl4 land, is there anything you actually care about 64 bits for?
<alyssa>
chrisf: nope
<chrisf>
~ anything the compiler unfortunately generates internally
<alyssa>
icecream95: has been poking at cl
<chrisf>
simultaneously, neat & ugh
yann has joined #panfrost
<icecream95>
fp64 lowering isn't too bad: ssa_37855
<alyssa>
T___T
<alyssa>
that sounds right
<alyssa>
now you know why the bifrost opencl blob doesn't support fp64 =)
<alyssa>
can't benchmark what doesn't work!! :p
yann has quit [Ping timeout: 264 seconds]
* alyssa
has been making progress on scheduling
<chrisf>
doubles are optional, if gross don't expose?