On Tue, Aug 2, 2016 at 3:13 AM, Michel Dänzer <mic...@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.ol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
