[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