On 3/5/21 21:36, Henri Verbeet wrote:
On Wed, 3 Mar 2021 at 23:36, Paul Gofman pgofman@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.
As far as I could see we add DDSCAPS_SYSTEMMEMORY for managed texture only if we detected that wined3d does not support the required bind flags. So it is not immediately clear to me why would we want to treat that case differently here, shouldn't we just have draw_texture the same way as for system memory texture without _TEXTUREMANAGE?
- 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.
That was my intention, but now after our discussion on IRC I realize that it is wrong as there are legitimate cases when reference from wined3d is the only reference for ddraw_surface. I will switch the reference counting to draw_texture.