[Mesa-dev] [PATCH] i965/hiz: Don't bind GL_DRAW_FRAMEBUFFER on GLES

[Chad Versace]

On 01/12/2012 02:50 PM, Ian Romanick wrote:
> On 01/12/2012 05:44 AM, Neil Roberts wrote:
>> Hi,
>>
>> Chad Versace<chad.versace at linux.intel.com>  wrote:
>>
>>> [chad]: Make comments more concise. Change the if-condition to be
>>> compatible with a core context, which may not advertise old extensions.
>>
>> The change to the if-condition breaks the patch. The problem is this bit
>> of code in fbobject.c:
>>
>> static struct gl_framebuffer *
>> get_framebuffer_target(struct gl_context *ctx, GLenum target)
>> {
>>     switch (target) {
>>     case GL_DRAW_FRAMEBUFFER:
>>        return ctx->Extensions.EXT_framebuffer_blit&&  ctx->API == API_OPENGL
>>      ? ctx->DrawBuffer : NULL;
>>     ...
>>     }
>> }
>>
>> That limits using GL_DRAW_FRAMEBUFFER to OpenGL even if the
>> GL_EXT_framebuffer_blit extension is supported by the context. As I
>> mentioned in the bug report, maybe it would be better to just remove
>> that check? Then the patch wouldn't be needed anyway.
> 
> We still want the check for now.  We don't expose any of this functionality in ES contexts, so we want to generate errors for applications that accidentally do the wrong thing.
> 
> However, after 8.0 ships we want to expose GL_ANGLE_framebuffer_blit (or a similar extension) which has this functionality.  We talked about enabling it now, but we don't have any ES tests, so I don't want to enable it without testing.
> 
> For now, I think we should take Neil's original patch, and we'll clean things up later.
> 

When I made my change, I wrongly assumed that the extension bit for EXT_framebuffer_blit was
off in an ES context, since the extension doesn't exist there. But that's not how Mesa's
extension works, which I should have known; I plumbed it before.

Neil, your original patch is pushed and the bug report updated.

----
Chad Versace
chad.versace at linux.intel.com