[Mesa-dev] [PATCH 12/12] gallium/radeon/winsyses: decrease max_alloc_size to 1/3 of largest heap

[Marek Olšák]

On Tue, Aug 2, 2016 at 3:13 AM, Michel Dänzer <michel at daenzer.net> wrote:
> 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?

I don't know.

I could avoid the problem by splitting buffers into 128MB blocks
mapped into GPUVM consecutively, but that would prevent easy DMABUF
sharing and CPU mappings would not be consecutive.

Marek