On 5/22/22 04:16, Stefan Dösinger wrote:
From: Stefan Dösinger stefan@codeweavers.com
Signed-off-by: Stefan Dösinger stefan@codeweavers.com
Love it or leave it. Shouldn't affect the test behind it.
Eventually we can merge depth formats into the UNORM or FLOAT codepaths, but right now the UNORM flag is specific to color formats. I'm also not sure how we'd ever realistically clear a depth buffer to anything other than zero in the CPU codepath. Tests show that depth locking is unreliable, and even DEPTHFILL value vs actual Z test value in d3d7 is vendor specific.
Merging depth-unorm and color-unorm as well as depth-float and color-float handling works without this patch too. Just multiply and OR color.r with mask_to_size(red) and mask_to_size(depth), as long as we don't encounter a format that has both red and depth channels.
dlls/wined3d/device.c | 4 +-- dlls/wined3d/resource.c | 8 +++--- dlls/wined3d/surface.c | 12 +++++---- dlls/wined3d/texture.c | 19 ++++---------- dlls/wined3d/utils.c | 47 +++++++++++++++++++--------------- dlls/wined3d/wined3d_private.h | 5 ++-- 6 files changed, 48 insertions(+), 47 deletions(-)
I don't dislike this, although on a second look I think using the union would work just as well? Note that because a format is either float or depth-stencil (and we have zero multipliers accordingly) we don't actually need to check the depth/stencil size in wined3d_format_convert_from_float(). Otherwise this patch would be broken wrt wined3d_texture_load_location().