On Fri, 26 Jun 2015 14:27:48 +0100 Daniel Stone <dan...@fooishbar.org> wrote:
> Hi, > > On 24 June 2015 at 13:11, Pekka Paalanen <ppaala...@gmail.com> wrote: > > I think the best way to cache state is to let it stay in the kernel, > > and avoid submitting a disable followed by the old state that's already > > there. If we manage that, maintaining cached atomic req pieces in > > weston would be moot. > > Can you expand a bit on what you mean here? Gaining anything from a req snippet cache depends on the need to submit already submitted state again. The only significant reason to do that, that I can imagine, would be if the algorithm unconditionally initialized the req with either that cached state or disabled state. If we avoid unconditionally initializing a req like that, I don't see what we would gain from a req snippet cache. And we can avoid it, because the kernel maintain all state we do not set. I assume the cases where we need to re-program all state are rare enough to not warrant this added code. Therefore, if we only program state that has changed, the cache would be a net cost rather than a win, as we'd (almost) never hit the cache. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
