[PATCH 4/4] wined3d: use stretch_rect_fbo for swapchainless blits

Henri Verbeet hverbeet at gmail.com
Thu Apr 29 09:08:14 CDT 2010


On 29 April 2010 15:38, Roderick Colenbrander <thunderbird2k at gmail.com> wrote:
>   } 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.
>
In principle surfaces that are on a swapchain are onscreen buffers
like GL_FRONT and GL_BACK. You can make that work between different GL
contexts, but it involves reading back at least one of them into a
texture. The exception is when we're rendering the backbuffer
offscreen, because in that case at least the backbuffers are textures
as well.

>    } 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'.
>
Well, overlaps can only happen if the source and destination surface
are the same, that doesn't have much to do with being on the same
swapchain. A case where you can have different surfaces on the same
swapchain that aren't the front and back buffers would be a blit
between different backbuffers. Multiple backbuffers is something
that's currently unimplemented though.

> 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.
>
Multiple swapchains is something that you can probably implement by
switching contexts and downloading one of the surfaces into a texture
in the worst case. You can probably avoid overlapped blits by checking
for them in the caller and making them a separate blit operation.
Worst case you can do those by downloading into a separate texture
first as well, although there may be a performance consideration to
make as well.



More information about the wine-devel mailing list