On 22 August 2013 14:57, Stefan Dösinger stefan@codeweavers.com wrote:
if (volume->locations & WINED3D_LOCATION_DISCARDED)
{
TRACE("Volume previously discarded, nothing to do.\n");
wined3d_volume_invalidate_location(volume, WINED3D_LOCATION_DISCARDED);
}
I don't think the location invalidation here is strictly required, although it probably doesn't hurt much in practice. (I.e., consider the sequence DISCARD, load SYSMEM, load TEXTURE_RGB. There's no real reason the RGB load needs to do an upload from SYSMEM in that case, although it's perhaps not something that's going to happen much in practice either way.)
wined3d_volume_validate_location(volume, WINED3D_LOCATION_SYSMEM);
You could probably just have a wined3d_volume_validate_location(volume, location); at the end of the function and return from the default case instead. That's not something I feel strongly about though.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-08-22 15:33, schrieb Henri Verbeet:
On 22 August 2013 14:57, Stefan Dösinger stefan@codeweavers.com wrote:
if (volume->locations & WINED3D_LOCATION_DISCARDED)
{ + TRACE("Volume previously
discarded, nothing to do.\n"); + wined3d_volume_invalidate_location(volume, WINED3D_LOCATION_DISCARDED); + }
I don't think the location invalidation here is strictly required, although it probably doesn't hurt much in practice. (I.e., consider the sequence DISCARD, load SYSMEM, load TEXTURE_RGB. There's no real reason the RGB load needs to do an upload from SYSMEM in that case, although it's perhaps not something that's going to happen much in practice either way.)
Ya, this is a pretty academic issue. The only situation I can think of that would trigger this is a read-only map of a newly created volume. In this case the application is most likely buggy and writes data and wants it uploaded.
My gut feeling is to keep it the way it is. The combination of a valid location and LOCATION_DISCARDED being set is somewhat unintuitive and I'd prefer to avoid it.