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
raster has quit [Quit: Gettin' stinky!]
stikonas has quit [Remote host closed the connection]
yann has quit [Ping timeout: 246 seconds]
vstehle has quit [Ping timeout: 256 seconds]
_whitelogger has joined #panfrost
davidlt has joined #panfrost
agrisis has quit [Quit: agrisis]
tomboy64 has quit [Remote host closed the connection]
tomboy64 has joined #panfrost
buzzmarshall has quit [Remote host closed the connection]
vstehle has joined #panfrost
guillaume_g has joined #panfrost
_whitelogger has joined #panfrost
<macc24> is there a program to measure where bottleneck is?
<macc24> with midgard gpu
<HdkR> and perf top
* macc24 noted
yann has joined #panfrost
nlhowell has joined #panfrost
warpme_ has joined #panfrost
<macc24> so i think i caught a bug in panfrost, https://i.imgur.com/lLJ4emM.png
<macc24> it returns to normal after changing size of window
<macc24> and the window is really slow
<macc24> i see nothing in dmesg
<macc24> this is firefox
stikonas has joined #panfrost
<daniels> macc24: is it running natively or under Xwayland?
<macc24> daniels: under Xwayland
<icecream95> macc24: Is this a very recent regression?
<macc24> icecream95: yeah, i have noticed it today
<icecream95> macc24: Does it still happen if you revert 23ad95227a8?
<macc24> icecream95: let me check
<macc24> icecream95: still happens with 23ad95227a8 reverted
nlhowell has quit [Ping timeout: 256 seconds]
nlhowell has joined #panfrost
<macc24> icecream95: compiling
<daniels> icecream95: wouldn't you also need to do that in handle_from_resource, so you don't transition exported resources whilst they're being used by the winsys or kms or whatever?
raster has joined #panfrost
<macc24> icecream95: issue still happens
_whitelogger has joined #panfrost
_whitelogger has joined #panfrost
icecream95 has quit [Ping timeout: 260 seconds]
nlhowell has quit [Ping timeout: 256 seconds]
nlhowell has joined #panfrost
nlhowell has quit [Ping timeout: 246 seconds]
nlhowell has joined #panfrost
Depau has quit [Quit: ZNC 1.8.1 - https://znc.in]
nlhowell has quit [Ping timeout: 240 seconds]
Depau has joined #panfrost
nlhowell has joined #panfrost
nlhowell has quit [Ping timeout: 256 seconds]
nlhowell has joined #panfrost
_whitelogger has joined #panfrost
Ntemis has joined #panfrost
rak-zero has quit [Ping timeout: 260 seconds]
nlhowell has quit [Ping timeout: 256 seconds]
buzzmarshall has joined #panfrost
leper` has quit [Ping timeout: 240 seconds]
leper` has joined #panfrost
nlhowell has joined #panfrost
nlhowell has quit [Ping timeout: 258 seconds]
adjtm has joined #panfrost
raster has quit [Quit: Gettin' stinky!]
adjtm has quit [Quit: Leaving]
agrisis has joined #panfrost
<agrisis> I have an odroid go advance and managed to boot kernel 5.9 w/ panfrost, I didn't manage to get a drm app up yet but I was curious if drm workflow goes through the panfrost driver?
<robmur01> panfrost is a render-only driver, i.e. it only handles the GL stuff - all the other DRM stuff is done by the display driver
tomboy64 has quit [Ping timeout: 240 seconds]
<agrisis> robmur01: ok thanks, I asked because I vaguely recall seeing something along the lines of PANFROST_*_DRM* config option in my kernel
<agrisis> robmur01: btw, how is the perf compared to g31 bifrost proprietary driver?
<robmur01> yeah, it's still a "DRM driver" in the sense of the sense of the userspace interface and how it interacts with the display, it just won't be involved in anything other than 3D rendering ;)
<agrisis> ah fair enough
<macc24> agrisis: i think rockchipdrm handles display on your device
<robmur01> (where "3D rendering" may effectively just be 2D, in compositors etc.)
<robmur01> I think Bifrost is still very much WIP, so don't set your expectations too high
<agrisis> I'm asking because one emulator developer commented on what he thought bifrost proprietary driver to be slower than expected, also it looks to be r6 whereas some other mali gpu drivers are in the r12+ release range
<agrisis> I have yet tried wayland on panfrost yet
<macc24> oh wayland runs better in my experience than xorg
<agrisis> would be curious to see if non-accel 2D graphics are faster in panfrost+wayland compared to DRM-KMS
<macc24> "non-accel 2d graphics" as in what?
<agrisis> macc24: as in whatever you would call this: https://github.com/libretro/RetroArch/blob/master/gfx/drivers/drm_gfx.c
<robmur01> I can't imagine that software rendering into a buffer can be any slower than software rendering into a buffer that a compositor then has to do something with
<agrisis> you're probably right
tomboy64 has joined #panfrost
<robmur01> of course there may be behavioural differences in terms of vsync/latency/etc., but in terms of processing effort, compositing is always going to involve more work than not compositing
tomboy64 has quit [Ping timeout: 240 seconds]
davidlt has quit [Ping timeout: 265 seconds]
tomboy64 has joined #panfrost
tomboy64 has quit [Ping timeout: 240 seconds]
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
tomboy64 has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
raster has joined #panfrost
raster has quit [Client Quit]
raster has joined #panfrost
<macc24> is this issue with panfrost?
<macc24> launching chromium with --no-sandbox fixes it
kinkinkijkin has quit [Ping timeout: 246 seconds]
mareko has joined #panfrost
<mareko> can somebody please have a look at these CI failures? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6283
<HdkR> tomeu and daniels I guess to look at it? :)
<HdkR> Of course it's like....9PM over there?
<bnieuwenhuizen> HdkR: looking at it, might actually be a driver issue and not a CI problem?
<bnieuwenhuizen> deqp runs, but crashes all in dEQP-GLES2.functional.*
Ntemis has quit [Read error: Connection reset by peer]
<daniels> HdkR: 9pm indeed
<HdkR> :)
<daniels> mareko: at a guess, you're hitting asserts, and we should figure out how to surface those
<daniels> mareko: thanks for letting us know, we'll try to pick this up and figure it out
<alyssa> macc24: not panfrost i don't think
<alyssa> mareko let me see
icecream95 has joined #panfrost
<alyssa> 49608d46bb54f567458ecef6a1829cf023bb8191 is causing the issue for us due to NIR we produce, let me tighten that
<icecream95> macc24: That is a Chromium bug - see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965960
<alyssa> i'm out-of-office tomorrow but that should fix it, apply that at the beginning of your series and things should be ok (and you have my permission to push that)
<mareko> alyssa: thanks, that was quick
yann has quit [Ping timeout: 265 seconds]
<mareko> there is just one lowp modf failure now: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/4499133
<icecream95> mareko: For that failure, ftrunc is done on a 32-bit value, and on the same value after rounding to 16-bit, so for the input of 1.99955 in the deqp test the first one returns 1, and the second 2
<mareko> icecream95: that's correct, isn't it?
<mareko> icecream95: what does the MR change there?
<icecream95> mareko: Both are part of a single modf operation, so should be consistent
<icecream95> NIR_PRINT=1 where the second ftrunc is inserted: https://gitlab.freedesktop.org/-/snippets/1175/raw
raster has quit [Quit: Gettin' stinky!]