[PATCH 3/3] d3d9/tests: Add test for SW shader in MVP mode.

Paul Gofman gofmanp at gmail.com
Thu Aug 24 10:27:18 CDT 2017


On 08/24/2017 04:39 PM, Henri Verbeet wrote:
> On 23 August 2017 at 16:17, Paul Gofman <gofmanp at gmail.com> wrote:
>> -static IDirect3DDevice9 *create_device(IDirect3D9 *d3d, HWND device_window, HWND focus_window, BOOL windowed)
>> +static IDirect3DDevice9 *create_device_behavior(IDirect3D9 *d3d, HWND device_window, HWND focus_window,
>> +        BOOL windowed, DWORD behavior_flags)
> It's perhaps a bit of an uncomfortable change to make due to the
> number of tests in visual.c, but ideally this would match the version
> of create_device() in device.c. Lacking that, there are a few tests in
> visual.c that just call IDirect3D9_CreateDevice() directly. In either
> case, we'd like device.c and visual.c to converge instead of diverge.
So I will create the device without this helper function then.
>> +    hr = IDirect3DDevice9_SetVertexShader(device, NULL);
>> +    ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr);
>> +    hr = IDirect3DDevice9_SetVertexShader(device, pure_sw_shader);
>> +    ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr);
> Is resetting the shader to NULL really needed here?
I will check once again, but I think I saw the second call to 
DrawPrimitiveUP succeeds for the next scene also if already failed once 
for previous scene. So it can be removed along with the first call 
returning invalid value below.
>
>> +    hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad));
>> +    todo_wine
>> +    ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr);
>> +    hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad));
>> +    ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr);
> Odd.
It looks like pretty consistent behaviour between drivers, at least it 
worked the same way for me on Intel & Nvidia (WIndows 7) and test bot. I 
suppose directx "frontend" part resets the shader internally after 
returning an error on first call, and then falls back to fixed function 
vertex processing on the next call. Even if the shader is reset though 
calling GetVertexShader still returns that invalid one previously set.
>
>> +    /* wined3d does not guarantee 0 for out of bounds constant access by default. */
> IIRC neither does Windows, in general. Matteo may have a better
> recollection of the details, but IIRC while it mostly works out in
> practice on current NVIDIA hardware, it doesn't necessarily everywhere
> else, and is essentially hardware/driver specific behaviour.
>
So should I maybe change the test not to check for exact value but 
rather for not matching constant c256?





More information about the wine-devel mailing list