[PATCH 01/10] wined3d: Introduce struct wined3d_dirty_regions.

[Stefan Dösinger]

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.

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.

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20170418/cb652d82/attachment.sig>