stikonas has quit [Remote host closed the connection]
vstehle has quit [Ping timeout: 264 seconds]
kaspter has joined #panfrost
kaspter has quit [Excess Flood]
kaspter has joined #panfrost
AreaScout_ has quit [Ping timeout: 260 seconds]
davidlt has joined #panfrost
_whitelogger has joined #panfrost
davidlt has quit [Ping timeout: 260 seconds]
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #panfrost
buzzmarshall has quit [Remote host closed the connection]
vstehle has joined #panfrost
nerdboy has quit [Ping timeout: 264 seconds]
davidlt has joined #panfrost
icecream95 has joined #panfrost
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 265 seconds]
camus1 is now known as kaspter
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
nerdboy has joined #panfrost
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
<tomeu>
robmur01: echo 0x1ff > /sys/module/drm/parameters/debug will probably make the cause be printed on the console
raster has joined #panfrost
TheMojoMan has joined #panfrost
TheMojoMan has quit [Quit: Connection closed]
davidlt has quit [Remote host closed the connection]
davidlt has joined #panfrost
<icecream95>
robmur01: kmscube wasn't working for me on 5.8, but after 348d374d013 it works. Are you sure you are using the right branch/remote for Mesa?
<robmur01>
tomeu: derp, I should have thought of that - the one thing that stands out is "Invalid pixel format XR24 little-endian (0x34325258), modifier 0xffffffffffffffff"
<icecream95>
robmur01: I get the same message for Mesa < 348d374d013
<tomeu>
hrm, why would xrgb8888 be invalid...
<robmur01>
icecream95: sigh, apparently the point at which I pulled yesterday was literally two commits before !6159 landed
<hanetzer>
so, question. at any point during panfrost's development, was static analysis used at all?
<hanetzer>
eg, objdump, ida, radare, ghidra
<robmur01>
seems OK now
<HdkR>
hanetzer: Nothing that contributed
<hanetzer>
nifty.
<HdkR>
It's a legal concern depending on region, so it shouldn't be done
<hanetzer>
truthy statement, as far as anything regarding laws can be truthy
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
<robmur01>
BTW, I did some more rvgl testing, and Profile=0,Shaders=1 with PAN_MESA_DEBUG=gl3 does indeed render correctly, but is the *only* combination that does so
<robmur01>
without PAN_MESA_DEBUG it won't event start
<robmur01>
Shaders=1,Profile=2 has a different visual bug
<robmur01>
and anything with Shaders=0 still has the original glitches
<bbrezillon>
tomeu: it's the modifier that's invalid
<tomeu>
oh, ti has become invalid after the afbc work, right?
<bbrezillon>
well, IIRC, 0 == linear, and 0xfffff... is pick the one you prefer
<robmur01>
so whatever the fix was it doesn't seem to be applying to the fixed-function GL/ES corner of gallium
<tomeu>
robmur01: fixed-function will hit some unrelated bug?
<icecream95>
With Shaders=0 I'm hitting the assertion !zsa->alpha.enabled in panfrost_create_depth_stencil_state
<HdkR>
womp womp
_whitelogger has joined #panfrost
kaspter has quit [Quit: kaspter]
<robmur01>
FWIW that would also have been with yesterday's master at 371f6f42ad
<icecream95>
alyssa: AFBC regresses performance in some situations for me - glmark2-es2 -b pulsar has gone from almost 1500 fps to 1150 fps
<urjaman>
the difference in frame time with such big fps numbers isnt a lot tho
<icecream95>
alyssa: AFBC also caused DarkPlaces to be unplayable - frame rates are in the single digits now
<icecream95>
pan_js is using about 20% CPU, which seems a lot...
<HdkR>
minmax calculation for indexed draws? :P
<icecream95>
HdkR: These are kernel threads, so shouldn't be going anywhere near GPU job descriptors, but minmax calculation hasn't been a bottleneck for a while anyway
<tomeu>
pan_js is the kernel thread that submits the jobs to the hw
<HdkR>
ah
<tomeu>
icecream95: do you have that in perf? if so, can you annotate and see what within it takes so long?
stikonas has joined #panfrost
<icecream95>
tomeu: pan_js spends a lot of time in queue_delayed_work_on and cancel_delayed_work, and spinlock functions. drm_gem_object_put_unlocked is the top drm function that perf shows
<tomeu>
ok, if there's spinlocks, then that's the problem
<tomeu>
we shouldn't be spending any sensible amount of time with that
<tomeu>
is it with a very specific workload?
<icecream95>
tomeu: I've only seen it with DarkPlaces so far
<tomeu>
oh, I guess what happens is that the GPU jobs take longer than the timeout
<tomeu>
then we get into a cancel storm
<tomeu>
we could increase the timeout to see if the storm doesn't happen, but I guess there's some problem with the GPU taking so long
<icecream95>
tomeu: dmesg doesn't show anything about job timeouts
<tomeu>
ok, then I guess we are using spinlocks to wait for BOs to be released by previous jobs?
<tomeu>
sounds quite awful
robmur01 has quit [Read error: Connection reset by peer]
robmur01 has joined #panfrost
icecream95 has quit [Quit: leaving]
buzzmarshall has joined #panfrost
tomboy65 has quit [Ping timeout: 240 seconds]
<alyssa>
"!zsa->alpha.enabled in panfrost_create_depth_stencil_state"
<alyssa>
This definitely smells like a Gallium bug, we're not setting CAP_ALPHA_TEST
<alyssa>
Hm. Not sure why AFBC would make things *slower* in practice ...
tomboy65 has joined #panfrost
<tomeu>
alyssa: maybe there's some extraneous blits to linear?