[Mesa-dev] [PATCH] Implement the ARB_clear_texture extension

[Ian Romanick]

On 06/04/2014 04:15 PM, Ilia Mirkin wrote:
> On Wed, Jun 4, 2014 at 6:42 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 06/04/2014 11:12 AM, Neil Roberts wrote:
>>> +
>>> +   ctx->Driver.ClearTexSubImage(ctx,
>>> +                                texImage,
>>> +                                xoffset, yoffset, zoffset,
>>> +                                width, height, depth,
>>> +                                data ? clearValue : NULL);
>>
>> Gallium drivers don't use meta at all, so ctx->Driver.ClearTexSubImage
>> will be NULL in all Gallium drivers.  Until there is a Gallium
>> implementation (Ilia may have done one already...), I don't think we can
>> enable this extension by default.
> 
> Well, the patches I had made just add a pipe->clear_texture callback
> (and implementation for nv50). After discussions spawned by my
> (semi-related) ->clear_buffer addition (for ARB_clear_buffer_object
> acceleration), it seems like it'll take a little more than this --
> I'll also need to unify the existing ->clear_render_target and
> ->clear_depth_stencil functions into one big happy do-everything API
> call.
> 
> However my understanding (I'm a newbie at this, so take with a grain
> of salt) was that a generic implementation was impossible due to the
> need to handle MS textures, and there being no "spec" for how they're
> laid out. e.g. is 4x MS just 4x wider? 4x higher? 2x on both? [And
> non-renderable texture formats present issues as well.]

Yeah... those each present difficulties, but I think they're orthogonal
difficulties.  I don't think there any MS texture formats that are not
renderable.  If that's true, then all the renderable formats can use a
rendering path, and all the non-renderable formats can use a
clear_buffer-like path.  Right?

>   -ilia