05:50 <icecream95> Maybe a mega-unrolled loop filling a whole 16x16 block per iteration wasn't such a good idea: 0.12 insn per cycle

05:52 <HdkR> yea, unrolling isn't always a win

06:24 <icecream95> HdkR: I think it's more that the cache can't handle reading from 16 rows of the image at once

06:33 <icecream95> HdkR: It runs 20% faster if I reduce the image width from 4096 to 4080

06:35 <HdkR> Considering you can saturate the loadstore pipelines with like 2-4 paired loadstore ops, you don't need to unroll very far :P

08:42 <chewitt> @alyssa nice article on the collabora blog :)

08:43 <chewitt> esp. the pretty pictures, which is more my level of comprehension

08:53 <daniels> 'ooh, cats!'

09:37 <kaichi> alyssa: further compliments to the article, quite extensive explanations there

09:38 <kaichi> and big congrats on the google award

10:36 <Ntemis> @alyssa there is a grammar mistake in the blog "promise high-performance in theory, and in theory" should be "promise high-performance in practice, and in theory"

10:37 <Ntemis> or better "in theory, and in practice"

10:40 <urjaman> you're copying only a part of the compound sentence but like i parsed the thing in the blog just fine

10:42 <urjaman> (promise high performance in theory) + (in theory (theory == practice))

10:43 <urjaman> anyways what i'm trying to say it's not an accident that it has "in theory, and in theory" as a part of the sentence, just that the "and in theory" referers to the following part

10:44 <urjaman> Ntemis: ^^

10:45 <urjaman> i did think it was funny tho :D

10:45 <Ntemis> hum you are right

14:02 <alyssa> chewitt: thank you!

14:02 <alyssa> karolherbst: thank you!

14:02 <karolherbst> huh? what have I done :D

14:03 <urjaman> have a nick starting with "ka" (and kaichi left)

14:04 <karolherbst> ahhh

18:31 <alyssa> cwabbott: Any idea why SWZ.* opcodes exist?

18:31 <alyssa> Functionally identical to SEL.* with the port reused, same scheduling, no more ports needed, ...

19:04 <alyssa> What the frost?

19:04 <alyssa> Looking at some OpenCL stuff to get a feel for int8, I see FMA extended opcode 206c

19:05 <alyssa> which appears to do something like

19:05 <alyssa> "Select 8-bit from src0, convert 32-bit src1/2/3 to 8-bit, and then do a select'

19:07 <HdkR> huh

19:07 <alyssa> 2166 seems like that but first two 8, second to 32->8

19:10 <alyssa> 0168 seems to select .Y from 8-bit src0 and swizzle it down to .X

19:11 <alyssa> actually since 4src 206c --> 2000

19:12 <HdkR> It is not actually a bitfield extract? :P

19:12 <alyssa> wait

19:12 <alyssa> both are opcodes 2000

19:12 <alyssa> HdkR: derp :)

19:12 <alyssa> so it's just SEL.XXXX.v2i8

19:12 <alyssa> er

19:12 <alyssa> so it's just SEL.XXXX.v4i8

19:13 <alyssa> (e02000 I mean)

19:13 <alyssa> the next case implies we don't have SEL.XYXX since we need an explicit Y->X instruction

19:14 <alyssa> e02400 is SEL.XZXX

19:15 <alyssa> 2600 is SEL.ZZXX

19:15 <alyssa> 2800 is SEL.XXZX

19:16 <alyssa> 3000 is SEL.XXXZ

19:17 <alyssa> OKay okay so it's one big SEL op

20:06 <HdkR> alyssa: So patches accepted for a Vulkan driver you say? :P

20:28 <Lyude> HdkR: you mean for midgard?

20:29 <HdkR> You're right Bifrost Vulkan would be more interesting :P

20:38 <alyssa> HdkR: if you write them I'll merge them ;P

20:41 <Lyude> narmstrong: poke, you around? it's been a while but I was wondering if you could help me get a bootloader onto the odroid n2 to do efi booting, since I might actually be getting a little bit of time to work on panfrost every now and then (also need it so I can debug igt-gpu-tools builds for fedora on aarch64, helped me justify spending time to set this up)

20:46 <Lyude> (if you're wondering, covid seems to be freeing some time up for me finally)

20:47 <Lyude> alyssa: btw, is vulkan on midgard actually possible?

20:50 <HdkR> Later generation midgard can do Vulkan

20:51 <HdkR> 2nd gen+

20:52 <HdkR> and it's only 1.0 there I believe. Not sure if it could do 1.1+

20:57 <alyssa> Lyude: probably with hacks, at least on t760+ there are blobs