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. 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? Regards, David Zhou > > Regards, > Christian. > >> >> Regards, >> David Zhou > >
