tgall_foo has quit [Read error: Connection reset by peer]
tgall_foo has joined #panfrost
chewitt has quit [Quit: Zzz..]
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #panfrost
kaspter has quit [Ping timeout: 264 seconds]
kaspter has joined #panfrost
chewitt has joined #panfrost
karolherbst has joined #panfrost
karolherbst has quit [Remote host closed the connection]
davidlt has joined #panfrost
<bbrezillon>
kinkinkijkin: do you have a backtrace?
<kinkinkijkin>
there was no crash
<kinkinkijkin>
so i didn't think to get one
<kinkinkijkin>
just anything that was rendered by any method but bitmap textures actually being rendered right being rare
<kinkinkijkin>
text didn't show up, firefox was all black with a white scrollbar on the side, background in sway way just 7f7f7f
<bbrezillon>
crap
<kinkinkijkin>
but anything rendered by qt showed up, and i managed to load supertuxkart and i could occasionally see a full frame
<kinkinkijkin>
let's see... i tried minitube, minitube was fully rendered until i tried loading a video
<kinkinkijkin>
as soon as the video went to play the whole application went black
karolherbst has joined #panfrost
<q4a>
kinkinkijkin are you using supertuxkart from snap?
camus has joined #panfrost
kaspter has quit [Ping timeout: 264 seconds]
camus is now known as kaspter
<bbrezillon>
kinkinkijkin: reproduced with weston, I'm on it
camus has joined #panfrost
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
tomboy64 has quit [Remote host closed the connection]
tomboy64 has joined #panfrost
stikonas has joined #panfrost
urjaman has quit [Read error: Connection reset by peer]
urjaman has joined #panfrost
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
phh has quit [Ping timeout: 265 seconds]
pmjdebruijn has joined #panfrost
<pmjdebruijn>
is there any general status overview of panfrost in linux-5.10 ?
<pmjdebruijn>
particularly with regard to the G31 and G52 GPUs (on OdroidC4/OdroidN2+ respectively)
<pmjdebruijn>
I read that with 5.10 the G52 should work on the N2+, however I can't find good sources as to what really "Works"
<HdkR>
looks like we need to get bifrost on to MesaMatrix
<HdkR>
Also maybe a features wiki that inevitably goes out of date
phh has joined #panfrost
<pmjdebruijn>
HdkR: mesamatrix is fairly hard to parse for lots of people
<Ke>
obviously public rest api for the data and someone else^^TM creates the frontend
<Ke>
when I say rest api, I mean static json file on a server
<Ke>
minified, not pretty-printed
<HdkR>
pmjdebruijn: It misses a lot of information yes. Which is why the Nouveau table can be nice. Will /immediately/ become outdated though
<HdkR>
Bifrost is currently in ES 2.0 GL 2.1 land though
<pmjdebruijn>
but it works well at that level?
<pmjdebruijn>
as in applications that have been verified to work
<HdkR>
"well" very much depends on your use case :)
<pmjdebruijn>
for one SDL2 as a 2D render surface through GLES
<HdkR>
Likely to work fine
<pmjdebruijn>
I just tried that with lima on an older board, and it works, but something feels off, feels laggy and maybe vsync isn't properly working?
<pmjdebruijn>
HdkR: on either the G31/G52 given the generational difference
<HdkR>
uh, one of them is in better shape but I forget which. :D
<pmjdebruijn>
I'd suspect the G31, as I saw that referenced in a fairly early status update, presumably by alyssa
<HdkR>
I believe the N2 had some kernel power quirks, but might be worked out at this point?
<pmjdebruijn>
ah, which would suggest there is unlikely to be significant difference between the g31/g52 wrt application support etc
<raster>
macc24_: mali gpu naming is... fun. even more fun dealing with the internal names (all some norse thing) and then trying to remember which of those map to which generation/version etc.
<raster>
:)
<macc24_>
raster: i've seen worse
<macc24_>
but WHY there are at least 2 different names with no connection for one gpu?
<raster>
like?
<macc24_>
g72 - bifrost v6
<macc24_>
and that v6 doesn't refer to bifrost but to whole mali
<raster>
well bifrost is like an architecture generation
<raster>
hmm like arm vs x86 i guess
<raster>
so midgard vs bifrost are essentialyl different instruction sets
<raster>
arm vs aarch64
<macc24_>
why g31 was named g31 if it is different version of bifrost architecture than g71?
<raster>
yeah - v3,4,5,6,7 etc. are just "we did another version people!"
<raster>
within a generation there may be minor changes
<raster>
like eg intel added mmx ... or avx512
<raster>
or just a few extra instructions
<raster>
etc.
<raster>
engineering decide codenames and such
<raster>
marketing decide G31, G72 etc.
<raster>
and the marketing decisions can happen like the day before the release...
<macc24_>
okay
<macc24_>
if marketing decided naming then it's understandable that it's confusing
<raster>
hehehe
<raster>
the usual engineering punt "blame marketing" :)
<raster>
but it's true
<raster>
why they decide what they decide... i have no idea
<macc24_>
maybe they thought "it's first little gpu.... so it should be G31"
<pmjdebruijn>
would it be great if everything was [MAJOR_GEN][MINOR_GEN][PERFORMANCE_TIER] :D
* pmjdebruijn
dreams on
<warpme_>
guys: wonder your opinion: i tying to finetune 4k hevc playback. mesa is 20.3.2. on t860 (rk3399) i have perfectly fluent/smooth playback. on t820 (s912) (and also on g31 on sm1) playback is jerky (see upper left corner with scrolling text at http://warped.inet2.org/hevc.mov ). In all cases cpu load at playback is below 5% so - if there is performance bottleneck - it is in GPU i think. Player uses drm_prime rendering
<warpme_>
in EGL mode via EGL_LINUX_DMA_BUF_EXT in mesa. In all cases sw.stack (kernel/mesa/ffmpeg/player) are exactly the same, and only change is GPU type. For HD content all gpu types are playing smooth so it looks like issue is manifesting on highest resolution only (4k). Is it possible that t820 differs so much compared to t860 that t860 plays 4k really smooth while t820 is simply too weak? What about g31? (g31 also has
<warpme_>
jerky playback). Are there any other tests i can do to find where is bottleneck causing jerky 4k playback on other than t860 GPUs?
<raster>
wouldn;'t it ever be nice... :)
<raster>
(maj.min.perf) :)
phh has quit [Ping timeout: 260 seconds]
<macc24_>
warpme_: are you using hardware video decoder on rk3399?
phh has joined #panfrost
<warpme_>
of course. uhd 4k with below 5% cpu can't be possible without hw. decoder
<macc24_>
are youi using hardware video decoder on s912?
<warpme_>
yes.
<macc24_>
hmm
<warpme_>
all plays perfectly with hd. jerkiness appears only for 4k. as on 4k cpu is still <5% i suspect bottleneck is gpu which can't cope with handling 4x bigger amount of data. but it can on t860 - which works really well (i would say even perfect)
<macc24_>
well i never did anything hwdec on arm ¯\_(ツ)_/¯
<raster>
warpme_: it isn't just gpu .. it's the whole memory subsystem that is going to have a major effect
<raster>
a fast cpu is going to be hamstrung if memory bottlenecks it ...
<macc24_>
raster: how much valhall differs from bifrost? is it entirely new isa too?
<raster>
yes. new isa.
<raster>
so current bifrost mesa effort will not stretch to valhall gpu's - that'll need a new compiler :)
<tomeu>
warpme_: but the s912 has a t820, right?
<tomeu>
that one is much slower than the t860
<warpme_>
raster: well - it is possible. But isn't that this will be issue mainly of numa architectures (in sense of separated video memory & program memory hierarchies). In such case dma assisted data movements needs to provide enough BW. But on uma systems there is zero-copy so mem. bw . limitation is probably far higher compared to required mem BW. In this context: is t820 & t860 uma or numa? Another possible factor is BW
<warpme_>
limited by mem type/timmings/bus.width (you know ddr3l with high cas vs. faster ddr3 with lower cas; 32bit vs 64bit bus). my t860 is rockpi4 SBC while t820 is beelink GT1 tvbox. I looking on advise how to narrow bottleneck....
<warpme_>
tomeu: yes s912 is t820. that's why i also check g31 and g31 also has jerkiness (lower but noticeable)
<tomeu>
don't know how it compares to the t860, but the g31 is low poer
<tomeu>
warpme_: can you measure cpu, external memory controller and gpu utilization?
<raster>
warpme_: there is only zero copy if you dont use the gpu....
<raster>
ie u literally decode to the buffer and directly present that buffer to the dpu with kms...
kaspter has quit [Ping timeout: 240 seconds]
<warpme_>
well - this will be good to see, how i can do that for mem.ctrl and gpu util.?
kaspter has joined #panfrost
<raster>
if you are doing what you seem to be (using gl/mesa to draw the video buffer as a texture to a backbuffer)
<raster>
then the gpu will necessarily have to read at least the entire video buffer in at some point and write it out ... in a larger form (ARGB so 4 bytes per pixel where the input is probably about 2 bytes per pixel in yuv)
<warpme_>
raster: you are describing drm_prime on drm_planes mode. I'm on EGL with EGL_LINUX_DMA_BUF_EXT so i'm on drm_prime in egl mode....
<raster>
so the bandwidth for that alone comes in at about 1.4GB/s
<warpme_>
raster: "then the gpu will necessarily have to read at least the entire video buffer in at some point and write it out ... in a larger form (ARGB so 4 bytes per pixel where the input is probably about 2 bytes per pixel in yuv)" - exactly
megi has quit [Quit: WeeChat 3.0]
megi has joined #panfrost
<warpme_>
input from decoder is nv12 iirc
<raster>
but you are drawing the video as a texture... right?\
<tomeu>
apparently, the Allwinner H616 has a G31 and is intended for TV boxes that are capable of 4k
<tomeu>
the g31 in the h616 might be connected to the external memory bus in a way that makes it feasible for the GPU to sample 4k textures during video playback?
<tomeu>
why is the GPU involved at all, btw?
<tomeu>
can't the display directly consume the buffers that come out of the hw decoder?
<warpme_>
raster: yes. my hypothesis is exactly like yours: 1.most probable hypothesis: t820 gpu can't computationally cope with pixel format conversion. this is computationally bound type of limitation; 2.highly probable hypothesis: mem bw is not enough for pix.conversion data movements. this is mem bw. bound type of limitation.
<tomeu>
also, regarding bw, AFBC might be relevant here
<warpme_>
raster: "but you are drawing the video as a texture... right?\" - yes
<raster>
warpme_: #1 is unlikely. it's mem bw...
<warpme_>
tomeu: "why is the GPU involved at all, btw" - we do this for deinterlacing (provided by GL if user wants DI)
<raster>
also keep in mind - rockchips were renowned for having poor mem perf vs other SoCs with the same cpu cores
<raster>
so if what u ave is pure compute it'd be good -b ut once u needed to deal with mem... things went south
<warpme_>
raster: "rockchips were renowned for having poor mem perf" - indeed. My tests on 3328 giving even hd playback highly jerky. i'm quite sure because of low mem. bw.
<macc24_>
i could play 1080p animes on rk3288 just fine
<macc24_>
on my c100pa
<tomeu>
warpme_: you may be able to get mem ctrl utilization from the devfreq driver (if there's one)
<macc24_>
warpme_:
<warpme_>
macc24_: with what rendering mode?
<macc24_>
how did you get hwdec to work?
<macc24_>
warpme_: mpv --vo=gpu
<warpme_>
macc24_: what is yours 3328 board?
<warpme_>
tomeu: "you may be able to get mem ctrl utilization from the devfreq driver (if there's one)" - this is very interesting. may you pls advice me how to do this?
<tomeu>
warpme_: cannot see such a driver :/
<tomeu>
maybe in downstream?
<tomeu>
narmstrong: does the downstream kernel do memory controller clock scaling for the s912?
<tomeu>
warpme_: guess it could all be done in fw :/
<macc24_>
warpme_: asus c100pa
<macc24_>
i run mesa-git on it for performance and testing
<raster>
warpme_: yeah. my rk3399 definitely lags behind even my pi4 in membw
<macc24_>
warpme_: oh i said rk3328? i meant rk3288
<raster>
the only place the rk3399 seems to shine is in memset... where it is streets ahead of all the other results
<raster>
and well ahead of the pi4 (like almost 3x the speed)
<warpme_>
tomeu: i have multiple selection of gpu freq governor (powersave, performance, users ace, simple_ondemand). But this is for GPU and you are referring to mem.controler? If yes - then indeed - i never saw (in mainline kernel) memory devfreq....
<tomeu>
yep
<warpme_>
raster: "the only place the rk3399 seems to shine is in memset" - this may well explain why i have really good results with 3399 and basically only with this. 3328/905/912/sm1/h6 - all are good for hd - but not for 4k :-(. Sure - when i'll switch to drm_planes drm_prime 4k should look much better - but this is different story (as Qt will require kms platform driver for this...)
<warpme_>
guys: is there way to read gpu utilisation in panfrost (memory occupation & computational load)?
<kinkinkijkin>
bbrezillon you still want me to test that mr right?
<kinkinkijkin>
or is it merged
<bbrezillon>
kinkinkijkin: yes, please
<kinkinkijkin>
kk sec
<macc24_>
bbrezillon: fyi i can test whatever g72 changes
<kinkinkijkin>
bbrezillon: building now
<bbrezillon>
macc24_: feel free to test
<macc24_>
bbrezillon: kinkinkijkin tests this
stikonas has quit [Remote host closed the connection]
<kinkinkijkin>
k testing now brb
<kinkinkijkin>
not fixed
<kinkinkijkin>
since macc24 wasn't getting it, and I'm on an older release candidate kernel, you think it was fixed kernel side?
stikonas has joined #panfrost
<macc24_>
kinkinkijkin: try kernel from newest cadmium release on usb stick
<kinkinkijkin>
I don't have a usb stick anymore
<macc24_>
kexec?
<kinkinkijkin>
I've not used kexec before, I'll try it
<macc24_>
there's a script for that in cadmium
<kinkinkijkin>
test-kernel?
<macc24_>
load
<macc24_>
oh it kexecs from $CADMIUMROOT/tmp/kernel-$TARGET
<macc24_>
still, kexec command might be useful
<kinkinkijkin>
so just grab that latest kernel, then kexec into it right?
<macc24_>
yep
<macc24_>
and install modules from it
<bbrezillon>
kinkinkijkin: duh :-/
<bbrezillon>
are you sure you updated mesa? I had the full deqp-gles2 testsuite passing with this fix
<kinkinkijkin>
shush, i havent used kexec before
<kinkinkijkin>
i did update mesa
<bbrezillon>
kinkinkijkin: can you check your kernel logs?
<kinkinkijkin>
gonna test this first since i already have momentum and dont feel like recompiling mesa again yet
kaspter has quit [Quit: kaspter]
<alyssa>
bbrezillon: I wonder how we should model paired instructions in the IR
<bbrezillon>
you mean, those like CUBEMAP1/2?
<alyssa>
yeah
<alyssa>
options are basically
<alyssa>
1. generate both instructions separately, scheduler magically determines they need to be paired
<alyssa>
2. generate both instructions separately, explicit pairing field on bi_instr
zkrx has quit [Ping timeout: 240 seconds]
<alyssa>
3. generate only the last instruction and let the scheduler fill in the details
<alyssa>
4. generate a pseudo instruction and let the scheduler fill in the details
<alyssa>
5. some combination?
<alyssa>
There will have to be some special casing somewhere, just which is most tolerable
<bbrezillon>
I'd vote for #4, but you probably have a better idea of what's preferable
<alyssa>
*nod*
<alyssa>
#4 works well for things like CUBEFACE, IMULD, VN_ASST, and maybe atomics
<alyssa>
It's rather awkward for cases where the paired instruction acts like a modifier (DTSEL_IMM pairings, JUMP_EX, maybe SHIFT_DOUBLE too)
<bbrezillon>
alyssa: I just tried running the whole testsuite with the BO-cache hack, and we still have INVALID_ENC faults :-(
<alyssa>
bbrezillon: Oh come on!
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
tomboy64 has quit [Ping timeout: 240 seconds]
<alyssa>
But maybe a combination of #3 and #4 depending on which makes sense for that instruction
<alyssa>
(Pseudo CUBEFACE instruction, but regular resource access with a descriptor modifier that induces a DTSEL_IMM)
<macc24_>
alyssa: what's up with gl3 on bifrost?
tomboy64 has joined #panfrost
<alyssa>
macc24_: MRT pending
<alyssa>
bbrezillon: Main thing that's still super awkward is 64-bit shifts
<alyssa>
as especially funnel shifts but those don't seem to exist in OpenCL
<macc24_>
alyssa: super cool :D
rcf has quit [Quit: WeeChat 2.9]
thecycoone has quit [Ping timeout: 260 seconds]
thecycoone1 has joined #panfrost
rcf has joined #panfrost
rcf has quit [Quit: WeeChat 2.9]
rcf has joined #panfrost
<kinkinkijkin>
trying one more time to see if this patch build was just botched by myself
<kinkinkijkin>
i can't get kexec to work right
<kinkinkijkin>
just deadlocks in boot
<macc24_>
kinkinkijkin: so it's broken not only for me
<macc24_>
i have to investigate when usbc breakout arrives...
<kinkinkijkin>
wait you just had me kexec a seemingly unworking kernel
<kinkinkijkin>
to test something else
<macc24_>
no, kernel itself works
<macc24_>
kexec sometimes doesn't
<kinkinkijkin>
ah
<macc24_>
i don't trust myself enough to tell you to install it onto kernel partition on your machine
<macc24_>
(i.e. don't do it)
<kinkinkijkin>
fwiw i had to use vmlinuz instead vmlinux or Image, think the latter two are the literal same but still
<macc24_>
Image ≠ vmlinux
<kinkinkijkin>
testing this patch for real this time, brb, was definitely a botched patching
<macc24_>
vmlinuz is compressed vmlinux IIRC
<kinkinkijkin>
yep
<macc24_>
booting from Image.lzo coming Soon™
<kinkinkijkin>
thought vmlinux was Image and vmlinuz was zImage, but that might just be the x86brain talking
<kinkinkijkin>
vmlinuz was the only one kexec would load
<macc24_>
i kexec Image just fine
<kinkinkijkin>
i didn't have Image, cause i didn't compile it myself
<macc24_>
oh i didn't include it in release?
<kinkinkijkin>
no, not in the kernel tarball
<macc24_>
ok
zkrx has joined #panfrost
<kinkinkijkin>
bbrezillon: mr confirmed working, ready for marge
<kinkinkijkin>
i can test further if you like but the regression from before is gone
<bbrezillon>
kinkinkijkin: ok cool. Thx for testing!
<kinkinkijkin>
thx for writing it, i can now rest easy knowing that i have afbc and its benefits without terminal regression
<macc24_>
kinkinkijkin: done
<macc24_>
now Image is included in release tarball
<kinkinkijkin>
kk, ill test that soon
<macc24_>
there's not really a reason to test it
zkrx has quit [Quit: zkrx]
zkrx has joined #panfrost
chewitt has quit [Quit: Zzz..]
<macc24_>
i wonder how much of G31 potatoness is from slow memory
chewitt_ has joined #panfrost
chewitt_ has quit [Ping timeout: 256 seconds]
chewitt has joined #panfrost
<alyssa>
icecream95 (when here): FWIW, jumping to 0x0 (or a few other special addresses) ends the shader without faulting.
<alyssa>
So that might be a cleaner way to implement "jump to end", without needing a nop.
<chewitt>
I updated my XU4 image to include the 3.0 changes; kmscube now runs perfectly, no faults showing
<chewitt>
Kodi still faults shortly after the GUI starts
<macc24_>
chewitt: mali t628?
<chewitt>
indeed
<chewitt>
it be banished to the twilght zone, but..
<chewitt>
unfortunately I have no clue about debugging so creating kodi.bin with debug symbols and capturing something meaningful is a bit beyond me
<chewitt>
aka, I haven't worked up the enthusiasm to learn a new trick yet
<kinkinkijkin>
wait
<kinkinkijkin>
wait a sec
<kinkinkijkin>
you're running panfrost on xu4 without exactly half of everything rendering and the other half not?
<kinkinkijkin>
when was this fixed
dhewg has quit [Ping timeout: 256 seconds]
nlhowell has quit [Ping timeout: 256 seconds]
dhewg has joined #panfrost
<chewitt>
@kinkinkijkin i've never seen this half-half thing
<chewitt>
kmscube has run for a while, but previously was "a bit crashy"
<chewitt>
and Kodi just deadlocks the board
<chewitt>
kmscube is now running smoothly at 60fps
macc24_ has quit [Ping timeout: 246 seconds]
<kinkinkijkin>
have you run sway yet chewitt
<kinkinkijkin>
trust me when i say sway works, but last time i ran it on xu4 there was a cache issue that caused half of all renderables to not be rendered
<kinkinkijkin>
usually down to triangles or quads
<chewitt>
no, because I run Kodi under GBM so have no need for a windowing system
<kinkinkijkin>
hm
<kinkinkijkin>
also maybe it was fixed btw
macc24 has joined #panfrost
macc24 has quit [Excess Flood]
davidlt has quit [Ping timeout: 240 seconds]
macc24 has joined #panfrost
raster has quit [Quit: Gettin' stinky!]
phh has quit [Quit: No Ping reply in 180 seconds.]