On Wed, Jan 3, 2018 at 4:18 PM, Sven Hesse shesse@codeweavers.com wrote:
+/* Context activation is done by the caller. */ +static void texture1d_srgb_transfer(struct wined3d_texture *texture, unsigned int sub_resource_idx,
struct wined3d_context *context, BOOL dest_is_srgb)
+{
- struct wined3d_texture_sub_resource *sub_resource = &texture->sub_resources[sub_resource_idx];
- unsigned int row_pitch, slice_pitch;
- struct wined3d_bo_address data;
- /* Optimisations are possible, but the effort should be put into either
* implementing EXT_SRGB_DECODE in the driver or finding out why we
* picked the wrong copy for the original upload and fixing that.
*
* Also keep in mind that we want to avoid using resource.heap_memory
* for DEFAULT pool surfaces. */
- WARN_(d3d_perf)("Performing slow rgb/srgb 1d texture transfer.\n");
- data.buffer_object = 0;
- if (!(data.addr = HeapAlloc(GetProcessHeap(), 0, sub_resource->size)))
return;
- wined3d_texture_get_pitch(texture, sub_resource_idx, &row_pitch, &slice_pitch);
- wined3d_texture_bind_and_dirtify(texture, context, !dest_is_srgb);
- texture1d_download_data(texture, sub_resource_idx, context, &data);
- wined3d_texture_bind_and_dirtify(texture, context, dest_is_srgb);
- texture1d_upload_data(texture, sub_resource_idx, context, NULL,
wined3d_const_bo_address(&data), row_pitch, slice_pitch);
- HeapFree(GetProcessHeap(), 0, data.addr);
+}
We would like to avoid code duplication, if possible. Other than that, do we really need sRGB transfers for 1D textures? I think we are going to use 1D textures only when WINED3D_SRGB_READ_WRITE_CONTROL is disabled. We should avoid a separate sRGB texture if possible.