My patch should fix those too. Since this is glBlitFramebuffer, it shouldn't need any gallium states, so the st_validate_state call is mostly useless and all unnecessary operations should skipped. Sadly, there is little interest in such optimizations nowadays, but I understand that people are busy with more important things.
Marek On Fri, Jun 26, 2015 at 5:44 PM, Ilia Mirkin <[email protected]> wrote: > 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
