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

[Nicolai Hähnle]

On 02.08.2016 10:55, Marek Olšák wrote:
> 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.

That really sounds like the kind of thing the kernel should take care of...

Nicolai

>
> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>