[PATCH 00/13] shadow page table support

[Christian König]

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