[PATCH 3/6] wined3d: Move format conversion to surface_upload_data.

Stefan Dösinger stefandoesinger at gmail.com
Wed Nov 27 11:08:17 CST 2013


Am 27.11.2013 um 17:46 schrieb Henri Verbeet <hverbeet at 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.




More information about the wine-devel mailing list