07:18 <bbrezillon> cwabbott: that would still be two dummy pages (one for reads, and one for writes) and a bit a lowering in shaders to read from/write to a different VA

07:23 <bbrezillon> or rather, two image descriptors, one pointing to the read-only section, and the other one to the write-only section, and then we pick the right one from the shader based on the access type. It's a shame we have to duplicate the sparse VA ranges, but I see no other way to do that.

13:11 <alyssa> bbrezillon: indeed you need to duplicate ranges, unless there's some trick with Mali's zero sink (although iirc that was a fixed VA range and not something you can map around)

13:11 <alyssa> worse, you need to duplicate every buffer because with BDA you don't know whether a given buffer VA is sparse or not

13:12 <alyssa> (unless you very carefully partition your VA space, I guess, but that'll slow down non-sparse SSBO stores etc)

13:12 <alyssa> but all of that is fundamentally solvable and hk does something similar

13:12 <alyssa> the really hard problem is shaderResourceResidency

13:12 <alyssa> implementing that for texture sampling without hw support..... yugh

13:13 <alyssa> even if you maintain a sideband data structure telling you which pages are mapped, you have no easy way of associating a texture sampling operation with a set of pages read

13:13 <alyssa> without hw support, either you..

13:14 <kusma> anisotropic filtering will be "fun"

13:14 <alyssa> 1. do all the address/wrapping/etc calculations in shader and hope you round exactly the same way as the hardware does, so you can then do a--

13:14 <alyssa> yeah, aniso is """"""fun"""" here

13:14 <alyssa> 2. have 2 texture descriptors, one with dummy pages that read 0, the other with dummy pages that read non-zero, and then check if sampling twice gives different results

13:14 <alyssa> this is actually kinda nice...?

13:15 <alyssa> and that first sampling is going to happen anyway so it just costs one extra texturesample and some bcsels

13:15 <alyssa> ...but now we need to map every image THREE times in VA space!

13:15 <alyssa> zero page, ones page, dummy page

13:16 <alyssa> because image storse might store zero or one or anything else, so we can't share that with either the 0 or the non-0 mapping

13:16 <alyssa> (in particular, the app might imageStore all zeroes and then your dummy page can't be distinguished from the zero page)

13:16 <alyssa> my real question i suppose is what is prompting emulation of sparse on Mali

13:17 <alyssa> sparse is only really used for dx12 calibre games

13:17 <alyssa> for reference i only just got this stuff working on apple, and perf is still hideous..

13:17 <alyssa> (and we have hw shaderResourceResidency support, thankfully)

13:18 <alyssa> robmur01: drm/asahi also wants this, fwiw

13:18 <alyssa> currently we have drm/gpuvm patches for this but if they're going to ba nak'd i'd rather know now so we can stop rebasing them and just loop in the caller instead

13:20 <alyssa> https://github.com/AsahiLinux/linux/commit/f0b4aa59aadedc926b0ca155c3607abba4ebc125

13:42 <bbrezillon> alyssa: didn't notice shaderResourceResidency /o\

13:43 <bbrezillon> or rather, I didn't understand how bad it would get...

13:43 <alyssa> ..yeah..

13:43 <alyssa> yeah, i'm not aware of any prior art for emulating it on any shipping driver

13:43 <alyssa> (although it's obvious how you might go about doing it.)

13:44 <bbrezillon> I must admit my main focus was sparse residency without shaderResourceResidency, and even residencyNonResidentStrict=true was something I was planning to do as a second step

13:44 <alyssa> i mean. easier than emulating geom/tess, lolz.

21:01 <robclark> why is panvk_vX_event.c stuff all panvk_per_arch? That all looks like pretty generic syncobj code