[PATCH 00/13] shadow page table support

zhoucm1 david1.zhou at amd.com
Fri Aug 5 02:43:33 UTC 2016



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
>
>



More information about the amd-gfx mailing list