On 20 April 2017 at 16:01, Masanori Kakura kakurasan@gmail.com wrote:
v2 - Use array
- Regions are stored in struct wined3d_texture
- Reuse old region if possible
v3 - Update Wine d3d8 test
- Get rid of "Ignoring dirty_region" FIXME in wined3d_texture_add_dirty_region()
Signed-off-by: Masanori Kakura kakurasan@gmail.com
dlls/d3d8/tests/visual.c | 10 ++--- dlls/d3d9/tests/visual.c | 10 ++--- dlls/wined3d/cs.c | 51 +++++++++++++++++++++- dlls/wined3d/device.c | 6 +++ dlls/wined3d/texture.c | 97 ++++++++++++++++++++++++++++++++++++++++-- dlls/wined3d/wined3d_private.h | 9 +++- 6 files changed, 167 insertions(+), 16 deletions(-)
Do you have any thoughts on the interactions with the resource location management?
Thanks for reviewing.
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.
On 21 April 2017 at 16:05, Masanori Kakura kakurasan@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@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.
-
Henri Verbeet -
Masanori Kakura