This got sidetracked quite a bit already and I'm going to make it worse. Sorry...
2017-04-18 21:31 GMT+02:00 Stefan Dösinger stefandoesinger@gmail.com:
Am 2017-04-18 um 19:44 schrieb Henri Verbeet:
On 18 April 2017 at 18:25, Matteo Bruni matteo.mystral@gmail.com wrote:
Either way, I just realized that something like this can be potentially used to accelerate (partial) texture updates with CSMT, similarly to e.g. buffers updates in Stefan's patchset. In general it makes texture uploads resemble buffers, which seems like a good thing.
I think that's no surprise to you. Any plan to explore this idea through?
No concrete plan.
One thing that made matters easier in buffers is that we only had two locations to deal with. The sysmem location would always have the entire content and the buffer location may need a partial or complete update. With textures you have multiple locations. You could e.g. render to the RGB texture, map a partial rectangle, unmap it, and then need it all loaded into the sRGB texture. And you can make it even more complicated if you want to.
Although now with UAV the SYSMEM location isn't necessarily the most up to date for buffers either and if EXT_texture_sRGB_decode is supported we only use one TEXTURE location. Anyway, I agree that with textures it can generally get more complicated.
I was thinking about handling it with a WINED3D_LOCATION_FRAGMENTED location that stores a "base" location (in my example LOCATION_TEXTURE_RGB) and a "diff" location (LOCATION_BUFFER in my example). The dirty box indicates which area of diff needs to be transferred to base. In a partial map we'd set base = old location, diff = new location and if necessary transfer the mapped area from base to diff. Then we'd set location=LOCATION_FRAGMENTED and invalidate all other locations. If we're later loading the base location again we only need to copy the dirty rect from diff to base. Afterwards we invalidate LOCATION_FRAGMENTED [*]. If we load a different location (even the diff location[*]) we'd first de-fragment it in the same way and then load the requested location from the now-valid base location.
[*]: These two things could be made a bit more flexible, but I am not sure if it is worth the trouble. In most cases we'll only have to worry about LOCATION_TEXTURE_RGB and one of LOCATION_BUFFER/LOCATION_SYSMEM/LOCATION_USERPTR. I don't think there are many applications that map two different subboxes and expect it to be fast.
Maybe that's already too flexible. I'd start by only "cloning" the SYSMEM -> BUFFER uploading mechanism from buffers (but for SYSMEM -> TEXTURE) and see where we stand at that point. Yes, it's not particularly generic / orthogonal / nice but it probably is the most important case we care about fast partial texture updates.
I think at some point we'll want to use GL_ARB_buffer_storage for both textures and buffers to speed up CSMT maps and a few other goodies. Merging GL BO handling of textures and buffers would make this a lot easier.
I assume you specifically mean persistent maps. Those would be interesting to try out for sure, although it's probably quite some work and it should wait for the "old" buffer mapping optimizations to come in CSMT first.