On 06/04/2014 04:15 PM, Ilia Mirkin wrote: > On Wed, Jun 4, 2014 at 6:42 PM, Ian Romanick <i...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
