On 12.03.2015 10:30, Oded Gabbay wrote: > > On 03/12/2015 11:23 AM, Christian König wrote: >> 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 at gmail.com> >>>> wrote: >>>>> On Wed, Mar 11, 2015 at 2:21 PM, Christian König >>>>> <deathsimple at vodafone.de> 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 at amd.com> >>>>>>> Signed-off-by: Alex Deucher <alexander.deucher at amd.com> >>>>>>> Cc: stable at vger.kernel.org >>>>>> 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 at amd.com> >>>>> 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. > I noticed this bug when trying to allocate very large BOs (385MB) from the > other side of VRAM. > However, even with this fix, the following scenario still fails: > 1. Allocate BO of 385MB on VRAM with no CPU access. > 2. Map it to VRAM > 3. Allocate second BO of 385MB on VRAM with no CPU access > > The last step fails as the ttm can't find a place to put this second BO. I > suspect the Top-Down thing isn't being respected at all by the > creation/pinning of BO. > > I think that what happens is that the first BO is pinned right after the > first 256 MB, instead of pinning it at the end of the VRAM. > Then, when trying to create the second BO, there is no room for it, as there > is only 256MB before the first BO, and 383MB after the first BO. > > I need to debug it further, but will probably only do that on Sunday.
What is the content of radeon_vram_mm (in debugfs) after you allocated the first BO? The placement should be visible there pretty fine. Regards, Christian. > > Oded > >>> >>> 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 at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel