Hi David,
well that additional placement range actually caused a performance problem.
It's only effect is that we check the invisible space twice, which can
burn quite a bunch of CPU cycles during allocation.
Can you somehow easily check for performance regressions?
Regards,
Christian.
Am 07.11.2016 um 03:35 schrieb zhoucm1:
> Hi Christian,
> I have some time not to track code, I'm not sure if I miss anything.
> In my mind, this change was added while doing performance
> optimization. If you don't encounter any problem, I'm suggesting not
> to change it, we have many regressions(bug and performance) recently.
>
> Regards,
> David Zhou
>
> On 2016å¹´11æ??04æ?¥ 19:00, Christian König wrote:
>> From: Christian König <christian.koenig at amd.com>
>>
>> This only has the effect of scanning the invisible range twice
>> since the topdown flag is given anyway.
>>
>> Signed-off-by: Christian König <christian.koenig at amd.com>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 -----------
>> 1 file changed, 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> index 6efa8d7..052c1b0 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> @@ -128,17 +128,6 @@ static void amdgpu_ttm_placement_init(struct
>> amdgpu_device *adev,
>> if (flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS)
>> lpfn = adev->mc.real_vram_size >> PAGE_SHIFT;
>> - if (flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS &&
>> - !(flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) &&
>> - adev->mc.visible_vram_size < adev->mc.real_vram_size) {
>> - places[c].fpfn = visible_pfn;
>> - places[c].lpfn = lpfn;
>> - places[c].flags = TTM_PL_FLAG_WC |
>> - TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_VRAM |
>> - TTM_PL_FLAG_TOPDOWN;
>> - c++;
>> - }
>> -
>> places[c].fpfn = 0;
>> places[c].lpfn = lpfn;
>> places[c].flags = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED |
>
