[PATCH 02/10] d3dx9/tests: Add test for effect parameter block.

[Matteo Bruni]

On Tue, Nov 12, 2019 at 8:09 PM Paul Gofman <gofmanp at gmail.com> wrote:
>
> On 11/12/19 21:50, Matteo Bruni wrote:
> > On Thu, Nov 7, 2019 at 10:18 PM Paul Gofman <gofmanp at gmail.com> wrote:
> >
> >> +    /* Child parameters and array members are recorded separately (the whole parameter is not
> >> +     * updated when parameter block is applied).
> >> +     * Setting the same float value does not affect dirty state, but parameter is still
> >> +     * recorded to parameter block.
> >> +     * Setting shared parameter through effect2 is not recorded to effect parameter block. */
> >> +    hr = effect->lpVtbl->SetFloat(effect, "arr2[0]", 92.0f);
> >> +    ok(hr == D3D_OK, "Got unexpected hr %#x.\n", hr);
> >> +    hr = effect->lpVtbl->SetFloat(effect, "ts1[0].fv", 28.0f);
> >> +    ok(hr == D3D_OK, "Got unexpected hr %#x.\n", hr);
> >> +    float_array[0] = -29.0f;
> >> +    hr = effect->lpVtbl->SetFloatArray(effect, "ts1[0].v2", float_array, 1);
> >> +    ok(hr == D3D_OK, "Got unexpected hr %#x.\n", hr);
> > That reminds me of something maybe worth testing: I couldn't manage to
> > have SetArrayRange() ever do anything. Maybe it actually does
> > something with parameter blocks? Not holding my breath for that...
> SetArrayRange() is currently not implemented, so involving it in
> parameters block test would make things very complicated for testing
> parameters blocks. Should not that testing go separately, if we decide
> to implement SetArrayRange()? I did not encounter an app using it so far.

Sure, it's just for my own curiosity. I was unclear: I don't think you
should modify the patch for submission, I'm just asking you to check
if a call to SetArrayRange() with a reduced range in there makes any
difference on native. I could (and should, really) do that myself but
I was asking you as a personal favor :)

> >> +    /* Object reference is not increased when object gets to parameter block
> >> +     * but is also not lost when object is reset in effect parameter.
> >> +     * Maybe native d3dx is using some copy on write strategy. */
> >> +    IDirect3DTexture9_AddRef(texture);
> >> +    refcount = IDirect3DTexture9_Release(texture);
> >> +    ok(refcount == 2, "Got unexpected refcount %u.\n", refcount);
> > Or stuff might just break if the texture is released while still in a
> > parameter block. It should be possible to test it.
>
> The test shows that native d3dx is not loosing reference when the
> texture is left in the parameter block only. Do you mean additionally
> testing a specific case deleting parameter block with texture still set
> to effect parameter? In case it will really loose it, I suggest to still
> keep the reference in our implementation.

Yeah, it's okay to not replicate it (it's definitely an implementation
detail unless applications somehow depend on that, which seems very
unlikely). I'm just curious about what native is doing, but it's
certainly not critical.