<mntmn>
what is the motivation for choosing a specific depth format? i'm comparing a blob trace and etnaviv trace, and in this example, the blob chooses D16 and etnaviv/mesa D24S8
<lynxeye>
mntmn: The driver doesn't choose the format, it's the application. Normally it asks about EGL configs with a minimum depth/stencil precision, then picks one of the options provided by the driver.
<lynxeye>
Obviously lower bit depth results in less bandwidth usage, thus higher performance.
<lynxeye>
Some dumb applications just pick the first option, so actual chosen format may depend on driver ordering of the options
<mntmn>
ah, that would explain it. i didn’t specify the depth resolution in the test.
berton has joined #etnaviv
lynxeye has quit [Remote host closed the connection]
<pcercuei>
mntmn: need some work on non-GPU related tasks? I'm for hire :)
<flto>
mntmn: have you tried playing with the VIVS_RA_EARLY_DEPTH value? (we have a comment saying blob uses 0x40000031 on GC7000, and your trace has 0x50000031, 0x10000000 could be related to early-z disable)
<Marex>
flto: I did that before, it didn't lead anywhere, but not on GC7000L all right
<flto>
these would be new GC7000L bits so not relevant to older gpus
<mntmn>
flto: yeah, i tried that. so 0x10000000 bit in RA_EARLY_DEPTH seems to disable depth testing (or writing) completely
<mntmn>
flto: 0x40000000 doesn't make a difference
<mntmn>
i'm wondering if the blob trace i got was correct. what it's doing seems kind of impossible.
<mntmn>
pcercuei: the biggest pain i have is etnaviv bugs, so i currently only need (paid) support for that
<lynxeye>
mntmn: so hey, you found the new disable_zs bit position
<flto>
mntmn: I have an old branch from working on passing gles3 tests and it has RA_EARLY_DEPTH set to 0x15000030 and BIT(18) set in PE_DEPTH_CONFIG, so maybe try that
<mntmn>
lynxeye: ah. :D
<mntmn>
flto: oh strange, ok i'll try
<mntmn>
this is why i think the trace might be not the right one:
<mntmn>
blob etna
<mntmn>
DEPTH_FUNC=0x7 DEPTH_FUNC=0x1
<mntmn>
DEPTH_MODE=NONE DEPTH_MODE=Z
<mntmn>
WRITE_ENABLE=0 WRITE_ENABLE=1
<mntmn>
lynxeye: what exactly does "zs" mean btw?
<lynxeye>
z as in depth, s as in stencil
<flto>
mntmn: looks like the BIT(18) in DEPTH_CONFIG is already upstream as part of something else, so try just the RA_EARLY_DEPTH value
<mntmn>
lynxeye: ah so it’s one bit for disabling both z and stencil? is z another way of saying depth?
<lynxeye>
yep, the Z-buffer in graphics means the depth buffer. As depth and stencil usually share teh same buffer storage (as with format Z24S8) you have a single bit to disable all access to both
<mntmn>
ahh, thanks for explaining!
<JohnnyonFlame>
any tool/doc/guide I can read on getting useful stats to identify slowpaths and whatnot on etnaviv? or should I just be using oprof+apitrace
<pcercuei>
JohnnyonFlame: know about GALLIUM_HUD?
<JohnnyonFlame>
I was thinking more in terms of like, more granular data than frametime alone
<JohnnyonFlame>
frametime & drawcalls/frame I guess
<mth>
perfetto was mentioned here recently, but I don't know the details
<cphealy>
GALLIUM_HUD will give you frametime and drawcalls/frame.
<JohnnyonFlame>
more than ftime and drawcalls/frame*
<mth>
from what I understand, that's the front-end, so it still needs a back-end that actually collects traces and counters
<cphealy>
You may want to use perf to see if there are any hotspots in Mesa under various use cases.
<cphealy>
That would be on the CPU though.
<JohnnyonFlame>
data on cpu overhead is a good enough start here I guess
<mth>
does apitrace log time stamps too?
<Marex>
and ETNA_MESA_DEBUG=nir , because TGSI generates poor shader program
<lynxeye>
flto: ... which reminds me: do we have any blockers left for flipping the switch on NIR?
<lynxeye>
IIRC there were only some very rare shaders, which generated better instruction scheduling for texture fetches by chance on TGSI. Which IMHO isn't really a good reason to keep the default on TGSI.
<mntmn>
flto: 0x15000030 doesn't make a difference except for the 0x10000000 which, as mentioned before, completely switches off Z
<flto>
lynxeye: apparently there is an assert failing during gles2 tests now
<Marex>
flto: only on gc7000l though
<Marex>
flto: and a lot of them
<austriancoder>
lynxeye: nir is not ready for prime time.. just use a debug build and try to run piglit or deqp
<Marex>
austriancoder: I do quite often run dEQP on anything which isn't GC7000L (that one is broken)
<austriancoder>
Marex: I have seen asserts on non gc7000l with piglit
<Marex>
austriancoder: isolated to gc7000l, right ?
<austriancoder>
JohnnyonFlame: GL_AMD_performance_monitor is supported to get some gpu related data (and the information is also available in GALLIUM_HUD)
<austriancoder>
Marex: have seen an assert on GC3000 with piglit
<Marex>
austriancoder: so maybe it would make sense to enable NIR on halti < 2 ?
<austriancoder>
Marex: all or nothing
<Marex>
austriancoder: that way, NIR will get basically no testing unless you know about it and there will be seldom any bug reports ... seems like a loss
<Marex>
gc3000/7000l can be fixed later
<mntmn>
soon we'll have >100 testers for NIR on GC7000: because i enable that by default ;)
<austriancoder>
let's fix the asserts and avoid the complexity in the driver
<mntmn>
i wonder if purism will ship with NIR enabled
<mntmn>
agx_: do you know?
<flto>
austriancoder: I guess some validation was added to NIR which makes etna_lower_io lowering of nir_intrinsic_load_uniform/ubo fail the validation.. it should be an easy fix
<Marex>
would it make sense to add etnaviv into the mesa CI ?
<austriancoder>
flto: jup
<austriancoder>
Marex: there is something in the works
<Marex>
austriancoder: it's been like that for a year or so, no ?
<austriancoder>
Marex: that's why I did step up and do it on my own... I have a proof of concept running and pushing out my changes (some of them already landed in master)
<Marex>
austriancoder: but no CI on push yet, to trap these new breakages ?
<lynxeye>
Marex: maintaining the test runners has a non-zero cost in terms of time, which is why I haven't jumped on-board the CI hypetrain.
<Marex>
lynxeye: well it's not hype, it prevents these kinds of breakages
<austriancoder>
Marex: not yet.. but soon
<austriancoder>
Marex: and I will start with gc2000
<austriancoder>
lynxeye: ci is needed at the stage where etnaviv is now.. we need to catch regressions early
<lynxeye>
I'm not telling anyone how to spend their time, I'm just saying that I don't have the bandwidth to babysit a farm of test-runners
<Marex>
lynxeye: agreed
<Marex>
austriancoder: nice
dv_ has quit [Ping timeout: 256 seconds]
<Marex>
mntmn: btw your example requires WL and Xwayland on top of that ?
<mntmn>
Marex: i don't think so?
<mntmn>
Marex: minetest yes but my test case should run without
<Marex>
maybe it's missing some FREEGLUT_WAYLAND=ON somewhere ?
<mntmn>
i don't know, GLUT is not important there, it's just 2 triangles
<mntmn>
maybe i should use another boilerplate
dv_ has joined #etnaviv
<Marex>
dont worry about it, I just wanted to try it on GC2000
<mntmn>
yeah i didn't even think about that this requires xwayland through glut, sorry
<mntmn>
what is good for wayland, glfw or so? probably SDL2
<daniels>
mntmn: damn, that's what I get for not testing on Weston - Mutter is rather permissive here. fixed, pull it again
<mntmn>
daniels: works!
<daniels>
\o/
<mntmn>
that looks pretty cool, even. gonna try it on the imx8mq now
<mntmn>
yep, that shows the problem nicely. thank you daniels!
<daniels>
np! hope the added shininess hopes you attract someone to fix :P
<daniels>
*helps
<mntmn>
haha yeah! will update the issue
<mntmn>
Marex: there's something you can try on GC2000 now ;)
JohnnyonFlame has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #etnaviv
JohnnyonF has joined #etnaviv
JohnnyonFlame has quit [Ping timeout: 264 seconds]
Johnny_ has joined #etnaviv
<Marex>
mntmn: just a second, I need to install about a gigabyte of dependencies for the build system (meson, ninja) ...
JohnnyonF has quit [Read error: Connection reset by peer]
Johnny_ has quit [Read error: Connection reset by peer]
<mntmn>
Marex: haha
<mntmn>
i'm always extremely happy when i see a meson.build because it means it will build reasonably fast on the target
JohnnyonFlame has joined #etnaviv
<Marex>
mntmn: faster than running gcc ... ? :)
JohnnyonF has joined #etnaviv
<Marex>
mntmn: I rewrote it into that gfx thing, so let's see
<mntmn>
Marex: faster than running make
JohnnyonFlame has quit [Read error: Connection reset by peer]
<daniels>
Meson doesn't need anything outside Python core, ninja similarly (only libc and libstdc++); its package install size on Debian is 300kB which includes all the docs and changelogs ...
<daniels>
(make is 1.5MB)
<mntmn>
almost fits on a floppy disk
<Marex>
except for the python :)
<daniels>
the subset of Python that Meson depends on is a 640kB install :P
<Marex>
mntmn: ok yep, I have the same test on this gfx thing, except it's much simpler
<mntmn>
Marex: so, does it work on GC2000?
<Marex>
mntmn: I think so
<Marex>
mntmn: if I rewrote the test right
<mntmn>
Marex: i posted screenshots in that issue ticket