alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - <daniels> avoiding X is a huge feature
<alyssa> BTW, I'm taking a break from Panfrost for a little while to let myself recharge and work on not-code
<alyssa> (Starting yesterday, as you can probably tell -- ending TBD, we'll see!)
<HdkR> woo
stikonas has quit [Remote host closed the connection]
<tomeu> alyssa: hope you have a great break :)
<tomeu> alyssa: indeed -brefract doesn't work, I get a bunch of JS faults
<tomeu> alyssa: what's the problem you see with that?
<tomeu> alyssa: thanks for pointing me to the on list patches, I will rebase on top of them and see how to push them forward
<alyssa> tomeu: Why -brefract doesn't work...? Hm
<alyssa> Well, I don't know your setup but the unique thing about that (compared to simpler tests) is that it renders to a depth-only framebuffer, i.e. there is no cbufs[0], but there is a zbuf BO you want to bind to
<alyssa> Also, lots of flushing shenanigans that you'll need to deal with (re fencing)
<alyssa> Also, AFBC?
<tomeu> ah, ok
<tomeu> ah, I see
<tomeu> regarding AFBC, do I need to do anything else at submit time besides BASE_JD_REQ_FS_AFBC?
<tomeu> I have checked, and apparently BASE_JD_REQ_FS_AFBC is only used for a workaround for t6xx
<tomeu> regarding zbuf, I guess I should be adding a fence to them, though atm I don't think anybody would wait on it
<tomeu> (only the fb driver waits on those fences atm)
<tomeu> alyssa: one more question: do you also see the horse's rotation pausing at regular times on the very first scene?
<alyssa> tomeu: I don't know re AFBC, I haven't looked at how that happens in the kernel. Make sure you're using the right BO if that's a thing your driver cares about? There are *multiple* BOs in use for an AFBC surface, iirc
<alyssa> tomeu: The fencing issue re zsbuf is, like.... Okay, we render to a depth FBO, and then we render to the screen texturing from that depth FBO. Before we can render from the screen, we have to finish rendering from the depth FBO; this is expressed by a fence / pre_dep / etc. Otherwise there's a read/write race condition
<alyssa> I don't know how fences work in mainline DRM to tell you how to handle that, but see how other drives handle FBOs
<alyssa> tomeu: Depends how you start the first scene
<alyssa> If it's just "glmark2-es2-drm" with nothing else, yeah, it switches the scene a few times stuttering in the middle
<alyssa> Specify it directly as "glmark2-es2-drm -bbuild" and it should not have that issue
<tomeu> ah, cool, then it's not a regression in the dRM driver :)
<tomeu> I think that, right now, dependencies between the depth and screen phases are being taken care of by the pre_dep fences
<alyssa> Alright..
<alyssa> tomeu: Could you get a pantrace?
<alyssa> I don't know if your mesa is new enough for that capability, but
<tomeu> but yeah, I guess it could happen that a texture comes from the video decoder, and drm/panfrost should be waiting on it before starting the job that samples from it
<tomeu> I rebase it often, are there instructions somewhere?
<alyssa> Uhhhh
<alyssa> tomeu: Set the environment variable PANTRACE_BASE to some folder
<alyssa> And then memory will get dumped there
<alyssa> And you can then do `pandecode $PANTRACE_BASE` to get the equivalent of a panwrap
<alyssa> This ought to work regardless of kernel
<alyssa> (Should be easier to get working with kmscube first, of course)
<tomeu> will try now
<tomeu> alyssa: traces/control.log is always empty here, could it be because I'm terminating the process before it can exist by itself?
<alyssa> That, or maybe I'm calling the trace callback from within nondrm, I forget
<tomeu> np, will debug
<alyssa> tomeu: Yeah, I think you need to add the callbacks to pan_drm
<alyssa> Where are these callbacks anyway
<alyssa> Oh, lovely, I never pushed the code for the callbacks. D'oh
<alyssa> tomeu: See the `traced` branch on panfrost-nondrm for what it looks like
<alyssa> Keep in mind this probably breaks on FBOs since I need to duplicate memory still but it's a start..?
<tomeu> alyssa: looks good!
<tomeu> hmm, maybe I should look at taking into account the extra_flags passed to allocate_slab...
<alyssa> tomeu: Mayhaps :P
<urjaman> alyssa: i assume you missed this ?
shenghaoyang has joined #panfrost
<tomeu> alyssa: pantrace is looking great!
<tomeu> anarsoul: isn't lima able to run weston yet?
_whitelogger has joined #panfrost
bbrezillon has joined #panfrost
pH5 has quit [Quit: bye]
paulk-leonov has joined #panfrost
BenG83 has joined #panfrost
raster has joined #panfrost
afaerber has quit [Quit: Leaving]
paulk-leonov has quit [Ping timeout: 240 seconds]
shenghaoyang has quit [Remote host closed the connection]
paulk-leonov has joined #panfrost
afaerber has joined #panfrost
Elpaulo has quit [Quit: Elpaulo]
Elpaulo has joined #panfrost
pH5 has joined #panfrost
<alyssa> tomeu: \o/
<tomeu> alyssa: have picked up the pending patches from mesa-dev and have pushed them to my branch here:
<tomeu> along with the patches to disable buffer_age
<tomeu> that's what I'm testing with
<alyssa> :+1;
<tomeu> don't think I will have time today, so on monday I will start sending patches to the ml for others to comment on
* alyssa forgot it's Friday.. :P
<tomeu> :)
jolan has quit [Quit: leaving]
pH5 has quit [Ping timeout: 245 seconds]
BenG83 has quit [Read error: Connection reset by peer]
pH5 has joined #panfrost
BenG83 has joined #panfrost
stikonas has joined #panfrost
afaerber has quit [Quit: Leaving]
jolan has joined #panfrost
raster has quit [Read error: Connection reset by peer]
BenG83 has quit [Quit: Leaving]
belgin has joined #panfrost
belgin has quit [Quit: Leaving]
afaerber has joined #panfrost
_whitelogger has quit [*.net *.split]
_whitelogger has joined #panfrost