Am 27.11.2013 um 17:46 schrieb Henri Verbeet hverbeet@gmail.com:
Staging resources. If we're going to enforce access restrictions we're going to need those anyway for blits that only the CPU blitter can do.
I don’t see how that helps here. This isn’t about a WINED3DFMT_R8G8B8A8_UNORM to WINED3DFMT_R32G32B32A32_FLOAT blit, this about uploading formats that have a conversion function to handle missing GL support (e.g. WINED3DFMT_R16G16_FLOAT without TEXTURE_RG or WINED3DFMT_R16G16_SNORM). Unless we add some WINED3DFMT enum values to express those conversions I don’t see how a staging resource helps here.
I don’t think there are any d3d8/9 blit operations that our GPU blitters cannot handle. There’s one exception - Partial CopyRects copies from a render target to a sysmem surface. With a small modification to the NP2 repacking code surface_download_data can handle that. A staging resource is a viable alternative here, but this is unrelated to this patch. Ddraw blits don’t matter because all ddraw surfaces are mappable.
The conv-update.diff patch has one potential problem: An application could create a R16G16_SNORM surface in D3DPOOL_DEFAULT with D3DUSAGE_DYNAMIC, update it with update_surface and then map it. If that ever happens we can easily handle this with something like
if(converted && destination->resource.valid_access & ACCESS_CPU) wined3d_surface_blt(destination, source, ...); else { surface_get_data(source, &data); surface_upload_from_surface(destination, data); }
But until we find an application with such an odd behavior I’m fine with the existing FIXME.