So that obviously avoids the crash. I guess I was unsure if that was the right way forward. The way that I understand it, there's "direct" state in the context, and there's derived state. And _mesa_update_state() will update the derived state. Since the various st atoms use derived state, doesn't it make sense to first just call _mesa_update_state?
In nouveau, we also have a parameter which allows you to do partial state validations, i.e. a mask on the dirty flag to only flush certain things out. Not sure if that'd be helpful here. -ilia On Fri, Jun 26, 2015 at 5:02 AM, Marek Olšák <[email protected]> wrote: > I think the best way is not to do anything if one of the shaders is > NULL. Just like my patch that I just sent. > > Marek > > On Fri, Jun 26, 2015 at 3:04 AM, Ilia Mirkin <[email protected]> wrote: >> Hello, >> >> A user reported a crash in wine in finalize_textures (called via >> st_validate_state). In this particular case it was happening through >> st_BlitFramebuffer (piglit test sent), but there are a number of >> callsites of st_validate_state from st/mesa. >> >> The reason it dies is that the fragment program isn't specified. Of >> course if that assumption were relaxed, it'd just crash later on in >> the process. Even though we specify _MaintainTexEnvProgram, that only >> gets bound somewhere down the line. >> >> One solution, which solved a number of different crashes for this user >> was to call _mesa_update_state(ctx) when making a context current for >> the first time. This normalizes a bunch of state, including setting >> the fragment/vertex programs which avoids the crash. Is this the right >> solution? >> >> Another thought I had was to call _mesa_update_state() from >> st_validate_state directly -- all the various state updates rely on >> mesa state being reasonable, and it seems to make sense to first flush >> those changes (which might e.g. update the currently-bound program, or >> all sorts of other things), and only then process the st's updates. >> >> However I'm unfamiliar with the reasoning behind the current system, >> so perhaps I'm also just missing something. Thoughts welcome. >> >> -ilia _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
