[v3 PATCH 1/2] wined3d: Add dirty region tracking.

[Henri Verbeet]

On 21 April 2017 at 16:05, Masanori Kakura <kakurasan at gmail.com> wrote:
>> Do you have any thoughts on the interactions with the resource
>> location management?
>
> Unfortunately no.
> I need to learn about the "resource location management" but don't know
> how to learn this, sorry.

In short, we keep track of what "locations" of a resource are current,
where "locations" are the various WINED3D_LOCATION_* constants. E.g.
after mapping a texture to update it WINED3D_LOCATION_SYSMEM might be
current, and in order to texture from it we'd have to load it into
WINED3D_LOCATION_TEXTURE_RGB. For textures, the functions involved in
this are primarily wined3d_texture_validate_location(),
wined3d_texture_invalidate_location(),
wined3d_texture_prepare_location() and
wined3d_texture_load_location().

The issue then becomes what the meanings of "locations" in struct
wined3d_texture_sub_resource and "dirty_regions" in struct
wined3d_texture are with respect to each other. E.g., suppose a
texture has WINED3D_LOCATION_BUFFER set, two dirty areas and we're
calling wined3d_texture_load_location() for WINED3D_LOCATION_DRAWABLE.
What would wined3d_texture_load_location() need to do to load the
location? Alternatively, is there a reason such a situation can't
occur?

The current patch set sidesteps the issue somewhat by only using the
dirty areas for choosing what to upload in
wined3d_device_update_texture(), but one of the implications is that
we potentially first redundantly upload the entire destination texture
to the GPU, only to overwrite it with parts of the source texture.


On 20 April 2017 at 16:01, Masanori Kakura <kakurasan at gmail.com> wrote:
> diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h
> index cd90eb8a41..f56c2763c9 100644
> --- a/dlls/wined3d/wined3d_private.h
> +++ b/dlls/wined3d/wined3d_private.h
> @@ -2902,6 +2902,9 @@ struct wined3d_texture
>      unsigned int row_pitch;
>      unsigned int slice_pitch;
>
> +    struct wined3d_box *dirty_regions;
> +    SIZE_T dirty_regions_size, dirty_regions_count;
Actually, I think this would mishandle cube textures. I.e., I think
dirty regions should also record the layer they apply to.