On 11/20/18 17:38, Henri Verbeet wrote:
On Tue, 20 Nov 2018 at 17:39, Paul Gofman gofmanp@gmail.com wrote:
It gets WINED3D_LOCATION_SYSMEM right at initialiaztion and this location is never used again anywhere but in the fast texture load code path under consideration (which ultimately prefers the sysmem location). Application never tries to map it.
Ah yes, that would do it. I think ideally we'd fix that as well. There's a somewhat theoretical concern that for e.g. a mappable rendertarget or default pool offscreen plain surface it may be advantageous to use the download path as well. I'm not sure how much we care about those cases.
I am not sure I fully understand. The case was that mappable render target was taking the download path, and that was causing performance regression due to downloading texture to system memory while it was not actually used there. Should I maybe use texture download_count to refine the condition of taking download path? The thing is though download_count is not currently incremented in texture2d_load_location() (only in texture1d_load_location() and texture3d_load_location(). This should probably be changed too in this case?