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

[Marek Olšák]

Hi Christian,

That deqp failure was due to my deqp setup that always used 16Kx16K
framebuffers.

I'm dropping this patch because it's obviously silly. It at least raised
awareness of this issue.

Marek

On Aug 2, 2016 7:30 PM, "Christian König" <deathsimple at vodafone.de> wrote:

> Am 02.08.2016 um 14:57 schrieb 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.
>>
>
> Additional to that paging VRAM should help a lot with that as well.
>
> Anyway I have both VRAM paging and splitting moves on my TODO list.
>
> Good to know that I can use "dEQP-GLES2.functional.color_clear.single_rgb"
> as a test case.
>
> Regards,
> Christian.
>
>
>> Alex
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160803/e064516e/attachment-0001.html>