alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - https://gitlab.freedesktop.org/panfrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
<alyssa> Oh, and I'm up to date according to git branch
<alyssa> Woohoo!
<alyssa> "This example is based on a Java algorithm for finding the gcd. (It is not important to understand what this function does.)
<alyssa> "
<alyssa> Thanks wikipedia.
<alyssa> Actually that whole section is problematic but I shouldn't edit wikipedia on worktime :p
davidlt has quit [Remote host closed the connection]
davidlt has joined #panfrost
unoccupied has joined #panfrost
davidlt has quit [Ping timeout: 272 seconds]
_whitelogger has joined #panfrost
davidlt has joined #panfrost
megi has quit [Ping timeout: 268 seconds]
davidlt has quit [Ping timeout: 248 seconds]
<tomeu> alyssa: when I saw "Job's log exceeded limit of 16777216 bytes" it was because we were stuck running once and again the same tests
<tomeu> I'm not looking at it because hopefully we are moving to a proper runner soon
<tomeu> Prf_Jakob: any luck with the arm* deqp runner?
<Prf_Jakob> tomeu: Yupp, I can make a "release" and upload a binary.
<Prf_Jakob> I found out that GDC doesn't support va_args on AArch64, so it's not a Volt issue that stops you from using the virgl approach but a D issue.
<daniels> egh
<tomeu> Prf_Jakob: but even with that issue, deqp will work?
<Prf_Jakob> tomeu: Yupp
<tomeu> awesome
<tomeu> Prf_Jakob: would armhf be much additional work?
<Prf_Jakob> tomeu: I can look into it on the weekend, I know all the simple mechanical work now. Just don't know if I will run into any more hairy armhf is crazy and expect the compiler to do a lot of work.
<tomeu> cool
<tomeu> will give it a try here as soon as you pass me the aarch64 binary
<tomeu> maybe alyssa will let me extend coverage if it's fast enough :)
<Prf_Jakob> Hehe :D
Elpaulo has quit [Quit: Elpaulo]
<tomeu> Prf_Jakob: let's see how it goes :) https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/506941
<Prf_Jakob> tomeu: Hmm looks like it failed, can't see anything in the log :-/
<tomeu> Prf_Jakob: it failed with:
<tomeu> 2019-08-15T09:01:39 Test names file not supplied, use:
<tomeu> and
<tomeu> 2019-08-15T09:01:39 Result file not supplied, use:
<tomeu> wonder how I should generate those
<Prf_Jakob> It's just those long lists of test names
_whitelogger has joined #panfrost
<tomeu> Prf_Jakob: what about the results file, can I omit one to get the initial results?
<Prf_Jakob> /dev/null ?
<tomeu> will try
<Prf_Jakob> Should work
<tomeu> Prf_Jakob: oh, that's the output results?
<Prf_Jakob> yeah
<tomeu> nice, let's see
<tomeu> Prf_Jakob: has it been considered omitting passing tests from the results file? to make it more git-friendly
<Prf_Jakob> tomeu: That's a good idea, no I haven't thought about that :)
<Prf_Jakob> tomeu: Can add it if you like
<tomeu> would be awesome :)
<Prf_Jakob> Btw --results-file /dev/null works
<tomeu> I'm outputting to a local file that I cat afterwards
<tomeu> I initially thought that it was the previous results file for comparison
<Prf_Jakob> So there is a couple of things I can do.
<Prf_Jakob> "--results-file -" can output the results to stdout
<Prf_Jakob> And then have a "--log-file <log>" for what usualy goes to stdout.
<tomeu> I think for now things are fine
raster has joined #panfrost
<Prf_Jakob> Just pruning the results for passing?
<tomeu> Prf_Jakob: oh, i meant that outputting results to a file and having the logs in stdout is fine for me
<Prf_Jakob> Okay
<tomeu> Prf_Jakob: omitting passes from the results file would be great to have
<tomeu> 2019-08-15T09:44:24 /home/jakob/Volt/watt/src/watt/io/file.volt:404: panic: Uncaught exception
<Prf_Jakob> Ok!
<tomeu> 2019-08-15T09:44:24 C4watt2io4file13FileException
<tomeu> 2019-08-15T09:44:24 couldn't change to path '/deqp/external/openglcts/modules'
<tomeu> I remove a lot of stuff from the deqp install dir, as we're short on ramdisk space
<tomeu> is that needed?
<Prf_Jakob> Yes, I'm pretty sure the deqp runner expects to be launched from that directory
megi has joined #panfrost
<tomeu> currently I only leave modules/gles2 and it works fine for that
<tomeu> I do have to run deqp-gles2 from /deqp/modules/gles2 though
<tomeu> but not from /deqp/external/openglcts/modules
<Prf_Jakob> Let me check
<Prf_Jakob> So /deqp is the build dir?
<Prf_Jakob> So modules/gles2 is in /deqp/modules/gles2 ?
<Prf_Jakob> Yupp that seems to work
<Prf_Jakob> Fixed
<Prf_Jakob> As long as you don't have any Khr OpenGL tests, as those seems to want a binary from 'external/openglcts/modules'
<Prf_Jakob> tomeu: Looks like I got everything working now. The flag/option will be --no-passed-results / noPassedResults
<tomeu> Prf_Jakob: awesome, are you going to upload a new binary?
<Prf_Jakob> Yupp
<Prf_Jakob> Tiding up the code, committing it and doing a new release
<tomeu> Prf_Jakob: btw, the tag was 0.1.1 but the tarball had 0.0.1
<Prf_Jakob> Yeah I noticed, I'll just remove the old binary.
<tomeu> let's see :) 56553
<Prf_Jakob> *crosses fingers*
<Prf_Jakob> tomeu: Ops, wrong file you tried to unpack :)
<tomeu> oops indeed
<Prf_Jakob> Woooh!
<tomeu> looks like it hung towards the end, I think there's some very slow tests
<tomeu> we were skipping them, so I have gone back to it so we can compare pears to pears
unoccupied has quit [Ping timeout: 268 seconds]
<Prf_Jakob> tomeu: It only took about 4 minutes to run the tests
<Prf_Jakob> If the timestamps are right
<tomeu> yep, and I think with more tests the gains will be bigger
<tomeu> I'm adding regressiona nalysis
<Prf_Jakob> tomeu: Don't forget the --no-passed-results :)
<Prf_Jakob> flag
<Prf_Jakob> Ah you did add it :)
<tomeu> yep, should be there
unoccupied has joined #panfrost
<tomeu> Prf_Jakob: wonder what happened here: https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/507573
<tomeu> when calculating regressions
<Prf_Jakob> Hmm not really sure
<tomeu> :: Checking for regressions.
<tomeu> Reading file /deqp/expected-failures.txt.
<tomeu> No change(s) found.
<tomeu> :: Printing changes and failing tests.
<Prf_Jakob> Hmm yeah
<tomeu> so there's no regressions but a lot of changes because all(?) tests are marked as incomplete?
<tomeu> or maybe that's all the passing tests?
<Prf_Jakob> Let me check something
<Prf_Jakob> Ooh yeah, when a test isn't listed in the file it's marked as incomplete by default
<tomeu> ok, I think I don't care about the changes, just about regressions
<Prf_Jakob> Well technically it could be seen as a fix
<Prf_Jakob> But yeah I will just ignore that
<tomeu> oh, I'm interested in treating fixes as regressions
<tomeu> Prf_Jakob: so we keep the failures list updated
<Prf_Jakob> Yea
<Prf_Jakob> But this is a case of the test not being in the regression file
<tomeu> otherwise, if it regresses later, we won't notice
<Prf_Jakob> But being run
<tomeu> yep, that's a passing test
<Prf_Jakob> But is it a "fix"?
<Prf_Jakob> That should fail?
davidlt has joined #panfrost
<Prf_Jakob> tomeu: What do you think?
<tomeu> Prf_Jakob: yep, if a test passes that we have in the failures list, it should fail the job
<tomeu> because we have a bug in the failures list :p
<Prf_Jakob> tomeu: But if it wasn't in the failure list?
<tomeu> no, that should be the normal case
davidlt_ has joined #panfrost
<tomeu> almost all tests will pass and won't be in the failures list
<Prf_Jakob> So that shouldn't be treated as a improvement?
<tomeu> Prf_Jakob: hmm, what do you mean by improvement?
<Prf_Jakob> Should it flag the test as a improvement?
<Prf_Jakob> The oposite as regression
<tomeu> a test that passes and isn't in the failures list is the normal case
<tomeu> a test that passes and is in the failures list is considered in practical terms as a regression
<tomeu> a test that fails and is in the failures list isn't reported whatsoever
davidlt has quit [Ping timeout: 272 seconds]
<tomeu> a test that fails and isn't in the failures list is a regression
<Prf_Jakob> Internally dEQP tracks, improements, regressions.
<Prf_Jakob> Having it print regression when the test improves will confuse people
<tomeu> in 2 and 4, we'd like for deqp to return an error code
<tomeu> ah, what happens currently in virgl? the CI run doesn't fail when a test starts passing unexpectedly?
<Prf_Jakob> Sure, but that's not seperate to if a test has improved or regressed.
<Prf_Jakob> but that is separate...
<tomeu> well, I don't mind much how we call it, as long as the CI run fails in 2 and 4
davidlt_ is now known as davidlt
<Prf_Jakob> Sure :)
<Prf_Jakob> Just so we get the terminology down :)
<tomeu> ah, improvement sounds great to me
<Prf_Jakob> So a test that fails and that isn't in the regression-file is just a regular failure?
<Prf_Jakob> Yah I guess
davidlt has quit [Remote host closed the connection]
davidlt has joined #panfrost
<tomeu> Prf_Jakob: yep
<tomeu> a regular regression
davidlt has quit [Read error: Connection reset by peer]
<Prf_Jakob> Oki
davidlt has joined #panfrost
davidlt has quit [Remote host closed the connection]
davidlt_ has joined #panfrost
davidlt_ has quit [Remote host closed the connection]
davidlt has joined #panfrost
<Prf_Jakob> tomeu: Also why are you catting the results file? That just spams the log, isn't it better to just use the status printing that dEQP-Volt already does?
<tomeu> Prf_Jakob: already stopped doing that, I just wanted to look at it
<tomeu> now I'm just using the return code
<Prf_Jakob> Ok cool
<alyssa> tomeu: Fair enough, yeah.
davidlt has quit [Remote host closed the connection]
davidlt has joined #panfrost
davidlt has quit [Remote host closed the connection]
davidlt has joined #panfrost
<Prf_Jakob> tomeu: Ops it's not counting the failing NotListed tests as regression let me fix that.
<tomeu> 2019-08-15T13:55:03 + [ 0 -ne 0 ]
<tomeu> 2019-08-15T13:55:03 + echo No regressions detected
<tomeu> Prf_Jakob: I thought deqp would return an error code if there's regressions or improvements?
<Prf_Jakob> tomeu: There is two parts of the code, one that counts, and one that prints :)
<Prf_Jakob> tomeu: Cheated and just updated the binary on github :)
<Prf_Jakob> tomeu: You should be able to just re run it
davidlt has quit [Ping timeout: 248 seconds]
<Prf_Jakob> tomeu: The output is captured over serial right? It looks like it actually take some time to print things to stdout.
<Prf_Jakob> Maybe we should hide the FLIP_FLOP printing as well.
<tomeu> yep, serial can be very slow
<tomeu> well, not that slow, I hope :)
* tomeu checks
<tomeu> yeah, I think it adds 1s
<tomeu> guess I could remove +x and add some logging
<tomeu> but hopefully that list of flip-flops will disappear once somebody starts caring strongly about compliance
<tomeu> Prf_Jakob: nice, this part is fixed:
<tomeu> 2019-08-15T14:23:19 + [ 1 -ne 0 ]
<tomeu> 2019-08-15T14:23:19 + echo Regressions detected
<Prf_Jakob> tomeu: Oh right, read it wrong, it adds like two seconds. Thought it added 2 minutes :p
<Prf_Jakob> But removing it would clean up the log :)
<tomeu> looks like a bunch of tests fail under this runner
<tomeu> probably due to concurrency
<Prf_Jakob> At least to me the interesting bits is the dEQP volt output
<tomeu> (and I'm using --no-rerun-tests)
<tomeu> yeah, would be cool to do that
<Prf_Jakob> Also if one test crash in a group the rest of them are not rerun
<Prf_Jakob> But I'm not seeing any bad terminate
<tomeu> ah, I see
<tomeu> robher: with 2G, I see some shrinker activity with 33 instances of glmark
<tomeu> robher: there's some possible problem with locking though: http://paste.debian.net/1095870/
<tomeu> and after a while I started getting the bad page warnings
<robher> tomeu: locking is hard... :(
<tomeu> robher: btw, what did you mean by "might need to check the page count when purging"?
<robher> tomeu: Ensuring pages_use_count is 1. I think that would be redundant, but maybe not. See drm_gem_shmem_is_purgeable().
<Prf_Jakob> tomeu: So it probably is concurrency issues
<Prf_Jakob> I really should do something about the color output as well. The log is hard to read.
<robher> tomeu: we should be able to fix the above locking issue using mutex_trylock instead in panfrost_gem_purge.
<tomeu> Prf_Jakob: we still fail those when running individually
<Prf_Jakob> tomeu: Okay, yeah they should be listed as BadTerminate then
<tomeu> Prf_Jakob: oh, why?
<tomeu> I thought they were normal failures
<Prf_Jakob> tomeu: So BadTerminate means that the deqp-runner crashed and didn't complete the tests.
<Prf_Jakob> Where as Fail means deqp-runner terminated normally but it reported failure.
JaceAlvejetti has quit [Ping timeout: 250 seconds]
JaceAlvejetti has joined #panfrost
<tomeu> Prf_Jakob: but we don't have any BadTerminates here, right?
<tomeu> we're just failing the tests, afaics
<alyssa> Anyone know of fancy macro magic so that:
<alyssa> blah(..) { ... }
<alyssa> expands to:
<alyssa> foo(..) { stmt; ... }
<alyssa> without the stmt, I can easily do
<alyssa> #define blah(..) foo(..)
<alyssa> With the statement, I'm at a loss.
* alyssa managed by expanding foo itself but gr
<Prf_Jakob> tomeu: Exactly, I just miss understood the output. :)
<tomeu> Prf_Jakob: tomorrow will run one of those tests under valgrind and see if there's anythign interesting
<alyssa> tomeu: Prf_Jakob: The Z/S tests may be legitimately failing
<alyssa> Our older CI just didn't catch it because we were rendering to a window and here I guess we're doing an FBO
<alyssa> So actually the log seems right to me
davidlt has joined #panfrost
raster has quit [Remote host closed the connection]
<alyssa> Okay, I have CFG helpers and stuff
<alyssa> so I should be able to actually do this algorithm. I think.
<alyssa> Woahhhhhhhhhhhhh
<alyssa> I'm playing with liveness analysis (done the right way) and it's
<alyssa> starting to make sense??
<robher> alyssa: I think you need (): "({ stmt; ... })"
<alyssa> robher: Hm?
<robher> alyssa: and maybe enclosed in a "do {} while(0)"
<robher> lot's of macro magic in the kernel...
<shadeslayer> 688M /tmp/log
<shadeslayer> q.q
<alyssa> Update: I got liveness analysis (the right way) working in the single block case.
<alyssa> Now for real CF..
<alyssa> The good news is that this is, like, making sense?!
<alyssa> Well, onwards, let's do this for multiblock.
adjtm has joined #panfrost
Elpaulo has joined #panfrost
<robher> tomeu: can't repro your crashes, but found 2 other bugs...
<alyssa> Success!
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
herbmilleriw has joined #panfrost
<HdkR> alyssa: hah, silly const-prop failures
stikonas has joined #panfrost
robert_ancell has joined #panfrost
<alyssa> HdkR: \shrug/
<alyssa> HdkR: So I've spent all day trying to wrap my head around liveness analysis
<alyssa> I'm kind of getting there. Maybe.
<alyssa> Loops make things hard.
<HdkR> Yea, loops can make things difficult
<alyssa> Like I've been making progress in places and improving MIR
<alyssa> 5 files changed, 99 insertions(+), 22 deletions(-)
<alyssa> of fixes checked in
<alyssa> 4 files changed, 241 insertions(+), 64 deletions(-)
<alyssa> of what I have not checked in on top of that and banging my head on
<alyssa> I'm getting a good picture of what actually needs to happen though
<alyssa> And seeing as this morning I knew next to nothing, I mean... that's the speed things happen at
herbmilleriw has quit [Remote host closed the connection]
<alyssa> Can't tell if I have a regression or I'm just colourblind
<alyssa> No defn regressions in places.
herbmilleriw has joined #panfrost
<alyssa> I'm reading the shader manually
<alyssa> and i don't see how the new compile is wrong
<alyssa> I suspect vector shenanigans
<alyssa> Vector shenanigan indeeed, uuuuuuuuuuuuuuuuuuugh
herbmilleriw has quit [Remote host closed the connection]
Depau has quit [Quit: ZNC 1.7.4 - https://znc.in]
Depau has joined #panfrost
herbmilleriw has joined #panfrost
herbmilleriw has quit [Remote host closed the connection]
herbmilleriw has joined #panfrost
stikonas has quit [Remote host closed the connection]
<alyssa> Bugs. Bugs all the way down.
<alyssa> Okay, need to fix texture ops the right way.