On Tue, 20 Nov 2018 at 18:28, Paul Gofman gofmanp@gmail.com wrote:
On 11/20/18 17:38, Henri Verbeet wrote:
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?
I think the patch is fine the way it is, I'm running the tests right now.
The case I was thinking of above is when the map binding location is current because the application is actually mapping the texture, rather than because it ends up being the same as the default location. We can't really distinguish those two cases right now.