[Mesa-dev] [PATCH 12/12] gallium/radeon/winsyses: decrease max_alloc_size to 1/3 of largest heap
Michel Dänzer
michel at daenzer.net
Tue Aug 2 01:13:45 UTC 2016
On 01.08.2016 16:35, Michel Dänzer wrote:
> On 30.07.2016 06:42, Marek Olšák wrote:
>> From: Marek Olšák <marek.olsak at amd.com>
>>
>> This is controversial, but I don't see a better way out of this.
>>
>> Tonga has 2 GB of VRAM and 2 GB of GTT. amdgpu is not capable of submitting
>> an IB referencing 1 GB of VRAM and 1 GB of GTT. The CS ioctl never succeeds
>> even though it's far below the limits.
>>
>> Without this, "dEQP-GLES2.functional.color_clear.single_rgb" fails to
>> submit an IB. With this, dEQP throws a framebuffer-incomplete exception
>> and kills the process.
>>
>> IMO, failing the CS ioctl is worse for stability than failing big
>> allocations.
>
> I can agree with that, but this change can't reliably prevent CS ioctl
> failures:
>
> I believe the problem is mostly due to BOs which are pinned for scanout.
> Since up to 6 CRTCs can scan out different buffers at any time, in the
> worst case it may not be possible to place any BOs whose size is >= ~1/7
> of the VRAM size.
>
> At the end of the day, this needs to be solved in the kernel one way or
> another.
Or if you do want to avoid the problem in userspace for now, maybe use 1
/ (number of CRTCs + 1) instead of hardcoding 1/3?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
More information about the mesa-dev
mailing list