Am 05.08.2016 um 11:12 schrieb zhoucm1: > > > On 2016å¹´08æ??05æ?¥ 16:56, Christian König wrote: >> 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. > I just completed this solution, and it works very fine as well, there > isn't any performance dropped. Well that sounds good. > Whatever we select any of the three solutions, we cannot avoid to > enable scheduler, since recovery page table jobs have to use scheduler. Why? I though we agreed to be able to send them to the rings directly? > Should I send which solution patch to review? Yeah, let's discuss on the code directly. Regards, Christian. > > Regards, > David Zhou >> >> 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 >>>> >>>> >>> >> > > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
