13:50 <alyssa> jekstrand: Trying my hand at wiring up the panfrost pipeline cache

13:50 <alyssa> with the new shiny common

13:50 <alyssa> unless you've already done that somewhere?

13:52 <alyssa> at least as a stub so we stop failing over at GetPipelineCacheData

13:54 <alyssa> just emptying the pipeline cache file gets dEQP-VK.synchronization.op.single_queue.fence.write_clear_color_image_read_image_compute.image_64x64x8_r32_sfloat from crash to stub..?

13:54 <alyssa> s/stub/fail

13:57 <alyssa> Probably easier thing for me to try is wiring up textureSize

13:59 <alyssa> although that requires fixing the bug that causes all of dEQP-VK.glsl.* to fail.

14:01 <alyssa> :v

14:03 <alyssa> https://rosenzweig.io/test.xml

14:03 <alyssa> Infuriatingly close!

14:06 <alyssa> still wondering if it's an indexed draw issue? but I don't see anything wrong

14:42 <cwabbott> alyssa: you can use the common pipeline cache just by deleting any stubs you have

14:43 <alyssa> cwabbott: ok, that's what I did but wasn't sure it was right, thanks :)

14:43 <cwabbott> you'll have to provide an empty vk_physical_device::pipeline_cache_import_ops list, I think that's all you need for a no-op implementation

14:43 <alyssa> ack

14:43 <alyssa> and no-op should be enough for CTS (obviously not perf but priorities)

14:44 <alyssa> I saw :)

14:45 <alyssa> btw, do you plan on looking at !16000? or are my attempts to abstract ir3's RA in vain and I should just close the MR and vendor?

14:46 <alyssa> (the latter saves you review effort and me not-breaking-ir3 effort, I suppose.)

14:55 <cwabbott> oh, forgot about that

14:55 <cwabbott> nice MR number, btw

15:01 <alyssa> Quite :D

15:02 <daniels> only 384 more to go

15:04 <alyssa> ;D

15:05 <alyssa> cwabbott: orthogonally, I realized you can do fast swaps on Bifrost

15:05 <alyssa> because of the exposed pipeline

15:06 <alyssa> (Just two moves, with the reads happening at once and the writes happening at once)

15:06 <alyssa> not sure that's legal though ;p

15:06 <alyssa> I.. can't see a reason why it wouldn't be, though

15:09 <cwabbott> alyssa: yup

15:09 <alyssa> Cursed.

15:10 <alyssa> valhall, with its sane pipeline, unfortunately require 3 instructions :-p

15:10 <alyssa> (Probably add/sub is fastest)

15:17 <jekstrand> alyssa: Neat! No, I've not tried to wire it up in panfrost yet.

18:52 <anarsoul> alyssa: can midgard/bifrost do y-flip in hardware?

19:01 <alyssa> anarsoul: y-flip of what?

19:01 <alyssa> it's not one thing

19:02 <macc24> anarsoul: the hardware mali's displaying onto might be able to do that

19:03 <alyssa> anarsoul: but, midgard can, bifrost can't

19:50 <anarsoul> alyssa: dFdy() and fragcoord

19:50 <anarsoul> and render buffer apparently

19:52 <alyssa> ???, midgard only, yes but it doesn't matter.

19:52 <anarsoul> alyssa: I'm just wondering if panfrost will benefit from !16136 :)

19:55 <alyssa> Possible but it would take work and I don't see the use case for us

19:56 <anarsoul> I see

20:13 <cphealy> Here's a potential use: mirroring video that is rendered by the 3D GPU

20:14 <cphealy> camera facing customer being displayed should be mirrored

20:25 <robclark> hw doing yflip for you is maybe saving a couple instructions in shader? It is basically nearly nothing

20:31 <HdkR> Enough for Nvidia to still have it in hardware :P