alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - <daniels> avoiding X is a huge feature
TheCycoONE has joined #panfrost
<hanetzer> second trig exam down
<hanetzer> one more, then the final for this semester
stikonas has quit [Remote host closed the connection]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC:]
belgin has joined #panfrost
davidlt has quit [Quit: ZNC -]
davidlt has joined #panfrost
belgin has quit [Quit: Leaving]
robert_ancell has quit [Remote host closed the connection]
ezequielg has quit [*.net *.split]
WeaselSoup has quit [*.net *.split]
maciejjo has quit [*.net *.split]
nickolas360 has quit [*.net *.split]
cyrozap has quit [*.net *.split]
<alyssa> A few more things I want to do before I'm happy enough to send it off to the ML, but I spent the evening working on a series of refactors relating to framebuffers
maciejjo has joined #panfrost
nickolas360 has joined #panfrost
WeaselSoup has joined #panfrost
ezequielg has joined #panfrost
cyrozap has joined #panfrost
<tomeu> chewitt, robher: indeed, I missed a little -a...
<tomeu> chewitt: btw, I haven't been ignoring your questions, but you have never been online at the same time as me before :)
<chewitt> no worries .. I travelling a lot with work at the moment so not online a lot
<tomeu> alyssa: please tell me if I can help with the BO refactor in mesa
<alyssa> tomeu: Focus on the kernel stuff, I can handle pure-userspace ;P
<alyssa> (Sorry, that came off rude. Sentiment being, you're needed on kernel, don't get distracted by my shenanigans? :P)
<tomeu> np :)
<alyssa> tomeu: While I have your attn though -- do you have a preference on merging the earlier parts of the DRM series (the prep stuff that doesn't touch the kernel abstraction yet)? It might ease your load a bit and I don't see a reasont o delay it, but maybe you wanted to keep the series coherent
<tomeu> alyssa: that would be great, though there might be some feedback that I needed to address?
<alyssa> I think the first few I just R-b'd as is
<tomeu> there's good stuff in panfrost/framebuffer-bits
<tomeu> alyssa: can you push them as they are, or better to have them in a MR?
<alyssa> tomeu: That's my BO refactor WIP; I'm sending it off when it's, you know, ready :P
<alyssa> ("Alyssa, why are you still awake? :V")
jernej has joined #panfrost
<tomeu> robher: the rebase is looking good, I'm testing now
jolan has joined #panfrost
adjtm_ has quit [Remote host closed the connection]
adjtm_ has joined #panfrost
pH5 has quit [Quit: bye]
raster has joined #panfrost
pH5 has joined #panfrost
BenG83 has quit [Quit: Leaving]
raster has quit [Remote host closed the connection]
Marex has quit [Ping timeout: 259 seconds]
chewitt has quit [Quit: Zzz..]
_whitelogger has joined #panfrost
chewitt has joined #panfrost
chewitt has quit [Quit: Zzz..]
raster has joined #panfrost
chewitt has joined #panfrost
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
raster has quit [Remote host closed the connection]
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
<tomeu> alyssa: oh, I think there was a misunderstanding, I asked you about pushing those patches from me that have already a r-b
<tomeu> not your WIP branch :)
chewitt has quit [Client Quit]
afaerber has quit [Quit: Leaving]
afaerber has joined #panfrost
BenG83 has joined #panfrost
<alyssa> tomeu: Oh, gotcha
<tomeu> alyssa: with the DRM driver, I'm getting DATA_INVALID_FAULT in the job dispatcher irq when a frame is submitted due to a flush when the context gets destroyed
<tomeu> but that doesn't happen with kbase
<alyssa> Hint: all of all flushing logic is deeply flawed. All of it.
<tomeu> do you have any ideas?
<alyssa> :P
<alyssa> tomeu: Why are we flushing on context destroy? Like, is that also the case on kbase?
<tomeu> well, by flushing I mean that the gallium pipe_flush cb gets called
<alyssa> (Aside: DATA_INVALID_FAULT is the most common -- and annoying -- to deal with it...)
<tomeu> guess we could just not submit any jobs on pipe_flush based on what flags are passed
<alyssa> tomeu: That's sort of the hack we're doing with kbase as it is
<tomeu> but I would like to know why with kbase we don't get any faults logged
<alyssa> Quick question, this "extra" flush, are there any draws?
<tomeu> that's what I wanted to check next :)
<alyssa> :)
<alyssa> Since I think there have been historical bugs for test-clear type jobs
<alyssa> Aside: I should've mentioned the motivation for the last night's patch series
<alyssa> All of this is a very long-winded build up to slimming down set_framebuffer_state
<alyssa> In particular, rather than converting a linear/tiled BO into AFBC, at BO creation time we decide the layout depending on the usage flags (which also fixes the memory leak thing you mentioned..?)
<alyssa> Also, just as a sanity check, I'd like to test rendering and sampling from linear render targets
<tomeu> yeah, I'm all for refactoring that stuff
<alyssa> Obviously that already works conceptually (Weston does that across processes) but we don't have any tests for that for FBOs
<tomeu> no draws on context destruction, btw
<alyssa> tomeu: Alright, let me look at your code closer then
<tomeu> but I do get some frames submitted on context creation with no draws and no JS faults
<tomeu> so I guess
<tomeu> it's not a simple problem with job dependencies
<alyssa> I recall getting faults when there were no draws and no clears and just nothing
<alyssa> Which is why for a while I inserted a bunch of dummy clears
<alyssa> Which was so egregiously wrong but for some reason it helped :P
<tomeu> hmm, maybe the job descriptor was "too empty"?
<alyssa> Yeah
<alyssa> If such a hack really is necessary, it can now be done non-invasively in whatchamacallit
<alyssa> clear_mfbd or one of those
<tomeu> but then, I don't know why with kbase we don't get that fault
<alyssa> (The one that actually does, like, "fragment_rts[0]->clear_color_1 = job->clear_color"
<alyssa> kbase, I think, had a "frame cleared?" flag that we check for; maybe you removed that...?
<tomeu> checking
<tomeu> cannot find anything related to that
<tomeu> but I see this in panfrost_flush:
<tomeu> /* Nothing to do! */
<tomeu> if (!ctx->draw_count && !job->clear) return;
<tomeu> hmm, job->clear is forever ever 5
<tomeu> alyssa: this avoids the problem, but I don't know if is correct, and I still would like to know what I don't get those faults with kbase :/
<alyssa> tomeu: job->clear... should be getting cleared every frame.. anyway?
<alyssa> panfrost_job is supposed to be reset after every frame
* alyssa poofs, school
pH5 has quit [Quit: bye]
pH5 has joined #panfrost
raster has joined #panfrost
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
BenG83 has quit [Quit: Leaving]
raster has quit [Read error: Connection reset by peer]
afaerber has quit [Remote host closed the connection]
<davidlt> GraphicsFuzz is the 3D GPU driver fuzzer that was born out of academia research for finding GPU driver bugs and ended up being acquired by Google and then open-sourced.
BenG83 has joined #panfrost
robert_ancell has joined #panfrost
belgin has joined #panfrost
<HdkR> Interestingly the mesa-dev email about that project went directly to my spam folder
<hanetzer> davidlt: ooh, kewl
belgin has quit [Quit: Leaving]
afaerber has joined #panfrost
<alyssa> davidlt: GPU drivers are chockful of security bugs IME
<alyssa> Which is why WebGL is such an awful idea tbh
<HdkR> WHLSL and WebGPU to save the day!
<HdkR> :P
* alyssa blinks
<alyssa> I think that's worse, dear
<alyssa> :P
<alyssa> ("Read in mom voice")
<hanetzer> wew, we goawt kernel 5.0