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
davidlt has quit [Ping timeout: 244 seconds]
davidlt has joined #panfrost
davidlt has quit [Ping timeout: 272 seconds]
_whitelogger has joined #panfrost
davidlt has joined #panfrost
megi has quit [Ping timeout: 272 seconds]
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
indy has joined #panfrost
_whitelogger has joined #panfrost
Elpaulo has joined #panfrost
davidlt has quit [Ping timeout: 246 seconds]
chewitt has joined #panfrost
<cwabbott> alyssa: you shouldn't need "defs" and "uses" sets, what you do to figure out interference is: walk the instructions in the block backwards with a temporary liveness set to keep track of liveness, exactly as if you're computing live_in from live_out
<cwabbott> right before you visit each instruction, the temporary set will have all the registers live right after that instruction
<cwabbott> now mark all those registers live right after the instruction as interfering with the register(s) written by the instruction
<cwabbott> the idea is that if two registers interfere, one has to be written while the other is live
<cwabbott> since it's "overwriting a register that's may be used later" that you want to avoid in the first place
NeuroScr has quit [Quit: NeuroScr]
adjtm_ has quit [Ping timeout: 272 seconds]
somy has quit [Quit: Leaving...]
raster has joined #panfrost
cwabbott has quit [Quit: cwabbott]
adjtm_ has joined #panfrost
megi has joined #panfrost
jernej has quit [Read error: Connection reset by peer]
jernej has joined #panfrost
cwabbott has joined #panfrost
davidlt has joined #panfrost
chewitt has quit [Read error: Connection reset by peer]
davidlt has quit [Remote host closed the connection]
davidlt has joined #panfrost
davidlt has quit [Remote host closed the connection]
davidlt has joined #panfrost
davidlt_ has joined #panfrost
<tomeu> robher: I'm getting these errors with your madvise patches: http://paste.debian.net/1095740/
<tomeu> (booting with mem=512m)
davidlt has quit [Ping timeout: 245 seconds]
chewitt has joined #panfrost
adjtm_ has quit [Ping timeout: 245 seconds]
megi has quit [Ping timeout: 248 seconds]
davidlt_ has quit [Read error: Connection reset by peer]
davidlt__ has joined #panfrost
davidlt__ has quit [Remote host closed the connection]
alyssa has quit [Ping timeout: 248 seconds]
adjtm_ has joined #panfrost
jolan has quit [Quit: leaving]
afaerber has quit [Quit: Leaving]
jolan has joined #panfrost
alyssa has joined #panfrost
<shadeslayer> so I'm trying to figure out a way to dump what kind of BO was requested in panfrost, but I don't see a way to infer that ?
<shadeslayer> at least not in Panfrost itself
<alyssa> bbrezillon: I just bisected a regression GALLIUM_HUD
<alyssa> The culprit was cso->normalized_coords=false for the HUD, but needing to set the NORM_COORDS flag in the hw anyway
<alyssa> Any idea where the discrepency is from?
<alyssa> Is this a bug in GALLIUM_HUD?
<alyssa> Or maybe RECT textures?
megi has joined #panfrost
<shadeslayer> alyssa: ^^ got any pointers?
<alyssa> shadeslayer: Mm, try with PAN_MESA_DEBUG=trace and dumping the bo->gpu pointer, and matching that GPU pointer to a pointer in the trace?
davidlt has joined #panfrost
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
<robher> tomeu: might need to check the page count when purging. OOO this morning.
<alyssa> tomeu: bbrezillon: 6bb4b6d07816eb116dd07884b4f593916e3daf88 looks super interesting
<alyssa> I wonder if we want something like that in frost
<shadeslayer> oooh, that does look cool
<shadeslayer> alyssa: re pan trace, thanks for the pointer, I'll take a look
<shadeslayer> don't have access to the device right now though
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
<shadeslayer> alyssa: FWIW I think these TODO's can all be eliminated? http://paste.ubuntu.com/p/6MQyzc8GZT/
<shadeslayer> robher: is there a way to get the flags a BO was created with from the kernel when importing it via the PRIME fd?
<shadeslayer> I can't really seem to find anything that would allow me to do that
<alyssa> shadeslayer: Mmyeah
<shadeslayer> alyssa: huzzah
<alyssa> :)
<shadeslayer> or am I on the wrong track?
<alyssa> shadeslayer: Yes, I think that's right
<shadeslayer> alyssa: ok, then I just have to figure out how to get the flags I suppose
<alyssa> Remove the mmap there, and add mmap_bo call(s) where we actually need the map
<alyssa> No flags needed :)
<shadeslayer> oh
<shadeslayer> heh ok
<shadeslayer> alyssa: how do I figure out where the mmap_bo calls are needed 0.o
<alyssa> shadeslayer: I think we already handle them, uhhhh
<alyssa> Try getting rid of those two lines and seing ifa nything breaks? :innocent:
<shadeslayer> lol ok
<shadeslayer> I guess I need to head home to try this patch and dump the traces then
<shadeslayer> I didn't see a malloc in that function, so that comment befuddled me
<alyssa> shadeslayer: That whole function *is* a malloc
<alyssa> (Except for the memcpy line)
<alyssa> pan_allocate.c implements memory allocators, albeit terrible ones.
<alyssa> I thought tomeu fixed this tho
marvs has joined #panfrost
<shadeslayer> alyssa: I wonder if https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/panfrost/pan_allocate.c#L122-124 might also be causing that double unreference crash, but that's just a shot in the dark
<alyssa> shadeslayer: It's... possible?
<alyssa> Conceptually, in that {...} chain we're creating 2 references and then removing one, netting 1 reference reamining
<alyssa> Ohhhhhh, huh hm hrm
<alyssa> Okay no uh
<alyssa> shadeslayer: I think you're definitely on the right track, hold on
<shadeslayer> alyssa: yeah I'm just missing parts of the picture to connect it all together
<shadeslayer> it seems like a likely cause, but I'm not sure how to connect it to the crash :P
<alyssa> shadeslayer: See the `refcnt` branch I just dumped to CI
<alyssa> Totally untested :p
<shadeslayer> hah
<shadeslayer> I mean, makes sense logically
<alyssa> shadeslayer: Assuming that was it, yeah, this is what happens when sw evolves organically :p
<shadeslayer> alyssa: I'll test it out when I'm home :)
<alyssa> When that reference_init line was added, it made sense! ..But then the BO cache was added and we forgot about poor reference_init
<alyssa> Oh wait, nope very broken
<alyssa> Hrm
<shadeslayer> Isn't all software grown organically in software greenhouses?
<alyssa> lmark2-es2-wayland: ../src/gallium/auxiliary/util/u_inlines.h
<alyssa> :81: pipe_reference_described: Assertion `count != 1' failed.
<shadeslayer> aw
raster has quit [Remote host closed the connection]
<alyssa> Anyway, it's probably something of that ilk
<shadeslayer> alyssa: I'll investigate :)
<alyssa> :+1:
<shadeslayer> good to know I'm on the right track :)
<alyssa> shadeslayer: Maybe disable the BO cache and see if the bug goes away
<shadeslayer> alyssa: btw dEQP doesn't do testing for prime handle imports does it?
chewitt has quit [Quit: Adios!]
adjtm_ has quit [Quit: Leaving]
<alyssa> shadeslayer: Not the tests our CI runs, no.
<alyssa> Well, it'll happen indirectly through weston but not deliberate tests
stikonas has joined #panfrost
<shadeslayer> Ok
<alyssa> HdkR: I'm going to pull your Bifrost compiler (circa May), rebase it against latest master, clean up what I can so it fits with the midgard stack, and push it in tree, bwap?
<alyssa> I have quite a bit of shuffling to do (tree has changed a lot this summer) but I'm feeling hopeful
<Lyude> you planning on working on bifrost? :)
<HdkR> alyssa: Coolio
<alyssa> HdkR: Can I get your Signed-off-by for the code in the bifrost/ folder?
<HdkR> Sure. You can have it
<alyssa> Very formal. :P
<HdkR> :)
<alyssa> HdkR: BTW, what state did you leave this in?
<alyssa> Or is that going to be a fun "surprise" for me?
<HdkR> Probably some memory leaks but last I knew it was doing NIR->MIR for some basic shaders
<HdkR> smidge of RA
<HdkR> There was some RA bug somewhere I do recall
<alyssa> All RA is buggy, next question ;)
<HdkR> I was messing with uniforms and UBOs, which I don't believe I fully implemented
<alyssa> So a fun surprise I guess :)
<HdkR> There is no bundler + emitter either :P
<alyssa> Delightful, okay
<alyssa> Lyude: Based on what you said at XDC, whoever takes this up is in for a wild ride, huh? :P
<Lyude> yeah
<Lyude> i mean
<Lyude> while bifrost has some kinda crazy stuff at least it makes sense for the most part :)
<HdkR> `// XXX: Doesn't support duplicated values in the components! // RA WILL fail!` Oh hey, there's that bug
<alyssa> What does that mean :/
<HdkR> emit_create_vector function, just takes ssa scalar components to create a vector of them, if you do something where you want to broadcast a scalar across a vector than RA fails to operate correctly :P
<HdkR> Each scalar needs to be unique in that one and I just didn't fix it
<alyssa> Ahh, yeah, ok
<HdkR> Basically search for XXX: in the source and that finds most random things I hit and didn't fix
<alyssa> HdkR: I'm stuck in Midgard brain mode so
<alyssa> Scalar arch is .. different :)
<HdkR> :D
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<alyssa> ...Okay, let's do that....
<HdkR> ellipses
<alyssa> paraboloids
<alyssa> "I'm gay as a paraboloid" -Rarity
NeuroScr has joined #panfrost
krh has joined #panfrost
<daniels> alyssa, tomeu, shadeslayer: it seems like the v3d BO-labelling is also something which would be really useful
<alyssa> daniels: Oh! Yeah, I didn't think about that
<alyssa> shadeslayer: ^^ You up for it :)
<alyssa> ?
raster has joined #panfrost
stikonas has quit [Read error: Connection reset by peer]
stikonas has joined #panfrost
<shadeslayer> alyssa: sure why not :)
JaceAlvejetti_ has quit [Ping timeout: 264 seconds]
<shadeslayer> seems like we can drop that mmap
<shadeslayer> alyssa: I'll put it on my TODO, I should be able to get started on it by Friday as long as I can get the refcnt issue sorted tomorrow
<shadeslayer> which I /think/ is doable
<shadeslayer> and then I want to look at cubemap arrays :)
<alyssa> Wherefore?
<shadeslayer> cubemap arrays? I saw a todo ...
<alyssa> It's ES3.2 functionality; that's why it's TODO :p
<shadeslayer> oh, bugger it then :P
stikonas has quit [Ping timeout: 244 seconds]
<shadeslayer> not sure why I added it then, I vaguely recall seeing it was added in version 1.x , but my eyes must have tricked me then
<alyssa> But if that's what it takes to get people to do things
<alyssa> /* TODO: vulkan driver */
<alyssa> /* TODO: opencl */
<shadeslayer> lol
<alyssa> /* TODO: take out my laundry -a */
<shadeslayer> ah that's the hardest one
<HdkR> alyssa: Isn't cube maps a very early GL feature though?
<shadeslayer> ah I think I got it confused with https://www.khronos.org/opengl/wiki/Cubemap_Texture
<HdkR> Or is this the seamless versus non-seamless thing?
<alyssa> HdkR: We support cubemaps (GLES2.0)
<alyssa> and seamless cubemaps (GLES3.0)
<alyssa> but not arrays of cubemaps (GLES3.2)
<HdkR> ah, arrays alright
<HdkR> Arrays are madness anyway
<alyssa> HdkR: cwabbott: FWIW, I just rewrote half of panwrap (again)
<alyssa> We're back to direct tracing like the good ol' days, except now there is some disturbing voodoo to link with internal build files in Mesa. Don't.. think about it too much...
<HdkR> The more times it is rewritten the better it gets :D
<alyssa> The upshot is that all the tracing is upstream in Mesa, and the kbase code out-of-tree is very thin and just as fast/reliable as the native tracing
<alyssa> (Since now it uses the same code as the native tracing)
<alyssa> Also I added a readme
stikonas has joined #panfrost
<alyssa> Blob isn't making any sense
<alyssa> For normalize(), normally that compiles to just, frcp/fmul, right?
<alyssa> But sometimes -- I can't figure out when; I've been trying to isolate the offending code sequence -- it becomes
<alyssa> ld_comptue_id 1.xyz, 0.xyzx, /* 0 */
<alyssa> (That might be negated from what it should be but conceptually)
<alyssa> Specifically I think that's loading the varying normalized
<alyssa> But again, I don't have a way to confirm this reliably
<alyssa> Since when I try to isolate the code, the blob switches back to ALU
<alyssa> Possibly the substitution happens at the 11th hour when all scheduling information is present (to take pressure off the ALU pipe and balance onto the L/S pipe, for ALU-heavy shaders)
<robher> tomeu: I can'
<robher> tomeu: I can't reproduce that. I can make things grind to a halt with 512M (plus swap) and Gnome Shell.
<robher> tomeu: Maybe something 32-bit specific or you have some page alloc debug on?
<robher> I only saw 'bad page state' if I left BO's mmapped.
<alyssa> Ohhhhhhhhhhhhhhhh
<alyssa> bbrezillon: Derp.
<alyssa> I think we have native RECT texture support :)
<HdkR> :D
* alyssa feels dumb for not making the connections ooner
<alyssa> Yup.
<alyssa> Here we go, native RECT texture on Panfrost
<alyssa> isn't that cute.
stikonas has quit [Read error: Connection reset by peer]
stikonas_ has joined #panfrost
<HdkR> alyssa: Texture op can just ingest [0, <dim>] coordinates?
<alyssa> HdkR: Yea
<HdkR> That's pretty cute
<alyssa> HdkR: There's a flag on the sampler to decide whether coords are normalized or not
<HdkR> :D
<alyssa> (Used in CL)
<HdkR> Makes sense
<HdkR> Gives you free GL rect though
<HdkR> Otherwise you would have to do the normalization dance and pass in dimensions as uniform
<HdkR> (Unless you have a dedicated dimension info op)
<alyssa> HdkR: That's the dance we did
<alyssa> I just deleted all of that code and just let RECT go native and it's fine
<HdkR> yay
<alyssa> bbrezillon: FWIW, the work you did was still super helpful since we need it for textureSize() :)
<alyssa> tomeu: Job's log exceeded limit of 16777216 bytes.
<alyssa> ^ This has been happening sporadically
JaceAlvejetti has joined #panfrost
raster has quit [Remote host closed the connection]
stikonas_ has quit [Remote host closed the connection]
<alyssa> cwabbott: Thank you for the pointers on liveness analysis, btw :)
* alyssa reads more about data flow, it's start to sink in
<HdkR> The data flow information is flowing in to your brain
<alyssa> HdkR: Zeep zorp.
<alyssa> HdkR: I'm also starting to get just how terribly inefficient my old code was :p
<alyssa> Like I knew it was bad, but dang
<HdkR> Time to rewrite the world again? :D
<alyssa> HdkR: Probably