search

KhronosGroup / KTX-Software-CTS

Test Suite (Black Box) for KTX-Software
Apache License 2.0
1 stars 5 forks source link

Failing to detect gcc for golden file regeneration #27

Open MarkCallow opened 5 months ago

MarkCallow commented 5 months ago

I attempted to regenerate some golden files that have output tolerance enabled and got the message "... not updated on non-primary platform ..."

But I am running under Ubuntu 22.04 and using gcc 11 to compile. Possibly the reason for the failure is that my configuration after selecting "default compilers" shows

CMAKE_CXX_COMPILER /usr/bin/c++
CMAKE_C_COMPILER   /usr/bin/cc

and if I run, e.g, cc --version the output is

cc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

while for gcc --version it is

gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

so you can't see from either the CMake variables or --version output that it is really gcc.

MarkCallow commented 5 months ago

I am surprised to see a tolerance needed with ASTC images. The encoder is supposed to be invariant. But it appears it is not living up to the promise. What was your experience @aqnuep?

aqnuep commented 5 months ago

so you can't see from either the CMake variables or --version output that it is really gcc.

That probably is the reason. Btw, which ASTC images do you see the need for tolerance? What test case are we talking about?

MarkCallow commented 5 months ago

Btw, which ASTC images do you see the need for tolerance? What test case are we talking about?

I didn't see a need for tolerance. I was regenerating golden files dues to an update to the ASTC encoder and got the "... not updated ..." message. The tests in question are create/astc_params.json and create/generate_mipmap.json.

I don't know why there is an outputTolerance in the first. In the second a comment indicates "On apple silicon certain floating point operation causes the lanczos4 filter to sometime be off-by a single unit." The tolerance is set according to which resampling filter is in use, not the output format and ASTC is used in only two of the output cases.

aqnuep commented 5 months ago

Ah, I believe this is related to some floating point precision differences we saw with the ASTC encoder when running on Apple silicon.

MarkCallow commented 2 weeks ago

Ah, I believe this is related to some floating point precision differences we saw with the ASTC encoder when running on Apple silicon.

As far as I can see the ASTC encoder is producing consistent results. It is the zlib deflator producing different results on x86_64 and Apple Silicon that requires use of outputTolerance in create/astc_params.json.

aqnuep commented 2 weeks ago

That is interesting... I have no clue how that could happen.