[Mesa-dev] [PATCH] intel: Fix render-to-texture in non-FinishRenderTexture cases.

[Ian Romanick]

On 05/08/2013 09:59 AM, Eric Anholt wrote:
> Ian Romanick <idr at 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.