As far as immediate verts, why don't we just add support to r300g to switch to immediate mode for small VBOs?
Posting from a mobile, pardon my terseness. ~ C. On Dec 13, 2009 3:28 PM, "Marek Olšák" <[email protected]> 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). Cheers. Marek On Thu, Dec 10, 2009 at 6:23 PM, Keith Whitwell <[email protected]> wrote: > On Thu, 2009-12-10 at 01:52 -0800, Marek Olšák wrote: >> Keith, >> >> I've taken your comment into consideration and started laying out a >> new simple driver module which I call Blitter. The idea is to provide >> acceleration for operations like clear, surface_copy, and >> surface_fill. The module doesn't depend on a CSO context, instead, a >> driver must call appropriate util_blitter_save* functions to save CSOs >> and a blit operation takes care of their restoration once it's done. >> >> I attached a patch illustrating the idea with the clear implemented >> and a working example of usage, but it's not ready to get pushed yet. >> >> Please tell me what you think about it. > > Marek, > > This looks good to me. It looks like this approach keeps the > implementation entirely on the driver side of the interface, which is > what I was hoping for. > > I had assumed that doing this type of operation in the driver would > require assistance "from above" for saving and restoring state. But it > seems like you've been able to do without that, which is nice. > > Let me know how it progresses. > > Keith > > ------------------------------------------------------------------------------ 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
------------------------------------------------------------------------------ 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
