Restore only modified texture state during virtual context switches

In this patch we track texture state that has been modified
by a virtual context and only restore the modified texture
state during context switches.

The most CPU consuming operations on the GPU thread for
Android are virtual context switches. Previously we would
restore all texture units (there are 32 units on Nexus
7 and Nexus 10) and all applicable targets for every context
switch. With this patch we only restore GL_TEXTURE0 unit and
GL_TEXTURE_2D target most of the time.

BUG=244701

[no sievers, 2013-12-16 19:02:08]

Can't we just dynamically generate dirty state from comparing old vs. new
ContextState during the context switch?
Since we already track all the state, maybe we can avoid going into the
direction of adding another state tracking shim.

[kaanb, 2013-12-17 10:39:46]

On 2013/12/16 19:02:08, sievers wrote:
> Can't we just dynamically generate dirty state from comparing old vs. new
> ContextState during the context switch?
> Since we already track all the state, maybe we can avoid going into the
> direction of adding another state tracking shim.

We cannot use ContextState from gl_gl_api_implementation.cc, we are not allowed
to depend anything under gpu/ from ui/gl/

[Sami, 2013-12-17 18:03:08]

It does seem like we'd want to reuse as much as of the existing gpu state
tracking infrastructure for this as possible. Could we extend the
GLStateRestorer interface to accomplish that?

With the current patch, do we handle cases like this:

MakeCurrent(context1);
BindTexture(GL_TEXTURE_2D, 1);

MakeCurrent(context2);
BindTexture(GL_TEXTURE_2D, 2);

MakeCurrent(context1);
// don't touch GL_TEXTURE_2D -- texture 1 will still get bound by the
restoration code

MakeCurrent(context2);
// sample from GL_TEXTURE_2D without binding anything => texture 1 still bound?

[no sievers, 2013-12-17 18:22:41]

On 2013/12/17 10:39:46, kaanb wrote:
> On 2013/12/16 19:02:08, sievers wrote:
> > Can't we just dynamically generate dirty state from comparing old vs. new
> > ContextState during the context switch?
> > Since we already track all the state, maybe we can avoid going into the
> > direction of adding another state tracking shim.
> 
> We cannot use ContextState from gl_gl_api_implementation.cc, we are not
allowed
> to depend anything under gpu/ from ui/gl/

Well, that can be solved, but I'm not sure if we even have to generate anything.
Can't we just pass old_state into the restorer and make the right decisions?

[Sami, 2013-12-17 18:27:10]

On 2013/12/17 18:22:41, sievers wrote:
> Well, that can be solved, but I'm not sure if we even have to generate
anything.
> Can't we just pass old_state into the restorer and make the right decisions?

We were also talking about doing just-in-time state restoration where we'd make
sure the bindings are correct at the latest possible time, e.g., right before a
draw call. That's much more error prone but also more optimal.

[kaanb, 2013-12-17 19:22:05]

On 2013/12/17 18:27:10, Sami wrote:
> On 2013/12/17 18:22:41, sievers wrote:
> > Well, that can be solved, but I'm not sure if we even have to generate
> anything.
> > Can't we just pass old_state into the restorer and make the right decisions?
> 
> We were also talking about doing just-in-time state restoration where we'd
make
> sure the bindings are correct at the latest possible time, e.g., right before
a
> draw call. That's much more error prone but also more optimal.

How does exposing ContextState as an opaque void* pointer to the VirtualGLApi
class
and passing it to the GLStateRestorerImpl::RestoreState() and casting it to the
correct
type there sound? Within GLStateRestorerImpl::RestoreState() we can compute the
diff as
sievers@ suggested.

[no sievers, 2013-12-17 19:35:10]

On 2013/12/17 19:22:05, kaanb wrote:
> On 2013/12/17 18:27:10, Sami wrote:
> > On 2013/12/17 18:22:41, sievers wrote:
> > > Well, that can be solved, but I'm not sure if we even have to generate
> > anything.
> > > Can't we just pass old_state into the restorer and make the right
decisions?
> > 
> > We were also talking about doing just-in-time state restoration where we'd
> make
> > sure the bindings are correct at the latest possible time, e.g., right
before
> a
> > draw call. That's much more error prone but also more optimal.
> 
> How does exposing ContextState as an opaque void* pointer to the VirtualGLApi
> class
> and passing it to the GLStateRestorerImpl::RestoreState() and casting it to
the
> correct
> type there sound? Within GLStateRestorerImpl::RestoreState() we can compute
the
> diff as
> sievers@ suggested.

You can just fwd declare "class ContextState;". I don't *think* that violates
DEPS.

But why not just pass the other GLStateRestorer or some other known object that
you can then get what you need from in the implementation?

[kaanb, 2013-12-18 14:19:01]

On 2013/12/17 19:35:10, sievers wrote:
> On 2013/12/17 19:22:05, kaanb wrote:
> > On 2013/12/17 18:27:10, Sami wrote:
> > > On 2013/12/17 18:22:41, sievers wrote:
> > > > Well, that can be solved, but I'm not sure if we even have to generate
> > > anything.
> > > > Can't we just pass old_state into the restorer and make the right
> decisions?
> > > 
> > > We were also talking about doing just-in-time state restoration where we'd
> > make
> > > sure the bindings are correct at the latest possible time, e.g., right
> before
> > a
> > > draw call. That's much more error prone but also more optimal.
> > 
> > How does exposing ContextState as an opaque void* pointer to the
VirtualGLApi
> > class
> > and passing it to the GLStateRestorerImpl::RestoreState() and casting it to
> the
> > correct
> > type there sound? Within GLStateRestorerImpl::RestoreState() we can compute
> the
> > diff as
> > sievers@ suggested.
> 
> You can just fwd declare "class ContextState;". I don't *think* that violates
> DEPS.
> 
> But why not just pass the other GLStateRestorer or some other known object
that
> you can then get what you need from in the implementation?

Ok, I have a new patch here: https://codereview.chromium.org/118203002/
Let's continue the discussion there.