[PATCH 2/2] drm/amdgpu: prevent command submission failures under memory pressure
Christian König
deathsimple at vodafone.de
Fri Sep 2 10:56:22 UTC 2016
Am 02.09.2016 um 12:33 schrieb Marek Olšák:
> On Fri, Sep 2, 2016 at 9:38 AM, Christian König <deathsimple at vodafone.de> wrote:
>> Am 01.09.2016 um 16:33 schrieb Deucher, Alexander:
>>
>>> return r; > + > + return -ENOMEM; > +}
>> Unreachable code. Other than that looks good.
>>
>>
>> Ups, indeed just a merge error.
>>
>> With that fixed: Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
>>
>> Thanks for the review, I've just pushed the resulting patches to
>> amd-staging-4.6.
>>
>> Marek you might want to try and raise the limits now how much VRAM can be
>> used by a single command submission. If I remember correctly that was rather
>> conservatively.
> I would beg to differ. Just to simplify the calculation, let's assume
> there are not allocations in GTT (in practice there are very few, so
> it's very close to the reality). If you take the memory used by all
> VRAM buffers in CS, the limit for that is "VRAM size + (GTT size *
> 0.7)".
>
> If you have 4GB VRAM and 4GB GTT, Mesa allows per-CS VRAM usage to be 6.8 GB.
>
> If you have any GTT buffers there, you just subtract from that. For
> example, if you have 100MB GTT usage, the VRAM limit is 6.7 GB.
>
> Does that sound conservative to you?
Not at all :)
But I clearly remember that you noted that you can't allocate more than
75% of VRAM in one CS without running into problems sometimes. Is that
already fixed?
When I limit VRAM to 256MB on my Tonga Valley ran into a whole bunch of
CS failures because the VM page tables couldn't be swapped in again.
With that patch nearly all of them are fixed now.
Christian.
>
> Code:
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/radeon/r600_cs.h#n36
>
> Marek
More information about the amd-gfx
mailing list