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

[Jose Fonseca]

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.

Jose