<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 7, 2015 at 2:46 AM, Mathias Fröhlich <<a href="mailto:Mathias.Froehlich@gmx.net" target="_blank">Mathias.Froehlich@gmx.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div style="font-family:'Monospace';font-size:9pt;font-weight:400;font-style:normal"> Hi, 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 > <a href="https://bugs.freedesktop.org/show_bug.cgi?id=91570" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=91570</a> . 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.</div></blockquote><div> </div><div>That seems like a bit of a hack. If you think it's OK, I'm just going to introduce the DrawBuffer check. Brian, does that seem OK to you? I'm mostly unfamiliar with the TnL module, its APIs, and when/how they're supposed to be used. But nouveau_vieux calls tnl_wakeup right in its context creation pass. nv04/nv05 don't have hwtnl at all, nv10+ have it, but it has various limitations, with which we end up using swtnl.</div><div> </div><div> -ilia</div></div></div></div>