alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - <daniels> avoiding X is a huge feature
<alyssa> (Don't worry about it ;P)
<alyssa> Hint: we deliberately pagefault. A lot. :)
<alyssa> (Obviously you haven't set it up that way. I might write the patch for that since I want to kernel at _some_ point but I dunno, yanno?)
rellla has quit [Ping timeout: 246 seconds]
rellla has joined #panfrost
* alyssa pokes at blob
<anarsoul> alyssa: and midgard can recover after page fault?
<alyssa> anarsoul: Oh, it has to :)
<alyssa> Don't think about it too much ^_^
<anarsoul> I'm just curious
<robher> alyssa: why do we need to handle page faults beyond recover from userspace bugs? It only matters for memory usage if we have swap AIUI.
stikonas has quit [Read error: Connection reset by peer]
<alyssa> robher: The vendor kernel supports "GROW_ON_GPF", which tl;dr means "We reserve a huge amount of memory upfront but don't actually allocate/commit it. Then whenever we get a page fault in the region, we expand the actual commited parts by enough pages, and then try again."
<alyssa> Used when reserving memory for hardware-internal-use for obvious reasons
<alyssa> AFAICT, right now you're just ignoring the flag and committing a 128MB tiler heap up front, for instance
<robher> I don't think that's how the drm drivers work.
<robher> I don't allocate any memory other than page tables for the hardware.
<robher> alyssa: We pin and map memory when BO are created (or imported). We could pin and map on demand, but without swap that doesn't buy anything.
<alyssa> robher: Hm? I mean, userspace is able to create a BO with the GROW_ON_GPF flag, which does the above behaviour
<alyssa> Without the flag, allocating the tiler heap means an 128MB increase in memory usage
<alyssa> With it, allocating it means a... 4K increase in memory usage, which will increase over the lifetime of the app on an as-needed basis
<alyssa> It's implemented in the kernel, but practically, it's needed by the hw I think..?
<alyssa> (Like, not "needed", but... the hw architecture means this is the only sane approach)
<robher> alyssa: Ah, okay. There's probably a couple of ways to implement that. I think intel drv can take multiple BO and map them virtually contiguous.
<alyssa> robher: Alright... that said, this is supposed to be totally transparent to userspace
<alyssa> If the kernel internally has to split up into multiple BOs (and map in the page fault handler), well, okay. But neither userspace nor hw should need to know these details
<alyssa> Aside: I'm looking at rendertarget format bits. Making a ton of quick progress :)
<alyssa> Looking at fancier formats and making negative progress, lol
<alyssa> ....Is that an address splatted across the clear color fields? WTF???
<anarsoul> maybe some shader?
<anarsoul> iirc utgard uses a shader to clear depth
<anarsoul> but not color
<alyssa> anarsoul: It's quite possible, yeah. It looks like they need a blend shader for some of these formats (not supported natively, evidently)
<HdkR> alyssa: Time for dual source blend? :P
<alyssa> HdkR: ...How would that work exactly?
<HdkR> hm?
<HdkR> Effectively passing a vec8 to the blend shader for a single RT :D
<alyssa> Yeah how uh
<alyssa> does that
<alyssa> work
<alyssa> :p
<HdkR> How does it work from the API side or the hardware side? :P
<alyssa> ...both
<HdkR> Uh, I wrote a piglit for it a few years ago, lemme find
<alyssa> ....of course you did :p
<HdkR> Shows the ES 2 side
<HdkR> It's a product of what is set in glBlendFunc. Which in that test is `glBlendFunc(GL_SRC_COLOR, GL_SRC1_COLOR);`
<HdkR> Doesn't set the blend equation so it should default to....add?
<alyssa> (So, I understand half of the format bits. Like, 16 of them I get. The other 16, I'm working onit.)
<alyssa> HdkR: Interesting
<alyssa> RGB565 is interesting
<MoeIcenowy> does Mali Midgard support Geometry Shader?
<MoeIcenowy> (it's useful when emulating Nintendo 3DS -- the PICA2000 GPU only has a feature set like GLES2, but with Geometry Shader
<alyssa> MoeIcenowy: The hw does, yes. Panfrost doesn't (yet)
<MoeIcenowy> thanks
<alyssa> Sure
<MoeIcenowy> BTW will panfrost work with T720 now?
<MoeIcenowy> and does panfrost mali_kbase support reset controller?
<HdkR> The PSP has a limited version of tessellation as well. Need those tessellation shaders :P
<alyssa> MoeIcenowy: It should work on T720, yes
<alyssa> It hasn't been specifically tested on that platform, but probably with a little massaging
<alyssa> HdkR: What's the diff between tess and geom?
<MoeIcenowy> oh weird
<MoeIcenowy> panfrost mali_kbase doesn't use upstream DT binding
<alyssa> Oops?
<alyssa> You need to add a compatible line iirc
<HdkR> alyssa: Mostly that tessellation is garbage and nobody should use it
<MoeIcenowy> alyssa: is there any example for meson with panfrost mali_kbase?
<alyssa> Bwah?
<HdkR> alyssa: In reality. Tessellation shaders let you do geometry subdivision and vertex emitting while geometry shaders allow you to do work on a primitive(With some minor ability to do vertex emission but you shouldn't do it there)
<HdkR> PSP can do a basic form of it where it....divides a triangle fan around its outer edge at linear intervals I think?
<HdkR> Basically spline interpolation
<HdkR> Loco Roco uses it to convert quads in to wobbly circles
chewitt has joined #panfrost
<chewitt> @alyssa ping!
<alyssa> chewitt: Bwah?
<chewitt> I'm updating our panfrost packaging
<alyssa> I'm sorry
<alyssa> :p
<chewitt> (not changed since kmsro)
<chewitt> I'm pulling the main mesa (master) branch
<chewitt> but this is incomplete, correct?
<chewitt> what branch has the missing bit(s)?
<alyssa> See the instructions in
<alyssa> Or bug HdkR since he knows how to egt it work apparently :^)
<alyssa> That's the repo
<chewitt> no instructions on btw .. just some gears
<alyssa> Er in the repo of that name on gitlab
<alyssa> public/ or something
<HdkR> Supposedly anyway
<alyssa> <--- Evening's work
<alyssa> Probably should update headers/pandecode while it's fresh in my brain, but tired and I wasn't supposed to be poking at ES3 anyway ;P
<chewitt> what's the file path (relative to mesa) for the nondrm content?
<chewitt> still can't see instructions
<alyssa> mesa/src/gallium/drivers/panfrost/nondrm
<chewitt> some deprecation warnings
<chewitt> (which cause build fail)
<alyssa> The build failure looks like a crosscompile issue?
<chewitt> DEPRECATION: Project targetting '>= 0.45' but tried to use feature deprecated since '0.48.0': python3 module
<chewitt> The Meson build system
<chewitt> Version: 0.49.1
<chewitt> DEPRECATION: build_always is deprecated. Combine build_by_default and build_always_stale instead.
<chewitt> so meson (buildsys) plumbing
<alyssa> That doesn't matter
<alyssa> (I mean, it matters to someone. Not us :P)
<alyssa> It's the ERROR line
<chewitt> hmm.. so, in previous packaging @narmsrtrong added
<chewitt> which looks familiar
<chewitt> maybe?
<alyssa> Yes, that's what you need
<alyssa> Although I could probably fix that upstream easily enough, since I think page sizes are fixed at 4k for what we care about..
<chewitt> ^ pretty please
<alyssa> Sent myself a reminder
<chewitt> src/gallium/drivers/panfrost/ ERROR: Non-existent build file 'src/gallium/drivers/panfrost/nondrm/include/'
<chewitt> when replicating previous changes
<chewitt> i.e. deleting
* alyssa blink
<alyssa> I did not sleep enough for this
<alyssa> ("You should probably be sleeping now..?")
<chewitt> creating a blank file seems to bypass that..
<chewitt> andecode@exe/pandecode_decode.c.o.d' -o 'src/gallium/drivers/panfrost/d407bd6@@pandecode@exe/pandecode_decode.c.o' -c ../src/gallium/drivers/panfrost/pandecode/decode.c
<chewitt> ../src/gallium/drivers/panfrost/pandecode/decode.c:25:10: fatal error: panfrost-job.h: No such file or directory
<chewitt> #include <panfrost-job.h>
<alyssa> *BLINK*
<alyssa> Wat
<chewitt> sorry for spam
<alyssa> I didn't even do anything obscure
<chewitt> In file included from ../src/gallium/drivers/panfrost/pan_pretty_print.c:24:
<chewitt> ../src/gallium/drivers/panfrost/pan_pretty_print.h:27:10: fatal error: panfrost-job.h: No such file or directory
<chewitt> and
<chewitt> ../src/gallium/drivers/panfrost/pandecode/mmap.h:31:10: fatal error: panfrost-job.h: No such file or directory
<chewitt> #include <panfrost-job.h>
<chewitt> same error
<alyssa> ....How
<alyssa> Did I forget a git add or something
<chewitt> this is current mesa HEAD
<chewitt> mesa completed compile *before* I patched the nondrm bits in
<alyssa> Meep
<alyssa> Okay uh
<alyssa> Why are derivative computations apparently done on the texture unit
<alyssa> Surely I made a typo?
<tomeu> o/
<tomeu> it's great to wake up and find such news from robher
<tomeu> sadly it's a bit too early here for beers
<tomeu> alyssa: how feasible do you see to drop nondrm in the near future? I would like to upstream the drm bits, but I find the abstraction layer getting quite in the way of cleaning stuff up
<alyssa> tomeu: nondrm is dropped as soon as DRM is ready :)
<tomeu> and what do you need from DRM so we can say it's ready? :)
<alyssa> ...Being functional? :P
<chewitt> okay.. so the panfrost-job.h error(s) are caused by me removing "include_directories('include')," from src/gallium/drivers/panfrost/
<chewitt> but when I leave it it..
<chewitt> ../src/gallium/drivers/panfrost/nondrm/pan_nondrm.c:36:10: fatal error: panfrost-mali-base.h: No such file or directory
<chewitt> #include <panfrost-mali-base.h>
<tomeu> alyssa: well, I saw a photo of a cube in the internets, is that enough? :)
<alyssa> ...I think you can answer that :p
<alyssa> tomeu: Ideally they could coexist while the DRM driver is in growing pains (if I dropped nondrm right now and upstreamed your DRM patches right now... there would be substantial regressions.)
<alyssa> I'm happy to take a patch for DRM that doesn't regress the exist non-DRM stuff, though it sounds like that's difficult for you?
<chewitt> nothing like a substantial regression to motivate the troops!
<alyssa> ^ Some notes from poking at shaders with the GLSL spec in hand
<tomeu> alyssa: I haven't tested things yet, so I need to know a bit more about what would be regressed
<tomeu> alyssa: but I could cleanup and submit what I have
<tomeu> just wouldn't be thrilled about adding more code while the abstraction is in place
<tomeu> not a deal breaker though
<alyssa> tomeu: If nothing else, I imagine there are very-low-prio features that you don't want to implement that I want to keep (dumping perf counters comes to mind -- we don't really -need- it in the DRM driver, but for driver dev, I want to keep it, and it does work fine with vendor as-is.. would be sour about losing that capability)
<tomeu> alyssa: what about: I do some testing and if things look good, I will ask you to test as well with what you usually run, and we talk again then
<tomeu> ah, I see
<alyssa> Though honestly, all else being equal, I'm more than happy to lose counters for a while if it means we can go mainline
<alyssa> (And if I needed counters, heck, I could implement it myself :P)
<tomeu> alyssa: I think perf counters are important, and hopefully wouldn't be that much work
<tomeu> anything else?
<alyssa> uhh
<alyssa> I mentioned the GROW_ON_GPF stuff (see the backlog), but that's not a blocker; it's just a little annoying
<alyssa> Bear in mind I haven't tested any of the above stuff yet, since building kernels is uncomfortable for my setup. When you feel it's time to have me give it a spin, I'll do more rigorous testing, but if the usual stuff works (weston with egl clients, sway with glx/xwayland clients, FBOs [AFBC], etc), we should be ok
<alyssa> Signing off for the evening. Best of luck :)
BenG83 has joined #panfrost
<tomeu> cool, rest well :)
chewitt has quit [Quit: Zzz..]
<tomeu> alyssa: just did some testing and I think we'd still need 1 or 2 weeks to get to feature parity
pH5 has joined #panfrost
raster has joined #panfrost
indy has quit [Ping timeout: 250 seconds]
unoccupied has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
BenG83 has quit [Quit: Leaving]
afaerber has joined #panfrost
pH5 has quit [Quit: bye]
TheKit has quit [Ping timeout: 240 seconds]
TheKit has joined #panfrost
<alyssa> :+!:
<alyssa> * :+1:
<robher> tomeu,alyssa: In regards to upstreaming, do we expect the job submit to expand? What I mean is what mesa passes to kbase driver is pretty fixed and a small subset of what kbase supports and the drm driver relies on that. Maybe it's just all vendor driver over-engineering. Some of the limits in the DRM driver are just internal shortcuts, but maybe there's other things. Are there features not yet implemented in mesa that would affect job submit? We don't
<robher> want to get stuck with an ABI prematurely. Though, we can just add submit_v2... :)
<alyssa> Yes, the job submit will expand
<alyssa> What I have there is good for ES 2.0 (and maybe not even with complex FBOs)
<alyssa> ES3 changes that substantially
<robher> and Vulkan?
<alyssa> I haven't looked at Vulkan
<alyssa> But probably yes in the same way as ES3
<HdkR> Theoretically ES 3.0 will be the largest change with 3.1 and 3.2 adding minimal things(If anything at all on top of that layer) Then Vulkan may need just a bit more on top of that depending on if buffer management needs any changes there
<alyssa> HdkR: Er, no, ES3.1 and ES3.2 both add new shader stages which affects job submission
<alyssa> I couldn't tell you in what way, without having looked at that yet
<alyssa> (Well, we know compute. Not geom or tesselation yet)
<alyssa> robher: BTW, is pre_dep (or equivalent) implemented right now? For scheduling kernel side?
<HdkR> Couldn't remember if the kernel bits need to care about that other than consuming some buffer of memory :P
* alyssa class
<robher> alyssa: is that tracking BO dependencies?
<alyssa> robher: Er, job dependencies I think
<alyssa> Maybe also BO dependencies but I think that part is userspace
* cwabbott reads scrollback
<robher> alyssa: either way, no.
<cwabbott> alyssa: I don't think tess or geom really require any kernel interaction
<cwabbott> they're just special vertex jobs, since it's all implemented completely in the driver
<cwabbott> I had a look at what they output for tess/geom, and the shader is... big
<cwabbott> which, of course, means that using them in reality would be pointless... they're just another checkbox feature
<HdkR> Obviously it's necessary for hairworks emulation :P
<cwabbott> alyssa: also, derivatives probably use the texture unit since "normal" texture sampling also requires the HW to do an implicit derivative
<robher> alyssa: Inter job dependencies would be done with in and out fences. BO dependencies I think are handled internally (beyond each job has a BO list). Not sure how we'd handle job dependencies between atoms in a single submit.
<cwabbott> derivatives are weird on midgard, since you have to syncronize all the threads in a quad so that they can exchange values
<cwabbott> I can see a cmdstream bit for "this shader does derivatives, and therefore needs to be dispatched in quads" but I'd be verrry surprised if that didn't include texturing that does implicit derivatives
<cwabbott> there are these weirdo things called "helper threads/invocations" in GL which don't correspond to an actual pixel in the triangle, but they're there to compute derivatives, so I can totally see a "do we need helper invocations" bit
<robertfoss> I've just got weston up and running on panfrost on rk3399 based rockpi4 board
<robertfoss> And I'm hitting an issue as soon as I move the mouse
<robertfoss> Every surface apart from a little square around the mouse is painted black
<robertfoss> And I'm seeing `Warning: clear color null?` in the logs
<robertfoss> alyssa: also, unrelated to ^^, but glmark2-es2-wayland thre seems to be a double free somewhere
<robertfoss> free(): invalid pointer
<robertfoss> Aborted
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
raster has quit [Remote host closed the connection]
stikonas has joined #panfrost
afaerber has quit [Quit: Leaving]
<alyssa> robertfoss: EGL_BUFFER_AGE is being inappropriately exposed
<alyssa> cwabbott: Alright, thank you. Will reread that when I'm not mentally drained
<HdkR> There are a few extensions that need to be disabled actually
<HdkR> Panfrost is definitely exposing too many atm
<alyssa> HdkR: Indeed
<urjaman> "inappropriately exposed" *chuckle*
* hanetzer snortles
<hanetzer> age too :P
<alyssa> urjaman: Real mature -.-
<alyssa> Just sent a patch off to the list / a nondrm-branch to fix cross compile, I hope