On 17 February 2017 at 04:43, Sebastian Lackner sebastian@fds-team.de wrote:
BTW: Is someone currently working on wined3d_buffer_map? To me it looks like there are multiple issues related to location handling in there.
The code certainly has issues, at least in part that's because it mostly predates the current resource location management scheme.
- For mappings without !(flags & WINED3D_MAP_READONLY), shouldn't the code invalidate the sysmem location, to force a download when it is required later?
If you're referring to the case I think you're referring to, no, because WINED3D_BUFFER_PIN_SYSMEM isn't set and the system memory location has been evicted.
- In the "Falling back to doublebuffered operation." case with !(flags & WINED3D_MAP_READONLY) the buffer location is never invalidated, which means no upload will happen. For testing purposes, this can be triggered by replacing the if conditions and running d3d9 visual tests. Adding something like: buffer->locations &= ~WINED3D_LOCATION_BUFFER; fixes it (using a function would add the modified range twice).
That path should only be reachable for read-only maps, in which case there's nothing to upload.
The general issue that the code is overly complicated and hard to reason about is certainly true though.