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. 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? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
