Am 05.08.2016 um 04:43 schrieb zhoucm1: > > > On 2016å¹´08æ??04æ?¥ 17:52, Christian König wrote: >> Am 04.08.2016 um 08:05 schrieb zhoucm1: >>> >>> >>> On 2016å¹´08æ??03æ?¥ 21:39, Christian König wrote: >>>> Doubling all the page table updates clearly doesn't sound like a >>>> good idea to me. >>> Could you tell me why it isn't a good idea? >>> I though the overhead is the least, and we don't need to sync >>> between bo and its shadow, aren't we? >> >> Yeah, but you also double the CPU overhead generating the update >> commands. And for large updates you need to backup the whole page >> table BO anyway, so the copy overhead between system memory and VRAM >> shouldn't matter so much. >> >> I would rather go into the direction that we switch shadow and real >> BO like we discussed previously. >> >> This way you would made all updates on the shadow first and then copy >> all changes page tables to their VRAM location after scheduling all >> the updates. > I have implemented your suggestion, and tested just now. The big > problem is coming, the performance dropped very much, from 68fps to > 50fps with heaven on Fiji. > The root cause is coping shadow bo to pt bo need to take pd > reservation, which kills your improvement of sync for vm page table > udpating. Mhm, that is indeed a bit problematic. I don't know of hand either how to fix this. > > I checked doubling update pt, which fps is 64.5fps, dropped 3.5fps > from 68fps. > > With thinking more, if we select doubling update, then updating shadow > jobs don't need to align with normal pt jobs, since shadow jobs > contain the content of updating, just let them run in alone entity > (shadow entity) with normal run_queue, after gpu reset, we wait for > all shadow jobs finished, and then recover page table from shadow, > this way, we will completely avoid the shadow jobs effect. > > What do you think of it? This way you need to enable the scheduler again before you can recover anything, which is clearly not such a good idea. Ok, let's do this with the double pt update for now. From your numbers that looks like the option with the least impact and we can work on that later on if we really find the double CPU overhead to be a problem. Regards, Christian. > > Regards, > David Zhou > >> >> Regards, >> Christian. >> >>> >>> Regards, >>> David Zhou >> >> >
