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. > > I'll push the patches intact, but one thing we need to start thinking > about is the mix of code in the util/ directory -- there's some stuff in > there that's only legal/useful for state-trackers, some that's likewise > only legal for drivers, and a lot that is valid everywhere. At some > stage we want to split that up.
I plan to split the os specific stuff out soon. I'm referring to memory allocation. debug printing, file abstraction, etc. All stuff that is not Gallium related and is needed everywhere. 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
