[PATCH 04/11] ddraw: Create the second texture for system memory bindable surfaces.
Henri Verbeet
hverbeet at gmail.com
Fri Mar 5 12:36:50 CST 2021
On Wed, 3 Mar 2021 at 23:36, Paul Gofman <pgofman at codeweavers.com> wrote:
> +static void ddraw_surface_create_draw_texture(struct ddraw_surface *surface)
> +{
> + DDSURFACEDESC2 *desc = &surface->surface_desc;
> + struct wined3d_resource *draw_texture_resource;
> + struct wined3d_resource_desc wined3d_desc;
> + unsigned int i, layer_count, level_count;
> + struct wined3d_texture *draw_texture;
> + struct ddraw_surface *parent;
> + unsigned int bind_flags;
> + HRESULT hr;
> +
> + if (!(desc->ddsCaps.dwCaps & DDSCAPS_SYSTEMMEMORY))
> + return;
> +
Does that check do the right thing? Note that we add
DDSCAPS_SYSTEMMEMORY for managed textures, but these still have
WINED3D_RESOURCE_ACCESS_GPU set.
> + if (FAILED(hr = wined3d_texture_create(surface->ddraw->wined3d_device, &wined3d_desc, layer_count,
> + level_count, 0, NULL, NULL,
> + &ddraw_null_wined3d_parent_ops, &draw_texture)))
> + {
> + WARN("Failed to create wined3d texture, hr %#x.\n", hr);
> + return;
> + }
> +
Passing "ddraw_null_wined3d_parent_ops" for the "draw" texture here,
and "ddraw_texture_wined3d_parent_ops" for the other texture, means
that the draw texture being referenced by wined3d won't prevent the
ddraw surface/texture from being released.
More information about the wine-devel
mailing list