[PATCH 08/10] wined3d: make wined3d_device_update_surface operate with wined3d_texture and sub_resource_idx

Riccardo Bortolato rikyz619 at gmail.com
Thu Oct 22 03:49:07 CDT 2015


I tried taking a different road here, please check out:
https://source.winehq.org/patches/data/115596

Ciao,
Riccardo

2015-10-22 10:47 GMT+02:00 Henri Verbeet <hverbeet at gmail.com>:
> On 21 October 2015 at 12:57, Stefan Dösinger <stefandoesinger at gmail.com> wrote:
>> I completely missed CopySubresourceRegion. This seems like a much
>> better method to map UpdateSurface to than UpdateSubresource.
>>
> At first sight, yes. But it's actually not that obvious. Note that in
> d3d10+ you don't have pure system memory resources like in earlier
> versions, in d3d9 terms resources are always in the default or managed
> pool. The way it's described in the documentation
> CopySubresourceRegion() always copies between GPU buffers, while
> UpdateSubresource() is for uploads. I had hoped to avoid thinking too
> much about how to handle system memory resources for a while. That
> said, perhaps wined3d_device_copy_sub_resource_region() could be a
> useful intermediate step, even though that means we may end up
> changing it to UpdateSubresource() anyway in the future.
>
>>> Complexities of managing that aside, that would always imply at
>>> least one copy of the data for d3d10+ updates.
>> Ya, the design of d3d10's update_sub_resource kinda implies a copy.
>> You can of course try to call GL right away with the
>> application-provided pointer, but then the driver is likely to make a
>> copy internally unless it is really clever too. It seems better to me
>> to do the copy ourselves, write into a client storage buffer object
>> and then blame the driver if it still insists on making an internal copy.
>>
> Yeah, we disagree there. I prefer to do the right thing and then fix
> the driver if it doesn't know how to handle that.



More information about the wine-devel mailing list