<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 7, 2017 at 12:22 AM, Juan A. Suarez Romero <span dir="ltr"><<a href="mailto:jasuarez@igalia.com" target="_blank">jasuarez@igalia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 2017-02-27 at 13:48 +0100, Juan A. Suarez Romero wrote:<br>
> Current Anv allocator assign memory in terms of a fixed block size.<br>
><br>
> But there can be cases where this block is not enough for a memory<br>
> request, and thus several blocks must be assigned in a row.<br>
><br>
> This commit adds support for specifying how many blocks of memory must<br>
> be assigned.<br>
><br>
><br>
<br>
</span>Jason, any thoughts about this?<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>The issue you guys ran into as well as bug 100092 have gotten me thinking about allocation a bit...<br><br></div><div>I don't think the solution proposed here is really workable.  Kristian and I talked about something similar in the early days of the driver.  However, the way the free lists work, all blocks on the free list have to be the same size.  Because it's a lock-free data structure, you can only ever pull the first thing off the list.  This means that you can never really hope to get a N consecutive blocks from the free list and every time you want to allocate something bigger than the block size, you have to pull "fresh" blocks.  If someone actually is using a framebuffer with 2k attachments (which is crazy) in a real rendering loop, then the block pool will grow unbounded.<br><br></div><div>There's a couple potential solutions to this.  One would be to allocate a blob of surface states per subpass rather than one for the entire render pass.  Since the number of surface states per subpass is limited by the size of a binding table (~250), this would guarantee an upper bound on the number of surface states that get allocated per-block.  This would probably mean more surface states being allocated but that's not a big deal.<br><br></div><div>Another option would be to make the block pool so that it can have different block sizes on the different ends of the pool.  We could continue to allocate whatever size blocks we want for binding tables but would be able to bump the surface state block size up to something absurd such as 1MiB.  It would still have a hard limit but if your Vulkan application is using a render pass with 8k attachments, something is probably wrong.<br></div></div></div></div>