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

[Alex Deucher]

On Tue, Aug 2, 2016 at 4:55 AM, Marek Olšák <maraeo at gmail.com> 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.

I think it could be fixed to a certain extent by handling migrations
to/from vram iteratively rather than trying to move the whole buffer
at once.  E.g., we may have enough room in vram, but not enough
contiguous gtt aperture or system pages to map the whole buffer to do
the transfer in one shot.

Alex