Hi,
On 29 June 2015 at 07:53, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Fri, 26 Jun 2015 14:27:48 +0100
> Daniel Stone <dan...@fooishbar.org> wrote:
>> 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
Yes, I don't think Weston would gain anything from caching request
snippets. As I said, it's not applicable to us, but I can certainly
imagine usecases _for other non-Weston users_ where req snippets would
come in handy, so I added it to the API as another way to go about
things. drmModeAtomic{Duplicate,Merge} are not relevant to Weston.
> 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.
Assuming this about Duplicate/Merge, I'll just leave it here, since we
agree that it's an inappropriate API to use for Weston, which is why I
haven't used it for Weston.
Cheers,
Daniel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
