[PATCH 01/10] wined3d: Introduce struct wined3d_dirty_regions.
matteo.mystral at gmail.com
Tue Apr 18 17:33:58 CDT 2017
This got sidetracked quite a bit already and I'm going to make it
2017-04-18 21:31 GMT+02:00 Stefan Dösinger <stefandoesinger at gmail.com>:
> Am 2017-04-18 um 19:44 schrieb Henri Verbeet:
>> On 18 April 2017 at 18:25, Matteo Bruni <matteo.mystral at 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.
More information about the wine-devel