[PATCH 3/4] wined3d: Store clear colors in subresources (v2).

[Stefan Dösinger]

> Am 20.05.2022 um 00:32 schrieb Zebediah Figura <zfigura at codeweavers.com>:
> 
> On 5/17/22 10:27, Stefan Dösinger wrote:
>> Signed-off-by: Stefan Dösinger <stefan at codeweavers.com>
>> Version 2: Take the new wined3d_texture_vk_clear into account.
>> ---
>>  dlls/wined3d/context_vk.c      | 41 +++++++++++++++++---
>>  dlls/wined3d/texture.c         | 70 ++++++++++++++++++----------------
>>  dlls/wined3d/utils.c           | 19 +++++++++
>>  dlls/wined3d/wined3d_private.h | 11 ++++++
>>  4 files changed, 104 insertions(+), 37 deletions(-)
> 
> This seems to be missing changes to wined3d_texture_gl_clear(), isn't it?

Not really, because only the Vulkan codepath will set delayed clears. I could add an ERR if the color is non-zero unexpectedly in wined3d_texture_gl_clear.

> It feels awkward to me that we're storing depth/stencil separately in the sub-resource structure, but collapsing it together here. Could we pass, say, a "union wined3d_clear_value" to wined3d_resource_memory_colour_fill() [and wined3d_format_convert_from_float()]?

I considered this, but it would end in the same result at the price of more flags checks in wined3d_format_convert_from_float (check DEPTH / STENCIL flags to read the converted values either from color.rg or depth/stencil. I didn't feel like an actual improvement, but that's not a strong opinion on my end.

I kept it separately for passing to Vulkan because that's how the Vulkan API works.

In practice it is fairly academic because the highest stencil bitcount we'll have is 8 bits, and floats have a large enough mantissa to store them without loss. Depth might be a 32 bit integer, but both Vulkan and GL decided for us to pass those as float unconditionally.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220520/49bf9e99/attachment.sig>