<zmike>
it doesn't block anything because rpi4 didn't technically support the feature enough to be confirmant
<zmike>
but v3dv supports it enough to run zink
<Kuratius>
any idea why it failed for this application? Or would you need more information?
<Kuratius>
or is the feature just not implemented at all, not even enough for zink?
<zmike>
it sounds like something else is going wrong
<zmike>
unrelated to that
<zmike>
my guess is not setting up env vars to load the right mesa libs
<Kuratius>
So the arch install is missing the right mesa libs? Also is it normal that mesa sets llvmpipe as a fallback on debian, but not on arch?
<Kuratius>
or are you talking specifically about me?
<zmike>
dunno, I don't use arch at I can't comment
<Kuratius>
is the llvmpipe fallback something that happens normally when zink fails to load?
<Kuratius>
as in in, with a normal mesa install on non arch
<Kuratius>
Is there a way I or someone else could help with testing this better?
<Kuratius>
I'm somewhat interested in getting this to work properly, but I don't really have much knowledge about graphics development so the only thing I could do is test and provide logs
<Kuratius>
is there like a recommended distro I should try this with?
<Kuratius>
or just use debian and try to compile mesa from source, then try there and see if the result is different from arch?
<zmike>
not sure about the status of zink on any distro tbh
<zmike>
if you can get a backtrace from the crash that would be useful
<Kuratius>
assuming I had an up to date mesa install, what command would be needed for the backtrace?
<zmike>
run your command in gdb and type backtrace
<zmike>
I'd recommend filing a mesa issue
<zmike>
IRC isn't that reliable across timezones
<Kuratius>
will do when I have logs
pi_ has joined #zink
Kuratius has quit [Ping timeout: 480 seconds]
sinanmoh- has joined #zink
sinanmohd has quit [Read error: Connection reset by peer]
<dj-death>
anholt_: it's more flaky than the existing?
<anholt_>
dj-death: so, we're now at a ~95% passrate, with just one flake. I'm unsure if that flake is related to this MR -- is it a flake that would happen .1% of the time and I got unlucky, or is it new in this MR?
<anholt_>
it would be neat if our CI run had something that someone could go dig into to see what happened, like devcoredump
<dj-death>
anholt_: I'm expanding capture-devcoredump.sh right now to capture the i915 thing
<anholt_>
but also the frames of this trace are pretty slow and I wonder if we just got unlucky and pushed things over the edge for fence timeouts -- what are the timeouts i915 has currently for "we're making progress through the batch, but gosh that was slow so we killed it?"
<anholt_>
nice!
<dj-death>
anholt_: but my hopes are 0 for anything new/nice happening in i915
<dj-death>
I read people were looking at devcoredump for xe
<dj-death>
yeah the fence timeout is problematic
<dj-death>
there is knob to increase the timeout in sysfs