Re: [PATCH 5/7] wined3d: introduce a new wined3d_texture_blt function

[Stefan Dösinger]

> Am 12.10.2015 um 17:23 schrieb Riccardo Bortolato <rikyz619(a)gmail.com>:
>
> +HRESULT CDECL wined3d_texture_blt(struct wined3d_texture *dst_texture, unsigned int dst_idx, const RECT *dst_rect_in,
> +        struct wined3d_texture *src_texture, unsigned int src_idx, const RECT *src_rect_in, DWORD flags,
> +        const WINEDDBLTFX *fx, enum wined3d_texture_filter_type filter)
> I am not convinced that this is how we want blits to work. I was looking into some blit cleanups myself a few months ago, but got stuck in swapchain related sidequests, mostly to get rid of wined3d_swapchain_blit.

My thinking re blitting is that we want to separate things into d3d9-style StretchRect (does color conversion, multisample resolve, stretching, color keying, ...) and CopySubresourceRegion (does sysmem<->vidmem transfers). Mapping d3d8+ methods on top of these calls is pretty simple. ddraw is trickier though and I cannot promise yet that it will work. Many things can be solved with staging resources, e.g. to split a color keyed sysmem -> vidmem blit into a copy_sub_resource_region upload and StretchRect color key blit.

(StretchRect will need to be a bit more powerful than what d3d9 / d3d10 allow. At least we want sysmem<->sysmem blits supported by it).

Henri was arguing for a more powerful blitter in wined3d if I understood him right, that would also be capable of handling the upload of converted surfaces (wined3d_format_texture_info.convert in utils.c). My concern is that this kind of blitter will turn into a god object that's more powerful than what we need (e.g. we don't need signed RGB -> unsigned RGB conversion while transfering from a sysmem vertex buffer to a vidmem volume texture), but I didn't get very far in proving that my alternative approach works.

[PATCH 5/7] wined3d: introduce a new wined3d_texture_blt function

[Riccardo Bortolato]

For reference, here's what I intend to do to accomodate ddraw (I have
a number of patches in github):

diff --git a/dlls/wined3d/texture.c b/dlls/wined3d/texture.c
index 7b6f651..319a0a0 100644
--- a/dlls/wined3d/texture.c
+++ b/dlls/wined3d/texture.c
@@ -1436,13 +1436,16 @@ HRESULT CDECL wined3d_texture_blt(struct
wined3d_texture *dst_texture, unsigned
         const WINEDDBLTFX *fx, enum wined3d_texture_filter_type filter)
 {
     struct wined3d_resource *dst_resource =
wined3d_texture_get_sub_resource(dst_texture, dst_idx);
-    struct wined3d_resource *src_resource =
wined3d_texture_get_sub_resource(src_texture, src_idx);
+    struct wined3d_resource *src_resource = NULL;

-    if (!dst_resource || !src_resource)
+    if (!dst_resource)
         return WINED3DERR_INVALIDCALL;

+    if (src_texture)
+        src_resource = wined3d_texture_get_sub_resource(src_texture, src_idx);
+
     return wined3d_surface_blt(surface_from_resource(dst_resource),
dst_rect_in,
-        surface_from_resource(src_resource), src_rect_in, flags, fx, filter);
+        src_resource ? surface_from_resource(src_resource) : NULL,
src_rect_in, flags, fx, filter);
 }

Ciao,
Riccardo

2015-10-13 11:37 GMT+02:00 Stefan Dösinger <stefandoesinger(a)gmail.com>:
> > Am 12.10.2015 um 17:23 schrieb Riccardo Bortolato <rikyz619(a)gmail.com>:
> >
> > +HRESULT CDECL wined3d_texture_blt(struct wined3d_texture *dst_texture, unsigned int dst_idx, const RECT *dst_rect_in,
> > +        struct wined3d_texture *src_texture, unsigned int src_idx, const RECT *src_rect_in, DWORD flags,
> > +        const WINEDDBLTFX *fx, enum wined3d_texture_filter_type filter)
> > I am not convinced that this is how we want blits to work. I was looking into some blit cleanups myself a few months ago, but got stuck in swapchain related sidequests, mostly to get rid of wined3d_swapchain_blit.
>
> My thinking re blitting is that we want to separate things into d3d9-style StretchRect (does color conversion, multisample resolve, stretching, color keying, ...) and CopySubresourceRegion (does sysmem<->vidmem transfers). Mapping d3d8+ methods on top of these calls is pretty simple. ddraw is trickier though and I cannot promise yet that it will work. Many things can be solved with staging resources, e.g. to split a color keyed sysmem -> vidmem blit into a copy_sub_resource_region upload and StretchRect color key blit.
>
> (StretchRect will need to be a bit more powerful than what d3d9 / d3d10 allow. At least we want sysmem<->sysmem blits supported by it).
>
> Henri was arguing for a more powerful blitter in wined3d if I understood him right, that would also be capable of handling the upload of converted surfaces (wined3d_format_texture_info.convert in utils.c). My concern is that this kind of blitter will turn into a god object that's more powerful than what we need (e.g. we don't need signed RGB -> unsigned RGB conversion while transfering from a sysmem vertex buffer to a vidmem volume texture), but I didn't get very far in proving that my alternative approach works.