ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard + Bifrost + Valhall - Logs https://oftc.irclog.whitequark.org/panfrost - I don't know anything about WSI. That's my story and I'm sticking to it.
Dr_Who has quit [Read error: Connection reset by peer]
Guest3791 has quit [Ping timeout: 480 seconds]
f11f12 has joined #panfrost
f11f12 has quit []
Guest3986 has joined #panfrost
hanetzer has joined #panfrost
robmur01_ is now known as robmur01
p0g0 has joined #panfrost
italove5 is now known as italove
davidlt has joined #panfrost
davidlt has quit [Ping timeout: 480 seconds]
Guest3986 has quit [Ping timeout: 480 seconds]
anholt_ has joined #panfrost
Guest3997 has joined #panfrost
anholt has quit [Ping timeout: 480 seconds]
Leopold_ has joined #panfrost
<robmur01>
robclark: not just weird developer cases - OPPs could be provided by something abstract like the SCMI performance protocol, where the actual clock rates and voltages aren't visible to the OS at all.
greenjustin has quit [Quit: Leaving]
greenjustin has joined #panfrost
cphealy has joined #panfrost
<robclark>
robmur01: you don't need to report the current freq (in fact it is not uncommon that a GPU driver couldn't do this, ie. power/thermal control is managed by some microcontroller).. if SCMI doesn't at least expose the max clk that is unfortunate but I guess it could come from dt or something like that
jdavidberger has joined #panfrost
jdavidberger has quit [Ping timeout: 480 seconds]
jdavidberger has joined #panfrost
<alyssa>
gfxstrand: working on some panvk patches, wtf I love Vulkan now what have you done to me
<alyssa>
Vulkan/panvk is great, it's Bifrost that I hate :-p
<alyssa>
ok, so the final NIR is what I expect, so why won't the test pass
<alyssa>
gfxstrand: any tips for debugging deqp-vk fails?
<gfxstrand>
alyssa: Depends on the deqp-vk fail
<alyssa>
(also, deqp-vk takes a while to start which is more than a little annoying..)
<gfxstrand>
alyssa: Yeah, deqp-vk is heavy
<gfxstrand>
alyssa: If you don't need to poke at test internals, I recommend a release build. It'll load substantially faster.
<gfxstrand>
alyssa: But, you'll probably need to poke at test internals to actually debug things. :weary:
<alyssa>
terrifying conflicting advice :weary:
<alyssa>
:blahaj_whatever:
davidlt has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<gfxstrand>
alyssa: What test are you debugging and what's going wrong?
Daaanct12 has quit [Quit: Quitting]
Danct12 has joined #panfrost
<anholt_>
what's amazing is deqp-vk heavy startup is mostly setting up the list of tests you could possibly run.
<anholt_>
some of that is doing some test init during startup even if you aren't running that test, but not that much.
<gfxstrand>
Yeah. If you specify an exact test name, a lot of that iteration work goes away.
<gfxstrand>
Also, pattern matches with wildcards that are only at the end, are way more efficient, so dEQP-VK.ssbo.* is way faster than *.ssbo.* even though they match the same set of tests.
<alyssa>
oh, weird, ok
<gfxstrand>
I mean, it is 2.7 million test names so building that list and filtering it is gonna take time...
<alyssa>
why are there so many tests T_T
<alyssa>
gles3.2 is like 100k test tops
<gfxstrand>
In the words of idr, it's not so much exhaustive testing as exhausting testing. :D
<alyssa>
right now I'm not looking for real review, just a sanity check that this is indeed the right thing for panvk and I should go type out the patches for the GL driver
<gfxstrand>
alyssa: Have you looked at the iris code for this?
<alyssa>
A little bit, but there's a lot of it and it's hard to find my way around
<gfxstrand>
Might be worth taking a gander. It's in iris_program.c somewhere
<gfxstrand>
iris_setup_uniforms
<gfxstrand>
You can ignore the kernel input stuff. That's for clover. Rusticl doesn't need any of it.
avane_ has quit [Ping timeout: 480 seconds]
<alyssa>
Sure, yeah, that maps closely to what we're doing now (but without the layering violation)
<alyssa>
where we have a "upload these things in this dynamic layout" step
<alyssa>
I'm unsure if that's actually better than "upload everything always (to different buffers corresponding to different dirty tracking state) and use static layouts"
avane has joined #panfrost
<alyssa>
(what we do in vulkan effectively, with the descriptor set and the root table)
<gfxstrand>
Yeah, IDK either.
<gfxstrand>
I think for iris, it matters because the amount we have to upload per-image on BDW and earlier is a lot.
<gfxstrand>
Vulkan has very little so having a tiny fixed layout is fine. IDK about panfrost GL.
<alyssa>
mm, right
<alyssa>
panfrost GL has a lot of crap
<alyssa>
the SSBO uploads you'll do regardless
<alyssa>
likewise XFB
<gfxstrand>
Yeah, and those aren't too bad. vec4 per binding
<alyssa>
sampler uploads are only for old gens and not too bad
<alyssa>
the only spicy thing is the texture size
<alyssa>
i.e. lowering txs to load_ubo instead of a descriptor crawl
<gfxstrand>
🌶️
<alyssa>
without preamble shaders, the descriptor crawl is potentially expensive
<alyssa>
probably makes sense for PanVK on Valhall (and hopefully preambles are cheap there), but
<alyssa>
so basically the question is whether the cost of uploading texture size buffers all the time (even if txs isn't actually used) is acceptable
<alyssa>
it's probably not the end of the world? idk
<alyssa>
descriptor crawl probably isn't the end of the world either, not like anything is txs-bound
<alyssa>
but without preambles that adds memory traffic which isn't good
davidlt has quit [Ping timeout: 480 seconds]
anarsoul|2 has quit [Ping timeout: 480 seconds]
anarsoul has joined #panfrost
Daanct12 has joined #panfrost
Danct12 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
Leopold___ has joined #panfrost
Leopold_ has quit [Ping timeout: 480 seconds]
mmind00 has joined #panfrost
jdavidberger has quit [Ping timeout: 480 seconds]
jdavidberger has joined #panfrost
cyrozap has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
cyrozap has joined #panfrost
<gfxstrand>
alyssa: I'm amused by the number of references to Ekstrand's rule without anyone (to my knowledge) ever having stated Ekstrand's rule. :P