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.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
