On Mon Sep 16 15:24:10 2024 +0000, Matteo Bruni wrote:
I'm afraid I wasn't clear enough here :/ I meant to specifically suggest using the float comparison functions we have in newer tests, like: `static BOOL compare_float(float f, float g, unsigned int ulps)` e.g. from d3dx9_36/tests/math.c. In particular I find ULPs to be a great way of quantifying comparison error. Relatedly, we want to use `%.8e` for `float` formatting, because that doesn't lose precision when printing values. It looks like, at least for now, we match native results to 1 ULP (on 32-bit, which is the one I happened to test). We need to specify the expected results with greater precision than we currently do, but it ensures that there are no surprises in the implementation.
Ah, I saw "relative error" and the function in `d3dx9_36/tests/texture.c`: ``` static inline float relative_error(float expected, float got) { return expected == 0.0f ? fabs(expected - got) : fabs(1.0f - got / expected); } ``` came to mind. :) This should be fixed in the current revision, using the functions in `d3dx9_36/tests/math.c`.
I've changed the format of the float constants in the calls to `check_pixel_float4()` to match the `%.8e` format where necessary, and kept the old format for things like `1.0f` and `0.0f`. Hopefully it's fine now.