<tomeu>
alyssa: just setting 0x608d to tiler_flags doesn't reproduce the GPU hang here
<tomeu>
wonder why it did hang there yesterday, when run in a loop
<tomeu>
maybe I shouldn't be fuzzy testing hardware :p
<anarsoul>
tomeu: yeah, it's not a good idea
<tomeu>
anarsoul: what's the concern?
<anarsoul>
I'm not sure about midgard, but if you wedge gpu in utgard with some weird shader or any bizzarities in command stream it recovers only after reset
<tomeu>
oh, that's exactly what I want
<tomeu>
but I get DATA_INVALID_FAULT and things keep working without a reset :/
<anarsoul>
want to wedge gpu? just set wrong type of next instruction in shader :)
<tomeu>
I need it for a test in IGT that checks that reset correctly recovers the driver after a hang
<anarsoul>
it reliably wedges utgard
<tomeu>
I don't have a compiler in IGT :)
<tomeu>
only a clear job
<anarsoul>
use precompiled blob?
<tomeu>
guess I could, but would be great if I could cause the hang by just flipping some bits in the cmd stream
<tomeu>
shadeslayer: I'm writing a value to the memory region pointed to by unknown_address_2
<tomeu>
no idea of why
<tomeu>
but gets things working :)
<shadeslayer[m]>
So weird
<tomeu>
guess it's the problem with so many layers of unknowns :)
stikonas has joined #panfrost
jolan has quit [Quit: leaving]
<alyssa>
anarsoul: Midgard has very good fault recovery. If you mess up cmdstream, DATA_INVALID_FAULT. If you mess up shader, say, next type/tag: INSTR_something_FAULT. Immediate recovery.
<alyssa>
We're looking for some brokeno chickenbit that legitimately hangs the thing (for kernel test purposes), not just faults it
afaerber has quit [Quit: Leaving]
raster has joined #panfrost
jolan has joined #panfrost
<shadeslayer[m]>
alyssa: re "panfrost/midgard: Move requirement setting into panfrost_job"
<shadeslayer[m]>
I took a look at other drivers, and they all did their requirement setting when getting the fbo
<shadeslayer[m]>
I think I discussed it with tomeu over here
<shadeslayer[m]>
so if you look at what vc4 and v3d do, the call chain looks like : get_job_for_fbo -> get_job -> set msaa stuff
<alyssa>
Sure :)
<shadeslayer[m]>
\o/
<tomeu>
I'm not particularly fond of panfrost_job_set_requirements() though
<tomeu>
has a bit of a bad smell because of not having arguments
<shadeslayer[m]>
it takes a context and a job?
<tomeu>
well, the context is the caller and the job is the instance getting the "method"
<tomeu>
so the context is basically poking the job and telling it "now it's the moment to figure out your requirements"
<tomeu>
would be cool I think if the job was able to figure out when to do that by itself
<tomeu>
if job creation is too early, what about on first call, or on flush?
<shadeslayer[m]>
hm, maybe it should be a private method
<shadeslayer[m]>
so you can't call it from outside panfrost_job
<tomeu>
well, it probably doesn't even need its own function
<shadeslayer[m]>
<tomeu "well, the context is the caller "> actually, we call it from inside panfrost_get_job
<tomeu>
ah, that's cool
<shadeslayer[m]>
I mean, at the moment, yes, and perhaps I prematurely optimized this
<tomeu>
yeah, I'm a bit concerned about a getter changing state though
<tomeu>
other than lazily creating an instance
<tomeu>
afaics, job->requirements is needed only when creating the framebuffer descriptors
<shadeslayer[m]>
hmmm ... I mean it's not really a strong argument, but clearly v3d and vc4 do the same
<tomeu>
isn't v3d accessing depth.writemask at v3d_draw_vbo?
<tomeu>
currently, in panfrost we need those values only at flush time, when creating the fragment job
<tomeu>
so just set the requirements field at flush/submit time?
<tomeu>
so in panfrost_job_submit
<tomeu>
though maybe the requirements field isn't needed at all?
<tomeu>
shadeslayer: sorry if I'm having trouble making my point across, I always find it hard to justify my sense of code smell :)
<shadeslayer[m]>
<tomeu "shadeslayer: sorry if I'm having"> It's alright, you could very well be correct since my reasoning is essentially that other drivers did it here
<shadeslayer[m]>
I have very large holes in my knowledge of mesa right now and the only way to fill them is by writing patches ;)
<tomeu>
well, I'm more concerned about having a panfrost_job_set_requirements(), not as much where the requirements field is set
<shadeslayer[m]>
yep, I do understand your concern
<shadeslayer[m]>
I'll just need to figure out a better way to do it :)
<tomeu>
why not just move the code that sets job->requirements to panfrost_job_submit()?
<tomeu>
and move to the enxt thing :)
<shadeslayer[m]>
<tomeu "why not just move the code that "> yeah should be fine, everything that accesses job->requirements sits inside panfrost_job_submit
<shadeslayer[m]>
so we could move it in there, sure
<shadeslayer[m]>
tomeu: done :)
<shadeslayer[m]>
and now it recompiles everything q.q
jernej has joined #panfrost
<shadeslayer[m]>
ugh cleaning this up is going to be messy
<shadeslayer[m]>
../src/gallium/drivers/panfrost/bifrost/disassemble.c:2198:48: error: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'uint64_t' {aka 'long long unsigned int'} [-Werror=format=]
raster has joined #panfrost
<daniels>
shadeslayer[m]: it's awkward in C - you want to do something like printf("this format string needs a macro - uint64_t is " PRIu64 "\n", (uint64_t) 0xdeadbeefdeadbeef);
BenG83 has joined #panfrost
<shadeslayer[m]>
daniels: I think c7a6e0745481ea99d6f02b8b8dc348ba85c105f4 fixed it
raster has quit [Remote host closed the connection]
<shadeslayer[m]>
mesa on refactor/panfrost_job [⇕$?] took 16s
<shadeslayer[m]>
don't even know how that happened
<shadeslayer[m]>
I mean, I know where it comes from, not sure how it got there
<daniels>
shadeslayer[m]: btw, in the patch series you sent to the list, patch 9/9 shouldn't be 'fixing' earlier patches in the same series
<daniels>
shadeslayer[m]: if that happens, please use git rebase -i to squash the two commits together, so that each intermediate commit works properly and doesn't regress anything
<daniels>
that way it's much easier to review the commits individually, and it also makes it possible to apply individual commits from the series whilst you wait for others to be changed
<shadeslayer[m]>
<daniels "that way it's much easier to rev"> Yeah alyssa already mentioned that :)
<shadeslayer[m]>
I'll send another revision tomorrow because I think I need to go in and change a whole bunch of stuff
<shadeslayer[m]>
wrt the history
<shadeslayer[m]>
tomeu: de5c8829732d broke my build because I nuked vertex_jobs and tiler_jobs :(
pH5 has quit [Quit: bye]
yann has quit [Ping timeout: 245 seconds]
<alyssa>
tomeu: MSAA/depth mask can prolly change across draws, so the one at the end of the frame/flush isn't necessarily valid
pH5 has joined #panfrost
<shadeslayer[m]>
alyssa: is there some sort of flow chart that explains this chain of calls?
stikonas has quit [Quit: Konversation terminated!]
stikonas_ has joined #panfrost
stikonas_ is now known as stikonas
<alyssa>
shadeslayer[m]: :/ Why would you think we have documentation?
<alyssa>
=P
<alyssa>
But... no, I can't there is :(
<shadeslayer[m]>
:(
<alyssa>
Sorry :(
<shadeslayer[m]>
alyssa: maybe start dumping your brain into docs? :P
<alyssa>
Weeelellll I'm starting to get misc_0 tamed
<alyssa>
Somehow
buzzmarshall has quit [Quit: Leaving]
montjoie has quit [Quit: Lost terminal]
_whitelogger has joined #panfrost
yann has joined #panfrost
buzzmarshall has joined #panfrost
davidlt has quit [Ping timeout: 244 seconds]
afaerber has quit [Quit: Leaving]
raster has joined #panfrost
pH5 has quit [Quit: -_-]
raster has quit [Remote host closed the connection]