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

[Ilia Mirkin]

On Wed, Jun 4, 2014 at 9:26 PM, Ian Romanick <idr at freedesktop.org> wrote:
> 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?

Yup, they are orthogonal indeed. But it was difficult to do in a
generic fashion (aka I couldn't quickly come up with a way to do it).
e.g. all the clear_buffer stuff is expecting PIPE_BUFFER resources (I
forget what it's called in GL-land) that are linear as opposed to the
miptree + tiled setups (although perhaps non-renderable formats are
always linear?) TBH I haven't really thought that hard about the
issues, but it does seem that they need to be thought about :) And the
piglit tests for it are missing, which is a quick way of verifying
that these issues are at least somewhat covered. (This is where I
stopped working on the extension -- couldn't quite figure out how to
operate GL to do the things I wanted.)

  -ilia