[PATCH 1/2] d3d11/tests: Added more multisample resolve tests.

[Henri Verbeet]

On Wed, 24 Feb 2021 at 13:32, Stefan Dösinger <stefandoesinger at gmail.com> wrote:
> Am 24.02.21 um 11:40 schrieb Jan Sikorski:
> > +    D3D11_MAPPED_SUBRESOURCE staging_mapped = {};
>
> I am not sure if this is valid C, we usually use {0}. If you are
> assigning all members later on anyway you can also skip the init here.
> test_state_refcounting() uses a memset, test_create_texture2d() init all
> fields explicitly. That's a matter of taste IMHO.
>
More than that, we have existing helpers like get_texture_readback(),
get_texture_color(), check_texture_color(), and so on for this kind of
thing.

> > +    {
> > +#if 0
> > ...
> > +#endif
> > +        68,88,66,67,30,184,39,220,81,141,142,55,98,251,192,170,226,59,
>
> This is different from the way we put the other shader bytecode. Afaics
> you should be able to tell the MS shader compiler to give you hex dumps.
>
> Personally I can read some stuff out of at least SM <= 3 hex dumps, but
> with decimal numbers I am lost.
>
Yes, it's much harder to read. Still, I think I can spot most of those
shaders don't end with a 0x010003e (ret) token, so they're not
stripped. For the tests, you'll want to compile shaders with
/Qstrip_reflect, /Qstrip_debug, and /Qstrip_priv for brevity.

Separately, you'll almost always want to use init_test_context() for
the initial setup, or at least create_device().

On Wed, 24 Feb 2021 at 15:18, Jan Sikorski <jsikorski at codeweavers.com> wrote:
> One more thing I’m on the fence about is baking in some tolerance for the results. Right now some of the tests fail because I check the values exactly.

Note that we have a compare_color() helper for exactly that purpose.
check_texture_color() also uses that internally.