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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170829/5f28cafb/attachment.html>
