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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
