On Wed, Jun 4, 2014 at 9:26 PM, Ian Romanick <i...@freedesktop.org> wrote: > 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?
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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
