So, for adreno, clears are basically just normal draws. So I've been meaning to get rid of a bunch of generation specific hand-rolled clear draw code. I got more motivated when I realized a bunch more stuff would need to be fixed up to make MSAA work if I kept the hand-rolled clear path.
The problem with using u_blitter's clear path as-is is that it is measurably slower on adreno. We *really* want to use a uniform for the clear color and pre-baked VBOs. Versus passing everything thru the VS. I thought about changing u_blitter (but apparently that might be slower on other hw), or making u_blitter support both cases. But instead went the route of exposing more of the u_blitter internal APIs so they could be re-used from driver specific blit code. This lets me re-use the shaders and pre-baked VBOs that I also use for GMEM->MEM blits (which could not reasonably re-use a generic u_blitter path). So I end up re-using u_blitter's state restore and some of the common clear state setup, but doing the VBO/shader/etc state setup myself in terms of the pipe_context API (so that it is generation independent). Rob Clark (6): gallium/u_blitter: export some functions gallium/u_blitter: add helper to save FS const buffer state gallium/u_blitter: split out a helper for common clear state freedreno: support for using generic clear path freedreno/a3xx: use generic clear path freedreno/a4xx: use generic clear path src/gallium/auxiliary/util/u_blitter.c | 193 ++++++++++-------- src/gallium/auxiliary/util/u_blitter.h | 29 +++ src/gallium/drivers/freedreno/a3xx/fd3_context.c | 3 +- src/gallium/drivers/freedreno/a3xx/fd3_draw.c | 201 +------------------ src/gallium/drivers/freedreno/a4xx/fd4_context.c | 3 +- src/gallium/drivers/freedreno/a4xx/fd4_draw.c | 216 +-------------------- src/gallium/drivers/freedreno/freedreno_draw.c | 62 ++++++ src/gallium/drivers/freedreno/freedreno_resource.c | 20 +- src/gallium/drivers/freedreno/freedreno_resource.h | 4 + 9 files changed, 223 insertions(+), 508 deletions(-) -- 2.7.4 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev