On Mon, 2009-12-14 at 03:52 -0800, Keith Whitwell wrote: > On Sun, 2009-12-13 at 15:27 -0800, Marek Olšák wrote: > > Hi Keith, > > > > I've finished the blitter module. It fully implements the clear, > > surface_copy, and surface_fill functions. It properly fallbacks to > > software in case a surface cannot be sampled or rendered to according > > to usage. Copying a stencil buffer always fallbacks unless the > > ignore_stencil parameter (see util_blitter_copy) is set to TRUE. To my > > knowledge, GPUs cannot copy the stencil buffer (not sure if fiddling > > with texture formats can help). It's all documented in u_blitter.h. > > > > The pipe driver can optionally hook up a function to draw a quad > > (blitter_context::draw_quad). I realized that embedding 4 vertices > > into a command stream (AKA immediate mode) is much faster than writing > > them to a vertex buffer due to reduced driver overhead. It might be > > worth to consider adding the draw_quad function to pipe_context. > > > > When working on the blitter, I added the following things to > > util/u_simple_shaders: > > - util_make_fragment_tex_shader has a new parametr tex_target and the > > value should be one of TGSI_TEXTURE_* enums so that it can be used to > > sample from any kind of texture. > > - Added util_make_fragment_tex_shader_writedepth, which writes depth > > sampled from a texture. It's used for copying depth textures. > > - Added util_make_fragment_clonecolor_shader, which copies input > > COLOR[0] to a specified number of render targets. It's used to clear > > MRTs. > > > > Also, I moved the code for converting 2D texture coordinates into > > cubemap texture coordinates from u_gen_mipmap to a new function in > > util/u_texture. > > > > Please review/push. > > > > Once it gets approved, I will send patches with r300g blit support to > > Corbin. With this work, untiling a texture will be as easy as calling > > surface_copy whereas the driver state remains intact (theoretically). > > Marek, > > This all looks great. Many thanks for adding this functionality - I'm > sure we'll be building on it in many ways going forward.
Nice stuff indeed. FWIW, I also think that putting a reasonable functionality bars instead querying the pipe for every little capability will benefit us in the long term. It worked well for vertex processing and hardware unsupported API quirks (via draw module); it's nice to see the same for blits; and I hope this becomes a trend. It not only makes things less complex, having all pipe drivers with similar capabilities is what allows us to plug'n'play pipe drivers; do things like replay a trace of one driver on top of another; perhaps in the future code a drivers that do differential analysis with a reference one, etc. Jose ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
