On 12.03.2015 10:02, Michel Dänzer wrote:
On 12.03.2015 06:14, Alex Deucher wrote:
On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote:
On Wed, Mar 11, 2015 at 2:21 PM, Christian König
<deathsimple@xxxxxxxxxxx> wrote:
On 11.03.2015 16:44, Alex Deucher wrote:
radeon_bo_create() calls radeon_ttm_placement_from_domain()
before ttm_bo_init() is called. radeon_ttm_placement_from_domain()
uses the ttm bo size to determine when to select top down
allocation but since the ttm bo is not initialized yet the
check is always false.
Noticed-by: Oded Gabbay <oded.gabbay@xxxxxxx>
Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
And I was already wondering why the heck the BOs always made this ping/pong
in memory after creation.
Patch is Reviewed-by: Christian König <christian.koenig@xxxxxxx>
And fixing that promptly broke VCE due to vram location requirements.
Updated patch attached. Thoughts?
And one more take to make things a bit more explicit for static kernel
driver allocations.
struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
problem is really that some BOs are expected to be within a certain
range from the beginning of VRAM, but lpfn isn't set accordingly. It
would be better to fix that by setting lpfn directly than indirectly via
RADEON_GEM_CPU_ACCESS.
Yeah, agree. We should probably try to find the root cause of this instead.
As far as I know VCE has no documented limitation on where buffers are
placed (unlike UVD). So this is a bit strange. Are you sure that it
isn't UVD which breaks here?
Regards,
Christian.
Anyway, since this isn't the first bug which prevents
TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
wonder if its performance impact should be re-evaluated. Lauri?
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
