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 <div class="gmail_extra"> <div class="gmail_quote">On Aug 2, 2016 7:30 PM, "Christian König" <<a href="mailto:deathsimple@vodafone.de">deathsimple@vodafone.de</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 02.08.2016 um 14:57 schrieb Alex Deucher: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Tue, Aug 2, 2016 at 4:55 AM, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Tue, Aug 2, 2016 at 3:13 AM, Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 01.08.2016 16:35, Michel Dänzer wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 30.07.2016 06:42, Marek Olšák wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> From: Marek Olšák <<a href="mailto:marek.olsak@amd.com" target="_blank">marek.olsak@amd.com</a>> 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. </blockquote> 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. </blockquote> 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? </blockquote> 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. </blockquote> 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. </blockquote> 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. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Alex _______________________________________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote> </blockquote></div></div>