On Tue, Jun 13, 2017 at 1:40 PM, Jose Fonseca <jfons...@vmware.com> wrote: > On 12/06/17 22:56, Marek Olšák wrote: >> >> On Mon, Jun 12, 2017 at 10:43 PM, Jose Fonseca <jfons...@vmware.com> >> wrote: >>> >>> On 12/06/17 21:25, Marek Olšák wrote: >>>> >>>> >>>> On Mon, Jun 12, 2017 at 9:51 PM, Jose Fonseca <jfons...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
