[Mesa-dev] [PATCH 1/7] gallium: add pipe_blend_state::srgb_enable and the CAP

[Marek Olšák]

On Tue, Jun 13, 2017 at 1:40 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> On 12/06/17 22:56, Marek Olšák wrote:
>>
>> On Mon, Jun 12, 2017 at 10:43 PM, Jose Fonseca <jfonseca at vmware.com>
>> wrote:
>>>
>>> On 12/06/17 21:25, Marek Olšák wrote:
>>>>
>>>>
>>>> On Mon, Jun 12, 2017 at 9:51 PM, Jose Fonseca <jfonseca at vmware.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> How does this help exactly?
>>>>>
>>>>> Are applications actually rendering to the same FBO w/ and w/o SRGB
>>>>> decoding?
>>>>>
>>>>> Or is the problem here GL_SRGB_WRITE state getting spuriously dirtied
>>>>> by
>>>>> the
>>>>> application?
>>>>>
>>>>> And even if they do, why is toggling surface views in framebuffer state
>>>>> so
>>>>> expensive?
>>>>>
>>>>> I don't object per se, but it looks like an unusual thing to optimize
>>>>> for.
>>>>>
>>>>
>>>> set_framebuffer_state is basically a memory barrier. We have different
>>>> caches between FB and textures and we have to flush them when a
>>>> texture is unbound from the framebuffer and set as a sampler view. To
>>>> keep thing simple, set_framebuffer_state is the barrier. When we
>>>> change the blend state, the barrier is avoided. Note that the barrier
>>>> makes set_framebuffer_state a function that is always GPU-bound.
>>>
>>>
>>>
>>> I see.
>>>
>>> And you're sure that the incoming set_framebuffer_state are not spurious?
>>>
>>> I know cso_context always eliminates redundant
>>> pipe_context::set_framebuffer_state calls, but it is perhaps possible
>>> that
>>> Mesa state tracker is reseting the framebuffer state with different
>>> surface
>>> views, but that in practice are exactly the same as the previous one?
>>>
>>> Like I said, it seems odd apps are doing this: it doesn't make much sense
>>> to
>>> me to change colorspace of the fragments between draws. (Unless some of
>>> the
>>> assets are already in SRGB and the app is trying to be too smart for its
>>> own
>>> good to avoid the sRGB->RGB->sRGB.)  It seems much more likely that these
>>> framebuffer state changes are self-inflicted some where in our stack,
>>> than
>>> something truly demanded by the app.
>>>
>>> And if that's the case and we can fix it, then it would be a better
>>> solution
>>> all around.
>>
>>
>> Yeah the funny part and the reason is that we have a microbenchmark in
>> piglit (drawoverhead) changing this state between draw calls. :)
>>
>> Marek
>>
>
> I couldn't find that piglit microbenchmark.  mesademos has
> src/perf/drawoverhead.c but it doesn't set GL_SRGB_WRITE.  So if fbo is
> changing internally, then it's a perf bug in Mesa state tracker.
>
> Unless it's mimicking something that real apps do, then it's probably better
> to fix the microbenchmark to use a more realistic tests.

If you build piglit, it's in bin/drawoverhead.

You're right that this subtest (switching GL_FRAMEBUFFER_SRGB) is
rather artificial and fairly unlikely to occur with real apps.

Marek