Am 12.10.2015 um 17:23 schrieb Riccardo Bortolato rikyz619@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.
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@gmail.com:
Am 12.10.2015 um 17:23 schrieb Riccardo Bortolato rikyz619@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.
-
Riccardo Bortolato -
Stefan Dösinger