On Wed, Mar 24, 2010 at 9:09 PM, Henri Verbeet <[email protected]> wrote: > On 24 March 2010 20:03, Roderick Colenbrander <[email protected]> wrote: >> I have experimented a bit with the design (intially only color fill >> since that's quite independent). Note this is just a proof of concept >> (some of the helper functions would become separate patches). This >> patch is the current code in the new form. In a later stage an FBO >> blit_shader can be added which can call the FBO based color fill but >> that's quite easy to extend later on. At this point no context setup >> is needed since the helpers already do that but after this is all >> over, they could be moved over to this framework to make it a bit >> nicer. >> > The general direction looks ok. As a first step you probably don't > even need to call the functions through struct blit_shader though. >
I have worked on some more parts of the blit_shader code. Before I clean it up and submit it, I'm posting it here to see if the direction is ok. Below I summarize each patch and also mention when I think a patch is ready (if that's the case more thorough feedback is welcome). 0007 - Renames is_color_fixup_supported to blit_supported and adds some parameters. I think this patch is ready. 0008 - Adds a blit method to arbfp_blit and limits the arbfp shader to complex blits (yuv/p8); for now this disables hw accelerated 8-bit color keying but that can easily be readded once the transition is over by modifying the p8 shader. I think this patch is ready. (I'm not that happy with the name arbfp_blit_surface but I had to use something else because arbfp_blit won't work and arbfp_blit_blit is a bit silly I think) 0009 - This moves the remaining 'offscreen -> render target' code to ffp_blit. I have thought long about whether to move the color key flag voodoo over as well. You can reason that it is up to the blit_shader how and if it implements color keying. If you move the code over, you would need some of the DDBLTFX information in the blit_shader (either through a parameter or some surface variable). I'm not sure if we want to go that way. I think it is better to leave the voodoo in one place. Later on I want to use it for the p8 arbfp code as well. As mentioned in a next patch the moved code, should likely become a helper function, so that ffp_blit.blit can decide whether to call 'ffp_blit_offscreen_to_render_target' or the fb_copy* calls. 0010 - Adds an initial fbo_blit implementation which supports blitting. I think this patch is ready but I'm only not sure where we want to have the fbo_blit code. Right now stretch_rect_fbo is in device.c (and the same for fbo color fill but Henri said that we shouldn't use it). I would say that the code should be in surface.c unless it is fine to use stretch_rect_fbo (some types have to be unified to be able to get rid of casts) as a helper function. 0011 - This patch is work in progress and moves the fb_copy_* calls to ffp_blit. It adds initial selection logic to ffp_blit.blit to decide which helper function to call. The logic tries to use SFLAG_SWAPCHAIN and WINED3DUSAGE_RENDERTARGET which I think works to get rid of some of the swapchain/surface checks which are around in BltOverride. Note this patch patch won't compile, so I also haven't tested it ;) If this work is in the right direction, I plan to work on the blitter selection next. I would apply it to 'render_target -> texture' and 'offscreen -> render_target'. Thanks, Roderick
blit_shader_patches.tar.gz
Description: GNU Zip compressed data
