14:59 <alyssa> 6 files changed, 178 insertions(+), 262 deletions(-)

14:59 <alyssa> i sure hope i didn't break anything

15:02 <macc24> alyssa: do you want me to test it if it's not valhall?

15:04 <bbrezillon> anarsoul, jekstrand: FWIW, I started implementing this vk_blitter lib before code panvk_meta, the reason I decided to a mali specific implem is that going the vk way implies trashing the panvk_cmd_buffer state every time we execute one of those meta operation, not to mention the time spent looking in the time spent looking in the pipeline cache to get the proper shaders (cache we

15:04 <bbrezillon> don't even have right now)

15:04 <bbrezillon> *before coding panvk_meta

15:05 <bbrezillon> *I decided to move to a mali specific

15:06 <alyssa> bbrezillon: FWIW, my "use frame shaders in panvk" branch seems to be working

15:06 <alyssa> assuming I'm deqp-vk'ing right

15:07 <alyssa> ..maybe

15:07 <alyssa> nope maybe not

15:19 <alyssa> `Oh, grumble

15:19 <jekstrand> bbrezillon: Yeah, meta is problematic. :-/

15:20 <alyssa> this will be .. slightly less trivial than I had hoped :\

15:22 <alyssa> ctx->position doesn't work for frame shaders

15:22 <alyssa> That shouldn't matter for blits / copies / etc

15:22 <alyssa> since the rectangle is logically specified as the bbox

15:23 <alyssa> but this breaks the mirror tests in VK >.<

15:25 <alyssa> It.. shouldn't though?

15:25 <alyssa> since we're using the varying for the texcoord still

15:25 <alyssa> so can push the transofmrations into the texcoords

15:25 <alyssa> ah but we don't actually do that pushing

15:25 <alyssa> guess I need to break out pencil and paper

15:31 <ccf100> The Matrix bridge is broken :/

15:48 <jenneron> hi, i tired to write here from matrix about what i got when trying panfrost on T604

15:49 <jenneron> matrix bridge is broken, it's probably the universe tried to stop me from disturbing you with T604

15:52 <jenneron> so, glmark2-es2 works in drm, but there are artifacts in both xorg and wayland (dmesg https://pastebin.com/tvBudqpD), there is also a segfault in wayland (backtrace https://dpaste.com/BRJ6LT7LB)

16:20 <robmur01> what's even more broken than any bridges is T604 itself :)

16:29 <alyssa> truth

17:57 <anarsoul> alyssa: daniels: out of curiosity, does collabora have access to t604 errata?

18:01 <daniels> anarsoul: I'm afraid not

18:02 <anarsoul> :(

18:13 <alyssa> anarsoul: bit of a loaded question, assuming that there exist errata docs with any more detail than "read the RTL" ....

18:14 <anarsoul> heh

18:15 <anarsoul> alyssa: well, utgard errata was something more reasonable

18:16 <anarsoul> e.g. see https://developer.arm.com/documentation/genc007749/latest

18:17 <anarsoul> and we don't have workarounds for most of these, so lima won't work on mali200

18:20 <alyssa> anarsoul: huh, wow

18:21 <alyssa> I am not convinced that document exists for midgard.

18:23 <alyssa> "Workaround: None." 🤣

20:06 <robmur01> errata docs certainly do exist, for things that licensees might need to know about

20:08 <anarsoul> robmur01: what about driver developers? :)

20:08 <robmur01> however many "issues" that can be worked around in the driver with no visible performance/functionality impact are likely not to be classified as errata, when the driver is part of the product ;)

20:08 <anarsoul> or it's assumed that driver devs at ARM can read RTL? :)

20:09 <robmur01> no, but they can read JIRA

20:09 <anarsoul> and it's not summarized in a single document later?

20:09 <robmur01> and they're most likely the ones finding the bugs in the first place

20:10 <anarsoul> heh

20:11 <anarsoul> robmur01: that's not what I'm used to at my daytime job, but I guess it somehow works for ARM

20:13 <alyssa> robmur01: Huh, I would've assumed the RTL would be easier to read than JIRA ;-)

20:14 <alyssa> You only need an EE degree for the RTL, but the JIRA needs so much more! :-p

20:27 <robmur01> in general, deviating from the original design intent is not necessarily an erratum; deviating from documented behaviour is what's problematic

20:29 <robmur01> I deal with system IP where the documented behaviour is what the TRM says - when most of it is instead a high-level graphics API, I'm sure many more liberties can be taken

20:35 <anarsoul> robmur01: so T604 peculiarities are documented in TRM?

20:42 <robmur01> no, you could pretty much summarise the contents of any Midgard-or-later TRM by reading respective Anandtech overview article plus the register definitions from kbase

20:49 <anarsoul> robmur01: so you're saying that there's no chance that we'll see panfrost supporting T604?

20:50 <anarsoul> since it basically requires access to sources of the blob?

20:56 <robmur01> I really can't say... depends how dedicated anyone is to doing archaeology on 10-year-old driver stacks, I guess

21:08 <alyssa> DDK src isn't needed for a T604 port, someday actually taking the time to do the work is

21:09 <anarsoul> alyssa: what about workarounds for the compiler?

21:31 <alyssa> not like we needed docs to write the rest of that compiler

21:35 <anarsoul> I remember you said that T860 is more sane than earlier midgards :)

21:39 <alyssa> well, yes

21:39 <alyssa> bigger feature space, though