On 05/08/2013 09:59 AM, Eric Anholt wrote:
Ian Romanick <i...@freedesktop.org> writes:
On 05/07/2013 03:53 PM, Eric Anholt wrote:
With EGL_KHR_gl_renderbuffer_iamge, we have the ability to render to
^^^^^
image
renderbuffers that are also textures, so the core Mesa FinishRenderTexture
hook doesn't get called. That hook also wasn't called in various cases
within the driver where we'd update texture contents using the render
cache (like glCopyTexSubImage) that resulted in
intel_batchbuffer_emit_mi_flush().
To fix it, track a set of rendered-to BOs in our context, which is
cleared at batch wrap or emit_mi_flush time, and do an emit_mi_flush if
one of our textures is in that set.
That sounds like an optimal (if complex) solution for the EGLimage.
When Ken described the bug to me, I was envisioning a simpler fix: if a
renderbuffer is attached to an EGLimage, use FinishRenderTexture. Out
of curiosity, do you think that would have also worked? It seems like
that would be cheaper in the non-EGLimage case, though it doesn't sound
like it matters.
When would you do that? After every draw call? There's no signal that
"now's the time it's going to be used as a texture".
Right now FinishRenderTexture is potentially called when the FBO is
unbound. I think that should be sufficient. There are already no
guarantees (excluding GL_NV_texture_barrier) about synchronization
during potential feed-back loops, and this shouldn't make that any worse.
I don't see anything in any of the relevant EGL extensions, but issue #2
in GL_OES_EGL_image suggests that it may be okay.
Anyway... Your patch should be fine. I was just wondering if you had
considered other strategies.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
