alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
<macc24> yeah it is a bug
<macc24> when cpus 4-7 are running, cci freq doesn't rescale
warpme_ has quit [Quit: Connection closed for inactivity]
karolherbst has quit [Ping timeout: 272 seconds]
archetech has joined #panfrost
chewitt_ is now known as chewitt
vstehle has quit [Ping timeout: 265 seconds]
kaspter has joined #panfrost
stikonas has quit [Remote host closed the connection]
<felipealmeida> macc24: kirin_drm upstream doesn't implement hi3660. I'll see if it is possible to forward-port it.
<macc24> felipealmeida: i wish you luck
archetech has quit [Quit: Konversation terminated!]
<kinkinkijkin> hey macc24, could you put up the kernel Image somewhere?
<kinkinkijkin> if you already have it built
<kinkinkijkin> imma try kexec again
chrisf has quit [Remote host closed the connection]
chrisf has joined #panfrost
davidlt has joined #panfrost
<q4a> icecream95 hi. What is your latest vulkan branch and what is it current state?
camus has joined #panfrost
<icecream95> q4a: Because of https://airlied.blogspot.com/2020/08/vallium-software-swrast-vulkan-layer-faq.html, I'm not intending to do any more work on that branch
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
<q4a> icecream95 url says `Sorry, the page you were looking for in this blog does not exist.`
<icecream95> q4a: Did you remove the comma at the end of the URL?
<q4a> ah, sorry
<icecream95> q4a: But at https://gitlab.freedesktop.org/panfrost/mesa there are the beginnings of a completely separate vulkan driver which might eventually be upstreamed
<q4a> icecream95 on master?
<icecream95> q4a: yes
<q4a> icecream95 and what do you think about v3dv https://gitlab.freedesktop.org/mesa/mesa/-/tree/master/src/broadcom/vulkan - will it helpfull?
<icecream95> q4a: The Panfrost driver I linked to is based on the freedreno vulkan driver, but they should all be similar enough that you can use any of them as a reference
<q4a> Thanks a lot
<icecream95> q4a: Note that the branch is a number of months old, and Panfrost has significantly changed since then. I'm currently attempting to rebase it on master
chewitt has left #panfrost ["Adios!"]
chewitt has joined #panfrost
agrisis has quit [Ping timeout: 272 seconds]
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #panfrost
icecream95 has quit [Ping timeout: 256 seconds]
vstehle has joined #panfrost
icecream95 has joined #panfrost
icecream95 has quit [Ping timeout: 260 seconds]
icecream95 has joined #panfrost
<icecream95> q4a: Rebased branch: https://gitlab.freedesktop.org/icecream95/mesa/-/commits/vk (only compile tested so far)
<q4a> thanks
icecream95 has quit [Ping timeout: 240 seconds]
icecream95 has joined #panfrost
icecream95 has quit [Ping timeout: 264 seconds]
camus has joined #panfrost
kaspter has quit [Ping timeout: 264 seconds]
camus is now known as kaspter
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
chewitt has quit [Client Quit]
camus has joined #panfrost
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
karolherbst has joined #panfrost
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #panfrost
_whitelogger has joined #panfrost
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #panfrost
warpme_ has joined #panfrost
raster has joined #panfrost
urjaman has quit [Read error: Connection reset by peer]
urjaman has joined #panfrost
<q4a> Hi. Is there way to switch mesa between original installation from repo and compiled+installed from sources?
<macc24> kinkinkijkin: yeah i can
stikonas has joined #panfrost
guillaume_g has joined #panfrost
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
tomboy64 has quit [Ping timeout: 240 seconds]
tomboy64 has joined #panfrost
<macc24> /join #libreboot
<macc24> oops, space
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
chewitt has joined #panfrost
gcl_ has joined #panfrost
gcl has quit [Ping timeout: 265 seconds]
agrisis has joined #panfrost
camus has joined #panfrost
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
<q4a> https://gitlab.freedesktop.org/icecream95/mesa/-/blob/178d13a33a28f39f14c217df66d8958d9132a9aa/meson.build#L255 - this mean, that panfrost vulkan driver vill not build by default - is that ok?
<q4a> This is test branch for panfrost vulkan, so may be better enable it by default?
<macc24> q4a: just pass -Dvulkan-drivers=panfrost or something
<HdkR> Lots of drivers aren't built by default :)
<q4a> *this
kaspter has quit [Quit: kaspter]
<q4a> ok, I created PR to fix build errors: https://gitlab.freedesktop.org/icecream95/mesa/-/merge_requests/1
<q4a> Hope, that icecream95 will accept it
<q4a> This simple test return `13 extensions supported` with lavapipe and only `7 extensions supported` with basic panfrost vulkan
<macc24> q4a: does it render anything btw?
<pmjdebruijn> https://pastebin.com/mD1dxUeB does that ring any bells, I got this on 5.10.5 combined with mesa 20.3.2, running crispy-doom through sdl2/opengles2
<macc24> pmjdebruijn: is that bifrost?
<pmjdebruijn> G52
<pmjdebruijn> (no X11 involved)
<macc24> this may be fixed in mesa-git
<pmjdebruijn> is there any patches I should cherrypick?
<macc24> i don't know
<q4a> macc24 - no. And I'm not sure, where is simple triangle) This one is 1200+ lines:
<pmjdebruijn> btw, given that this is a kernel trace, wouldn't the root cause always be kernel-side?
<macc24> 5.10 is working fine on bifrost for me
agrisis has quit [Ping timeout: 272 seconds]
<macc24> crispy-doom is working fine for me on g72 with mesa-git
<pmjdebruijn> through opengles2?
<macc24> through the default
<pmjdebruijn> macc24: try crispy-doom -timedemo demo3
<pmjdebruijn> macc24: should be opengles2 if you start it from the console
<macc24> pmjdebruijn: ok gimme 20 minutes
<pmjdebruijn> but still is a kernel through, so I'm somewhat skeptical the problem is in mesa
<macc24> iirc data_invalid_fault means that gpu got bad data from gl driver and gpu complained about it to panfrost module
<pmjdebruijn> I still have to test if it's reproducable or erratic on my end btw
<pmjdebruijn> macc24: it wasn't gracefully handled, as my display console was unusable after
<pmjdebruijn> serial console kept working though
<pmjdebruijn> i'll do more testing on my end, and possibly try git mesa
<pmjdebruijn> it's also amazing how much the pixel scaling algo matters wrt performance
<pmjdebruijn> nearest = 220fps, linear=90fps
<pmjdebruijn> oh starting dosbox generates continuous DATA_INVALID_FAULT
<pmjdebruijn> i'll be trying git mesa soon
<pmjdebruijn> oh git seems to provide a huge performance boost already
<pmjdebruijn> and dosbox starts at al
<pmjdebruijn> I still see some FAULTs on dmesg, but nothing that stops anything from practically working
ids1024 has joined #panfrost
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #panfrost
raster has quit [Quit: Gettin' stinky!]
raster has joined #panfrost
archetech has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
<thecycoone1> pmjdebruijn: I had good luck with dosbox-staging (search on github, it's a fork but it has wayland and better arm support)
<macc24> alyssa: should i test the patch now?
<Lyude> alyssa: what kinda work is still left to do on bf btw? just curious
<macc24> Lyude: probably gl3 and optimization
<Lyude> gotcha
<macc24> probably
davidlt has quit [Ping timeout: 240 seconds]
icecream95 has joined #panfrost
<q4a> icecream95 I saw, that you merged my changes. Thanks. I'm not good in vulkan, but I would like to try and implement some parts. How development of vulkan driver can be splitted?
<q4a> It's better on focusing draw real triangle or some parts of Vulkan CTS?
<alyssa> Everything in the CTS will depend on the first triangle.
<alyssa> So it's probably easier to try to get vkcube (or just a triangle) working, after that you'll have more options :)
<alyssa> Lyude: A _lot_ of optimizations, and some feature work to bring up shiny APIs
<alyssa> icecream95: has been not-so-quietly bringing up OpenCL on Bifrost (and Midgard)
<macc24> alyssa: fyi bugs are still present, even in newest patch version
<alyssa> macc24: Can you send an apitrace?
<alyssa> Thanks :)
* macc24 inhales
* macc24 exhales
<macc24> ok
<alyssa> Bwa?
<macc24> yes it is supposed to close after kart menu
<macc24> renders correctly on my desktop with radeonsi gpu
<alyssa> thanks
<alyssa> oof, big
<macc24> you need PAN_MESA_DEBUG=deqp for that
<macc24> gles3 context...
<macc24> without that supertuxkart segfaults at least on g72\
<macc24> alyssa: sha1 is ea9b0f
<alyssa> let's take a look then.. thanks
<macc24> there's also dmenu weirding out, couldn't get apitrace of it
<alyssa> If we're lucky it's the same bug
<macc24> doesn't look to be for me
<macc24> but we can always hope
<alyssa> I downloaded the trace, can confirm it looks right on midgard
<alyssa> guess I need to plug HDMI into my n2 for this..
<macc24> how about bifrost that people actually care about(g31/g52)?
<alyssa> N2 is G52
<macc24> i had to make this joke
<alyssa> ?
<macc24> "bifrost that people actually care about" <- this was implying that people don't care about g72
<HdkR> Jokes and things :)
<br_> Is swrast_dri.so needed for OpenGL apps ? I found that xorg starts normally, but glxgears/xmoto don't
<macc24> br_: strace it to check why panfrost_dri isn't loaded?
<macc24> or use strace equivalent on freebsd
<br_> so swrast_dri.so should not be needed ?
<HdkR> Shouldn't be needed
<macc24> Shouldn't be needed
<br_> ok
<HdkR> Almost every mesa driver provides both GL and ES :P
<macc24> ^ if no gl use gl4es
<macc24> or fix the damn drivers
archetech has quit [Quit: Konversation terminated!]
nlhowell has quit [Ping timeout: 240 seconds]
nlhowell has joined #panfrost
<alyssa> macc24: Give the branch scheduler-fixes a spin
<alyssa> It seems to fix STK for me.
<alyssa> Hopefully dmenu is the same bug or two
<alyssa> GPU spill code is notoriously hard to get right
<alyssa> (I.e. still pprobably wrong somehow..)
<br_> macc24: HdkR: despite swrast is needed to run glxinfo/demos in my case, it shows "Renderer: Panfrost"
nlhowell has quit [Ping timeout: 272 seconds]
<macc24> alyssa: okay
<HdkR> br_: weird
<br_> glxinfo -B shows that I have two screen
<br_> display: :1 screen: 0 panfrost
<br_> display: :1 screen: 1 VMware, Inc.
<alyssa> VMware = llvmpipe = swrast
<alyssa> well, =>
<br_> should I have two cards in /dev/dri/ ?
<br_> card0, card1
<macc24> br_: i have 3 cards in /dev/dri
<macc24> does freebsd include something like vgem?
<br_> I don't know what is vgem
<br_> one of my card is rockchip DRM
<br_> another is panfrost DRM
<macc24> i don't know to
<br_> but on the laptop (x86) I have card1 only, no card0
<alyssa> br_: that's normal
<alyssa> rockchip is display, panfrost if 3d
<alyssa> *is
<icecream95> DRM_VGEM: "Choose this option to get a virtual graphics memory manager as used by Mesa's software renderer for enhanced performance."
<macc24> br_: display and 3d are completely different devices in case of mali + rockchip
<alyssa> icecream95: "software renderer for enhanced performance" Love the doublespeak ;P
<macc24> alyssa: u broke my sway with scheduler-fixes :(
<macc24> oh nvm it's just rendering so slowly
<alyssa> uh oh, that sounds like breaking worse ;-;
<macc24> supertuxkart turned into flashing "Loading"
<macc24> definitely something wrong
<macc24> alyssa: https://bpa.st/ROBA
<br_> can someone on linux try xmoto and press F7 for FPS ?
<macc24> br_: i'd try it if certain someone didn't broke sway
<icecream95> br_: yes
<icecream95> alyssa: With VGEM enabled, LLVMPipe can render Quake 1 @ 1920x1200 at a playable framerate on duet
<macc24> icecream95: before learning about deqp supertuxkart hack i was playing supertuxkart on llvmpipe
<macc24> i posted a pic some time ago
<alyssa> macc24: ok how'd it break it this time..
<macc24> alyssa: apitrace?
<alyssa> uhhh
<br_> icecream95: on xmoto I have about u(40), d(20) average, highest u(50), d(30). Not sure what u and d mean
<br_> on rk3399
<macc24> br_: what mesa version?
<br_> not sure, just built today from git
<macc24> ok
<macc24> br_: ill tell you results on my kevin after mesa compiles
<alyssa> macc24: I can't seem to reproduce the faults on g52
<br_> xmoto takes entire core (97%), xorg 20% during game
<macc24> alyssa: oh no
<br_> so overall 77% of system (6 cores)
<alyssa> icecream95: You wouldn't happen to know anything about mesa winsys integration on... Darwin? 😅
<alyssa> macc24: You're sure it's only that branch>
<alyssa> and only that last commit?
<macc24> git merged master, ill try that branch
<macc24> sorry for causing trouble
<alyssa> hmm?
<alyssa> (The STK bug was very real and CI didn't catch it. You have nothing to be sorry for, I should be thanking you :) )
<alyssa> [And that would've been ugly to bisect.]
nlhowell has joined #panfrost
<macc24> ill recompile mesa on my duet... might take some time
<br_> nlhowell: rinet )
<br_> nlhowell: I was using it in Moscow
<macc24> icecream95: i think that cci bug doesn't have to be fixed. if task eats all of one small core, kernel should be smart enough to move it to big core
<alyssa> macc24: I'm confused.
<icecream95> macc24: But the bug is for the big cores
<macc24> icecream95: o.o
agrisis has joined #panfrost
<icecream95> br_: I usually get 40-50 fps (corresponding to the 'd' value) in xmoto, but different CPU/GPU so not directly comparable
<macc24> br_: u 100 d 50
<macc24> on rk3399 800x600 32bpp max settings
<macc24> alyssa: still broken
<macc24> and it looks like after a while it ends up rendering the frame
<macc24> and window borders draw correctly
<macc24> in sway
<alyssa> I don't understand why it would fault for you but not for me, I don't know of architectural differences affecting spilling ..
<macc24> kmscube works fine
<icecream95> br_: Xmoto eats about 150% CPU and sway takes another 15
anarsoul has quit [Read error: Connection reset by peer]
<alyssa> macc24: And it's definitely that last patch that introduces the faults?
<macc24> alyssa: i used the branch this tiem
<macc24> time*
<alyssa> right, if you revert the top commit (the one with IRC logs spammed in), it works?
<macc24> lemme check
<macc24> still broken
karolherbst has quit [Ping timeout: 272 seconds]
<macc24> do you want apitrace?
<macc24> it renders fine in my radeonsi setup
<icecream95> I can reproduce the faults, will try bisecting
<icecream95> macc24: Try with PAN_MESA_DEBUG=noafbc
<macc24> icecream95, alyssa: noafbc makes it work fine
icecream95 has quit [Quit: Reconnecting]
icecream95 has joined #panfrost
<macc24> icecream95: received my previous message?
<icecream95> macc24: yes
karolherbst has joined #panfrost
<macc24> brb
<alyssa> AFBC sounds like not-my-problem then? 😇
<alyssa> bbrezillon: ^^
anarsoul has joined #panfrost
<icecream95> alyssa: See 471fd78e3c5 ("panfrost: Fix AFBC on Bifrost v6")
<alyssa> Did the fix not fix it?
raster has quit [Quit: Gettin' stinky!]
<icecream95> alyssa: git log scheduler-fixes | grep 471fd78e3c5
<alyssa> icecream95: Ugh. Thanks. You're the best.
<icecream95> alyssa: Best at what?
<alyssa> icecream95: idk, panfrost development? fixing my awful mistakes? :p
<alyssa> macc24: Pull and rebuild, issue is fixed, thank icecream95 not me.
<icecream95> alyssa: Speaking of mistakes, have you fixed the bugs when ssa_0 is not load_const yet?
<alyssa> icecream95: right, meant to ask about that, do you have a GL reproducer?
<alyssa> (Is clover still awful to setup? I got burned by SPIRV LLVM versioning out of tree and related nonsense)
<alyssa> btw i use debian
<icecream95> btw I no longer use Arch
raster has joined #panfrost
warpme_ has quit [Quit: Connection closed for inactivity]
<alyssa> Gentoo?
<alyssa> Void?
<alyssa> LFS?
<icecream95> alyssa: I found the bug with piglit/tests/spec/arb_compute_variable_group_size/execution/separate-global-id-2.shader_test
<cphealy> Do the Midgard and/or bifrost GPUs have special bits that allow a glClear to operate at a rate much faster than the typical shader pixel fill rate?
<alyssa> cphealy: Yes, in good conditions.
<alyssa> icecream95: I should download piglit shouldn't i
<alyssa> uh do I even have connectivity on my bifrost board anymore
<alyssa> it doesn't have wifi and the ethernet is inoperable here..
<icecream95> cphealy: Clears are done with fixed-function hardware before rendering starts on a new tile
<icecream95> It's faster to clear than not to clear, as otherwise the GPU has to load the old contents of the tile from RAM
<alyssa> * unless you scissor or mask
<cphealy> Is this faster as in 2x, 4x, 8x, or is this special HW where it's hundreds/thousands of times faster than the fill rate to do a clear because of this fixed-function HW?
<cphealy> With old Adreno 200, it's like 2x or 4x faster to do a clear based fullscreen color. With Vivante, it's like 100x or more because special HW is setting tile-status regs with clear color.
<alyssa> cphealy: If you render _anything_ whatsoever, the hardware _has_ to do a fullscreen clear
<HdkR> `Because of the way tiling works, using glClear is essentially a free operation. Clearing only a part of the buffer is inefficient both in terms of time and power consumption.`
<alyssa> So if you don't call glClear, it's still doing the clear, and then a bunch of work (in the shaders) on top of it to keep up the illusion of not cleared
<cphealy> Got it, this makes sense.
<cphealy> So, for a 2D GPU that is fragment shader bound and a solid color background can be used, it's going to be much faster to just set the clear color than to do a fullscreen solid color background rectangle then, correct?
<alyssa> Absolutely
<cphealy> Excellent, thank you!
<alyssa> ok, odroid is tethered to my laptop's wifi
<alyssa> mildly horrifying
<icecream95> alyssa: With working forwarding? I never worked out how and just use an SSH SOCKS proxy...