On Wed, Apr 28, 2010 at 2:56 PM, Henri Verbeet hverbeet@gmail.com wrote:
On 28 April 2010 14:29, Roderick Colenbrander thunderbird2k@gmail.com wrote:
- /* Early sort out of cases where no render target is used */
- if (!dstSwapchain && !srcSwapchain
- && src_surface != device->render_targets[0]
- && dst_surface != device->render_targets[0])
- {
- if (fbo_blit_supported(&device->adapter->gl_info, BLIT_OP_BLIT,
- &src_rect, src_surface->resource.usage, src_surface->resource.pool, src_surface->resource.format_desc,
- &dst_rect, dst_surface->resource.usage, dst_surface->resource.pool, dst_surface->resource.format_desc))
- {
- stretch_rect_fbo(device, src_surface, &src_rect, dst_surface, &dst_rect, Filter);
- return WINED3D_OK;
- }
- TRACE("No surface is render target, not using hardware blit.\n");
- return WINED3DERR_INVALIDCALL;
- }
You might as well try FBO blits first, before doing most of the other checks. That's how it's eventually supposed to work anyway, and you could remove the other strecth_rect_fbo() calls in that case. That does depend on fbo_blit_supported() working properly, of course.
I had a look at the code and it looks like all the swapchain related calls don't affect FBOs but some questions though. First of I will write tests before I attempt such a risky patch which would improve test coverage of untested parts of BltOverride and which also test Blt/StretchRect more thoroughly.
} else if(dstSwapchain && srcSwapchain) { FIXME("Implement hardware blit between two different swapchains\n"); It looks like this case would work fine using stretch_rect_fbo. In the end it comes down to binding two textures to an FBO and a blit which works because the different swapchains are sharing lists. Corect me if I'm wrong since I don't know the subtle details.
} else if(dstSwapchain && dstSwapchain == srcSwapchain) { FIXME("Implement hardware blit between two surfaces on the same swapchain\n"); return WINED3DERR_INVALIDCALL; This case is for swapchain blits other than back->front. stretch_rect_fbo should be able to handle this properly except for overlaps because BlitFramebuffer doesn't support overlaps. This is no issue for StretchRect which doesn't support this either but Blt surely does (at least in some cases, so more tests are needed). Such a case could be supported by drawing in multiple passes or by just disallowing this but for that I need swapchain information in 'blit_supported'.
Information about swapchains might be needed in blit_supported anyway for ffp_blit_supported. A lot of swapchain related cases (two were shown some lines up) are not supported in the ffp backend (and perhaps also in the arbfp one later on ). Some of the cases can be fixed but I fear some cases can't be. What do you think? I hope we don't have to pass variables telling that src / dst are on a swapchain and whether they are on the same.
Roderick