[Mesa-dev] Early calls to st_validate_state

Ilia Mirkin imirkin at alum.mit.edu
Fri Jun 26 08:17:43 PDT 2015


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 <maraeo at gmail.com> 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 <imirkin at alum.mit.edu> 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


More information about the mesa-dev mailing list