Am 04.08.2016 um 05:35 schrieb zhoucm1: > > > On 2016å¹´08æ??03æ?¥ 22:01, Christian König wrote: >> Well patch #10 is incorrect. The SA BO will be set to NULL by >> amdgpu_sa_bo_free(), so it can't be freed twice and so you can't >> reference the fence twice. > I see. > But amdgpu_job_free_resources still shouldn't be called twice, right? > That's an obvious duplication although it seems no effect now. Is > there any other reason? It's actually called from a couple of different locations: 1. From the CS path in amdgpu_cs.c as soon as we have a scheduler fence. 2. From the amdgpu_job_submit() path as soon as we have a scheduler fence. 3. From amdgpu_job_run() after submitting the job to the hardware ring. 4. From amdgpu_job_free(), this is for direct submissions or for freeing the job when something went wrong. Thinking about it you could be right and we could probably drop the one in amdgpu_job_run(), because amdgpu_job_submit() should have already taken care of that. But I'm not 100% sure of that. > >> >> Additional to that the whole approach here of restoring the GART from >> the backup using the SDMA won't work either. For the SDMA to work you >> need the GART to access the ring buffer. >> >> So you run into a chicken and egg problem here, for the ring buffer >> to work you need the GART and for the GART backup to work you need >> the ring buffer. > Good catch, ring buffer is a GTT buffer as well. > > Then Can we use memcpy to copy GTT to VRAM? Fortunately, the GART bo > is only one bo. Yeah that is what we did with radeon as well. Unfortunately the double housekeeping costs quite a bunch of memory. And actually we have the exactly same information in the TTM MM as well, we would just need to bind all BOs again. Give me a day or two to double check that. Might be that the solution is rather simple. Regards, Christian. > > Regards, > David Zhou > >> >> We should just restore the GART content from the housekeeping >> structure instead. Going to evaluate if and how that might be possible. > >> >> Regards, >> Christian. >> >> Am 02.08.2016 um 10:00 schrieb Chunming Zhou: >>> gart table is stored in one bo which must be ready before gart init, >>> but the shadow bo must be created after gart is ready, so they >>> cannot be created at a same time. shado bo itself aslo is included >>> in gart table, So shadow bo needs a synchronization after device >>> init. After sync, the contents of bo and shadwo bo will be same, and >>> be updated at a same time. Then we will be able to recover gart >>> table from shadow bo when gpu full reset. >>> >>> patch10 is a fix for memory leak. >>> >>> Chunming Zhou (10): >>> drm/amdgpu: make need_backup generic >>> drm/amdgpu: implement gart late_init/fini >>> drm/amdgpu: add gart_late_init/fini to gmc V7/8 >>> drm/amdgpu: abstract amdgpu_bo_create_shadow >>> drm/amdgpu: shadow gart table support >>> drm/amdgpu: make recover_bo_from_shadow be generic >>> drm/amdgpu: implement gart recovery >>> drm/amdgpu: recover gart table first when full reset >>> drm/amdgpu: sync gart table before initialization completed >>> drm/amdgpu: fix memory leak of sched fence >>> >>> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 9 ++ >>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 + >>> drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 139 >>> +++++++++++++++++++++++++++++ >>> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 80 ++++++++++++++--- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 9 ++ >>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 50 ++--------- >>> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 39 +++++++- >>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 40 ++++++++- >>> 9 files changed, 304 insertions(+), 66 deletions(-) >>> >> >> _______________________________________________ >> amd-gfx mailing list >> amd-gfx at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >
