[Mesa-dev] [PATCH 3/4] tnl: Maintain the _WindowMap matrix in TNLcontext v2.

Mathias Fröhlich Mathias.Froehlich at gmx.net
Thu Aug 6 23:46:09 PDT 2015


On Thursday, August 06, 2015 12:32:18 Ilia Mirkin wrote:
> > @@ -182,6 +187,13 @@ _tnl_InvalidateState( struct gl_context *ctx, GLuint new_state )
> >           }
> >        }
> >     }
> > +
> > +   if (new_state & (_NEW_VIEWPORT | _NEW_BUFFERS)) {
> > +      double scale[3], translate[3];
> > +      _mesa_get_viewport_xform(ctx, 0, scale, translate);
> > +      _math_matrix_viewport(&tnl->_WindowMap, scale, translate,
> > +                            ctx->DrawBuffer->_DepthMaxF);
> This appears to crash nouveau_vieux on startup. See
> https://bugs.freedesktop.org/show_bug.cgi?id=91570 . I suspect that
> ctx->DrawBuffer is null. What's the proper way to handle that
> situation -- predicate on a drawbuffer being bound? Or make sure that
> something is bound to the drawbuffer before we call tnl_wakeup?

It looks like nouveau_vieux uses _tnl_InvalidateState for early initialization.
I assume that _mesa_make_current is called later on to set the DrawBuffer
and there the _NEW_BUFFERS flag is set. So, when _tnl_InvalidateState is called
while validating state before the first draw and past a bound draw buffer, we should
get the desired update on the _WindowMap matrix.
So just checking for the presence of the DrawBuffer before grabbing data
from it seems to be safe.

The aim of the change was to move the _WindowMap matrix out of the non tnl drivers
and track it in the tnl module where it is exclusively used today.
At the higher mesa level we did/do not invalidate DrawBuffer related state that early.

One alternative I can see is to call _tnl_InvalidateState without the _NEW_VIEWPORT and
_NEW_BUFFERS flag set instead of _tnl_wakeup in the two nouveau early initialization
code paths in nouveau_swtnl_t.c and nv04_render.c. That should also bring us back to
the original behavior.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150807/cf020507/attachment-0001.html>

More information about the mesa-dev mailing list