On Tue, 23 Oct 2018 at 20:39, Matteo Bruni mbruni@codeweavers.com wrote:
Signed-off-by: Matteo Bruni mbruni@codeweavers.com
dlls/d3d8/buffer.c | 4 ++++ dlls/d3d8/device.c | 2 ++ dlls/d3d8/texture.c | 6 ++++++ dlls/d3d9/buffer.c | 4 ++++ dlls/d3d9/device.c | 2 ++ dlls/d3d9/texture.c | 6 ++++++ dlls/ddraw/surface.c | 1 + dlls/wined3d/buffer.c | 2 +- dlls/wined3d/device.c | 10 ++++++---- dlls/wined3d/resource.c | 3 ++- dlls/wined3d/texture.c | 10 ++++++---- dlls/wined3d/utils.c | 2 ++ dlls/wined3d/wined3d_private.h | 5 ----- include/wine/wined3d.h | 3 ++- 14 files changed, 44 insertions(+), 16 deletions(-)
Well, maybe. A few questions though:
- You had tests, right? Does this really make sense for textures as well? - What is the conceptual model? I.e., after this series, what is the difference between a D3DPOOL_SYSTEMMEM and a D3DPOOL_MANAGED resource? - Does it really make sense that D3DPOOL_MANAGED resources are evicted on wined3d_device_evict_managed_resources(), but D3DPOOL_SYSTEMMEM resources are potentially kept on the GPU?