op: test comparison sampling results and filtering

[kainino0x]

Filtering+comparison is underspecified behavior but we can try to approximate tests.

Nonfiltering comparison should be well specified and we should make sure it has the expected behavior (see also texture_view,read)

[greggman]

Just as an FYI, In October 2021, AMD on Metal had fairly different filtering than other devices

I wrote a test that put 0 in the first mip, 1 in the second, 0 in the 3rd etc...., then filtered between them and graphed the output. Here are the results. This was why the Metal backend on AMD does not pass the OpenGLES dEQP conformance tests related to filtering.

https://jsgist.org/?src=0d5618b35e26acf24191109f60ea87ce

At the time Apple responded with "that's intentional behavior for perf".

That may have changed since then but if it hasn't then it looks like the most you can assume is that sampling between 2 mips where t goes from 0 to 1 to select between mips a and b, that as t goes from 0 to 1, for any t' greater than t sampled value for t' will be closer b to **or equal** to the sampled value for t

If it's useful, a standalone Swift based metal app to test the values is here