Am 20.05.2022 um 00:32 schrieb Zebediah Figura zfigura@codeweavers.com:
On 5/17/22 10:27, Stefan Dösinger wrote:
Signed-off-by: Stefan Dösinger stefan@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.