Yeah, but there are a whole bunch of places, non-blit-related, where we call st_validate_state that will hit this same problem.
On Fri, Jun 26, 2015 at 11:43 AM, Brian Paul <[email protected]> wrote: > If we really do need to call _mesa_update_state() for this, I think the > right place would be in _mesa_blit_framebuffer(), not in the state tracker. > > -Brian > > > > On 06/26/2015 09:17 AM, Ilia Mirkin wrote: >> >> 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
