Message ID | bug-92775-502@http.bugs.freedesktop.org/ (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
https://bugs.freedesktop.org/show_bug.cgi?id=92775 --- Comment #1 from Michel Dänzer <michel@daenzer.net> --- (In reply to Shawn Starr from comment #0) > One solution discussed is to split up the transfer into smaller chunks in > radeon_ttm. Specifically, here's how I think a fallback could be implemented in the kernel driver which can never fail because of fragmentation or resource starvation: During initialization, reserve some pinned GTT memory for bounce buffers. When a BO can't be bound to GTT for eviction as in the case reported here, instead do the eviction directly from VRAM to CPU domain in one or several passes of: 1. Copy part of the BO from VRAM to one of the reserved bounce buffers in GTT using the GPU. 2. Copy that part of the BO from the bounce buffer to the BO's system RAM pages using the CPU.
https://bugs.freedesktop.org/show_bug.cgi?id=92775 --- Comment #2 from david1.zhou@amd.com <david1.zhou@amd.com> --- (In reply to Michel Dänzer from comment #1) > (In reply to Shawn Starr from comment #0) > > One solution discussed is to split up the transfer into smaller chunks in > > radeon_ttm. > > Specifically, here's how I think a fallback could be implemented in the > kernel driver which can never fail because of fragmentation or resource > starvation: > > During initialization, reserve some pinned GTT memory for bounce buffers. > When a BO can't be bound to GTT for eviction as in the case reported here, > instead do the eviction directly from VRAM to CPU domain in one or several > passes of: > 1. Copy part of the BO from VRAM to one of the reserved bounce buffers in > GTT using the GPU. > 2. Copy that part of the BO from the bounce buffer to the BO's system RAM > pages using the CPU. if we can split a large BO to two parts, one is in VRAM, one is in GTT, seems also to be helpful for this case.
https://bugs.freedesktop.org/show_bug.cgi?id=92775 --- Comment #3 from Christian König <deathsimple@vodafone.de> --- Actually it doesn't need to be so complicated. Just take a look at amdgpu|radeon_move_vram_ram(). Instead of trying to reallocate and binding everything at once we just need to bind the already allocate new_mem pages page by page and copy page by page.
https://bugs.freedesktop.org/show_bug.cgi?id=92775 Shawn Starr <shawn.starr@rogers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #4 from Shawn Starr <shawn.starr@rogers.com> --- I believe this can be closed, given the massive changes in amdgpu. I haven't seen issues anymore.
--- r600_buffer_common.c 2015-11-02 01:56:10.796446185 -0500 +++ r600_buffer_common.c.workaround 2015-11-01 21:16:55.398517539 -0500 @@ -133,7 +133,7 @@ bool r600_init_resource(struct r600_comm case PIPE_USAGE_IMMUTABLE: default: /* Not listing GTT here improves performance in some apps. */ - res->domains = RADEON_DOMAIN_VRAM; + res->domains = RADEON_DOMAIN_VRAM | RADEON_DOMAIN_GTT; flags |= RADEON_FLAG_GTT_WC; break; } @@ -158,7 +158,7 @@ bool r600_init_resource(struct r600_comm /* Tiled textures are unmappable. Always put them in VRAM. */ if (res->b.b.target != PIPE_BUFFER && rtex->surface.level[0].mode >= RADEON_SURF_MODE_1D) { - res->domains = RADEON_DOMAIN_VRAM; + res->domains = RADEON_DOMAIN_VRAM | RADEON_DOMAIN_GTT; flags &= ~RADEON_FLAG_CPU_ACCESS; flags |= RADEON_FLAG_NO_CPU_ACCESS; }