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@gmail.com:
On 21 October 2015 at 12:57, Stefan Dösinger stefandoesinger@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.