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