[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 4/4] wined3d: use stretch_rect_fbo for swapchainless blits
From:       Henri Verbeet <hverbeet () gmail ! com>
Date:       2010-04-29 14:08:14
Message-ID: s2id658b69e1004290708vae0855f1ya91d66f96c6a0181 () mail ! gmail ! com
[Download RAW message or body]

On 29 April 2010 15:38, Roderick Colenbrander <thunderbird2k@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.



[prev in list] [next in list] [prev in thread] [next in thread]