13:35 <tomeu> alyssa: any ideas regarding the min/max indexes in vbos? when using stk's gles3 renderer, 50% of the time in mesa is spent iterating through the vertices to compute those

13:40 <tomeu> alyssa: guess we could create a cached BO for buffers, then copy on submission to a WC one

13:49 <alyssa> tomeu: I'm not positive... you think the issue is caching?

13:49 <alyssa> but yes I noticed that stk spends an absurd amount of time in that routine :\

14:16 <tomeu> alyssa: well, the issue is the lack of caching, because we read a lot of uncached data

14:26 <tomeu> alyssa: or well, if you have any ideas on how we can avoid the driver having to read all the vbo...

14:35 <alyssa> tomeu: Not sure.

14:35 <alyssa> I mean, the correct solution is for the app to use glDrawRangeElements and specify the values themselves

14:35 <alyssa> but evidently stk does not

16:21 <alyssa> tomeu: If the issue really is reading/caching, the answer is *not* to cache it ourselves

16:22 <alyssa> Rather patching Gallium to compute the min/max indices on upload time, if that's possible

16:22 <alyssa> So if you do it right, you save the read entirely

16:22 <alyssa> Right now the flow is, you know

16:22 <alyssa> Gallium reads app user indices --> writes to BO ---> Panfrost reads BO for indices

16:22 <alyssa> that could be hacked to

16:23 <alyssa> Gallium reads app user indices and updates min/max --> writes to BO

16:23 <alyssa> This is on the assumption that the memory traffic really is the bottleneck, anyhow.

16:44 <robmur01> +1 to that

16:46 <robmur01> reminds me of the microscopy thing I once wrote where images had to be moved from a capture buffer to a storage buffer anyway, so the "copy" operation also took care of both min/max and axis flipping :)

19:56 <anarsoul> alyssa: please make this optimization generic so lima can also benefit from it

20:19 <alyssa> anarsoul: of course :)

20:52 <MastaG> but the most important question would be.. can it run Crysis?

21:00 <alyssa> MastaG: Does that even build for arm gnu/linux?

21:01 <alyssa> Or OpenGL at all?

21:01 <alyssa> So I'll have to say, probably not ;)

21:12 <HdkR> I'm sure wine can handle the D3Dd translation bit

21:12 <HdkR> Just need an x86 recompiler faster than qemu

21:14 <HdkR> time for a Vulkan driver to go the vkd3d path? :D

21:22 <MastaG> yeah I was just trying to be unny

21:22 <MastaG> *funny even

21:26 <HdkR> How soon until an ARM CPU has the single threaded performance of a 5Ghz Coffee Lake CPU that can actually handle Crysis 1 at this point? :P

21:27 <HdkR> Crysis 1 is a monster lightly threaded app

21:34 <MastaG> lol

21:34 <MastaG> that's actually a shame.. you guys are doing such a wonderful job getting the graphics drivers up to the latest GL spec

21:34 <MastaG> but there's not so many A++ games that run on arm

21:35 <MastaG> retroarch, kodi, supertuxkart and the countless of quake-engine ports

21:39 <MastaG> unreal engine 4 could be a possibility since it was ported to openpower as well: https://www.raptorengineering.com/TALOS/op_ue4_gl.php

21:41 <HdkR> Pretty much every engine supports ARM. That's how you get Switch and Android ports :P

21:43 <MastaG> I know.. but I was thinking of linux on arm

21:44 <MastaG> Switch is awesome btw.. I compiled this yuzu emulator and it actually runs mario odyssey

21:45 <MastaG> but for Android everything is stuffed with in-app purchases and adware

21:47 <HdkR> eh, that bit is just an ecosystem problem

21:47 <HdkR> Whales are easier to exploit than sales volumes

23:20 <marex-cloud> MastaG: Android is Linux on ARM :)

23:37 <HdkR> hehe