It might be interesting to try glmark2. Marek On Tue, Aug 29, 2017 at 3:59 PM, Christian König <deathsimple at vodafone.de> wrote: > Ok, found something that works. Xonotic in lowest resolution, lowest effects > quality (e.g. totally CPU bound): > > Without per process BOs: > > Xonotic 0.8: > pts/xonotic-1.4.0 [Resolution: 800 x 600 - Effects Quality: Low] > Test 1 of 1 > Estimated Trial Run Count: 3 > Estimated Time To Completion: 3 Minutes > Started Run 1 @ 21:13:50 > Started Run 2 @ 21:14:57 > Started Run 3 @ 21:16:03 [Std. Dev: 0.94%] > > Test Results: > 187.436577 > 189.514724 > 190.9605812 > > Average: 189.30 Frames Per Second > Minimum: 131 > Maximum: 355 > > With per process BOs: > > Xonotic 0.8: > pts/xonotic-1.4.0 [Resolution: 800 x 600 - Effects Quality: Low] > Test 1 of 1 > Estimated Trial Run Count: 3 > Estimated Time To Completion: 3 Minutes > Started Run 1 @ 21:20:05 > Started Run 2 @ 21:21:07 > Started Run 3 @ 21:22:10 [Std. Dev: 1.49%] > > Test Results: > 203.0471676 > 199.6622532 > 197.0954183 > > Average: 199.93 Frames Per Second > Minimum: 132 > Maximum: 349 > > Well that looks like some improvement. > > Regards, > Christian. > > > Am 28.08.2017 um 14:59 schrieb Zhou, David(ChunMing): > > I will push our vulkan guys to test it, their bo list is very long. > > å??è?ªå??æ?? Pro > > Christian Ké°?ig <deathsimple at vodafone.de> äº? 2017å¹´8æ??28æ?¥ ä¸?å??7:55å??é??ï¼? > > Am 28.08.2017 um 06:21 schrieb zhoucm1: >> >> >> On 2017å¹´08æ??27æ?¥ 18:03, Christian König wrote: >>> Am 25.08.2017 um 21:19 schrieb Christian König: >>>> Am 25.08.2017 um 18:22 schrieb Marek Olšák: >>>>> On Fri, Aug 25, 2017 at 3:00 PM, Christian König >>>>> <deathsimple at vodafone.de> wrote: >>>>>> Am 25.08.2017 um 12:32 schrieb zhoucm1: >>>>>>> >>>>>>> >>>>>>> On 2017å¹´08æ??25æ?¥ 17:38, Christian König wrote: >>>>>>>> From: Christian König <christian.koenig at amd.com> >>>>>>>> >>>>>>>> Add the IOCTL interface so that applications can allocate per VM >>>>>>>> BOs. >>>>>>>> >>>>>>>> Still WIP since not all corner cases are tested yet, but this >>>>>>>> reduces >>>>>>>> average >>>>>>>> CS overhead for 10K BOs from 21ms down to 48us. >>>>>>> Wow, cheers, eventually you get per vm bo to same reservation >>>>>>> with PD/pts, >>>>>>> indeed save a lot of bo list. >>>>>> >>>>>> Don't cheer to loud yet, that is a completely constructed test case. >>>>>> >>>>>> So far I wasn't able to archive any improvements with any real >>>>>> game on this >>>>>> with Mesa. >> With thinking more, too many BOs share one reservation, which could >> result in reservation lock often is busy, if eviction or destroy also >> happens often in the meaning time, then which could effect VM update >> and CS submission as well. > > That's exactly the reason why I've added code to the BO destroy path to > avoid at least some of the problems. But yeah, that's only the tip of > the iceberg of problems with that approach. > >> Anyway, this is very good start and try that we reduce CS overhead, >> especially we've seen "reduces average CS overhead for 10K BOs from >> 21ms down to 48us. ". > > Actually, it's not that good. See this is a completely build up test > case on a kernel with lockdep and KASAN enabled. > > In reality we usually don't have so many BOs and so far I wasn't able to > find much of an improvement in any real world testing. > > Regards, > Christian. > > > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > >
