[Mesa-dev] Early calls to st_validate_state

[Marek Olšák]

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 <imirkin at alum.mit.edu> 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 <brianp at vmware.com> 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 <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
>>
>>