-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I am working on a more comprehensive test for V8U8, V16U16, L6V5U5, X8L8V8U8 and Q8W8V8U8. I have attached the current status of this test. I am still struggling with finding the right precision that makes all Windows machines happy. There are also some problems with our conversion code.
Your test tests the case of a non-even width, whereas my test doesn't do that. I can build that into my test as well.
We can still commit your test if you want, and I'll remove it again in my patch (together with x8l8v8u8_test).
Stefan
Am 2015-02-20 um 13:06 schrieb Matteo Bruni:
dlls/d3d9/tests/visual.c | 148 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 148 insertions(+)
diff --git a/dlls/d3d9/tests/visual.c b/dlls/d3d9/tests/visual.c index 5f64ec3..2152ba6 100644 --- a/dlls/d3d9/tests/visual.c +++ b/dlls/d3d9/tests/visual.c @@ -16208,6 +16208,153 @@ done: DestroyWindow(window); }
+static void v16u16_test(void) +{
- IDirect3DTexture9 *texture;
- IDirect3DPixelShader9 *shader;
- IDirect3DDevice9 *device;
- D3DLOCKED_RECT rect;
- IDirect3D9 *d3d;
- unsigned int i;
- ULONG refcount;
- D3DCAPS9 caps;
- SHORT *texel;
- DWORD color;
- HWND window;
- HRESULT hr;
- static const struct
- {
struct vec3 position;struct vec2 texcrd;- }
- quads[] =
- {
{{-1.0f, -1.0f, 0.0f}, {0.0f, 0.0f}},{{-1.0f, 1.0f, 0.0f}, {0.0f, 1.0f}},{{ 1.0f, -1.0f, 1.0f}, {1.0f, 0.0f}},{{ 1.0f, 1.0f, 1.0f}, {1.0f, 1.0f}},- };
- static const DWORD shader_code[] =
- {
0xffff0101, /* ps_1_1 */0x00000051, 0xa00f0000, 0x3f000000, 0x3f000000, /* def c0, 0.5, 0.5, */0x3f000000, 0x3f000000, /* 0.5, 0.5 */0x00000042, 0xb00f0000, /* tex t0 */0x00000004, 0x800f0000, 0xb0e40000, 0xa0e40000, 0xa0e40000, /* mad r0, t0, c0, c0 */0x0000ffff /* end */- };
- window = CreateWindowA("static", "d3d9_test", WS_OVERLAPPEDWINDOW | WS_VISIBLE,
0, 0, 640, 480, NULL, NULL, NULL, NULL);- d3d = Direct3DCreate9(D3D_SDK_VERSION);
- ok(!!d3d, "Failed to create a D3D object.\n");
- if (!(device = create_device(d3d, window, window, TRUE)))
- {
skip("Failed to create a D3D device, skipping tests.\n");goto done;- }
- hr = IDirect3DDevice9_GetDeviceCaps(device, &caps);
- ok(SUCCEEDED(hr), "Failed to get device caps, hr %#x.\n", hr);
- if (caps.PixelShaderVersion < D3DPS_VERSION(1, 1))
- {
skip("No ps_1_1 support, skipping tests.\n");IDirect3DDevice9_Release(device);goto done;- }
- if (FAILED(IDirect3D9_CheckDeviceFormat(d3d, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL,
D3DFMT_X8R8G8B8, 0, D3DRTYPE_TEXTURE, D3DFMT_V16U16)))- {
skip("V16U16 textures are not supported, skipping test.\n");IDirect3DDevice9_Release(device);goto done;- }
- hr = IDirect3DDevice9_SetFVF(device, D3DFVF_XYZ | D3DFVF_TEX1);
- ok(SUCCEEDED(hr), "Failed to set FVF, hr %#x.\n", hr);
- hr = IDirect3DDevice9_CreatePixelShader(device, shader_code, &shader);
- ok(SUCCEEDED(hr), "Failed to create pixel shader, hr %#x.\n", hr);
- hr = IDirect3DDevice9_SetPixelShader(device, shader);
- ok(SUCCEEDED(hr), "Failed to set pixel shader, hr %#x.\n", hr);
- hr = IDirect3DDevice9_SetSamplerState(device, 0, D3DSAMP_MAGFILTER, D3DTEXF_POINT);
- ok(SUCCEEDED(hr), "Failed to set filter, hr %#x.\n", hr);
- for (i = 0; i < 2; ++i)
- {
D3DPOOL pool;if (i)pool = D3DPOOL_SYSTEMMEM;elsepool = D3DPOOL_MANAGED;hr = IDirect3DDevice9_CreateTexture(device, 1, 2, 1, 0, D3DFMT_V16U16,pool, &texture, NULL);ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr);hr = IDirect3DTexture9_LockRect(texture, 0, &rect, NULL, 0);ok(SUCCEEDED(hr), "Failed to lock texture, hr %#x.\n", hr);texel = (SHORT *)((BYTE *)rect.pBits + 0 * rect.Pitch);texel[0] = 32767;texel[1] = 32767;texel = (SHORT *)((BYTE *)rect.pBits + 1 * rect.Pitch);texel[0] = -32768;texel[1] = 0;hr = IDirect3DTexture9_UnlockRect(texture, 0);ok(SUCCEEDED(hr), "Failed to unlock texture, hr %#x.\n", hr);if (i){IDirect3DTexture9 *texture2;hr = IDirect3DDevice9_CreateTexture(device, 1, 2, 1, 0, D3DFMT_V16U16,D3DPOOL_DEFAULT, &texture2, NULL);ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr);hr = IDirect3DDevice9_UpdateTexture(device, (IDirect3DBaseTexture9 *)texture,(IDirect3DBaseTexture9 *)texture2);ok(SUCCEEDED(hr), "Failed to update texture, hr %#x.\n", hr);IDirect3DTexture9_Release(texture);texture = texture2;}hr = IDirect3DDevice9_SetTexture(device, 0, (IDirect3DBaseTexture9 *)texture);ok(SUCCEEDED(hr), "Failed to set texture, hr %#x.\n", hr);hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, 0x00ff00ff, 1.0f, 0);ok(SUCCEEDED(hr), "Failed to clear, hr %#x.\n", hr);hr = IDirect3DDevice9_BeginScene(device);ok(SUCCEEDED(hr), "Failed to begin scene, hr %#x.\n", hr);hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, &quads[0], sizeof(*quads));ok(SUCCEEDED(hr), "Failed to draw, hr %#x.\n", hr);hr = IDirect3DDevice9_EndScene(device);ok(SUCCEEDED(hr), "Failed to end scene, hr %#x.\n", hr);color = getPixelColor(device, 320, 160);ok (color_match(color, 0x00007fff, 1),"Expected color 0x00007fff, got %#x, V16U16 input -32768, 0.\n", color);color = getPixelColor(device, 320, 400);ok (color_match(color, 0x00ffffff, 1),"Expected color 0x00ffffff, got %#x, V16U16 input 32767, 32767.\n", color);hr = IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL);ok(SUCCEEDED(hr), "Failed to present, hr %#x.\n", hr);IDirect3DVolumeTexture9_Release(texture);- }
- IDirect3DPixelShader9_Release(shader);
- refcount = IDirect3DDevice9_Release(device);
- ok(!refcount, "Device has %u references left.\n", refcount);
+done:
- IDirect3D9_Release(d3d);
- DestroyWindow(window);
+}
static void add_dirty_rect_test_draw(IDirect3DDevice9 *device) { HRESULT hr; @@ -17566,6 +17713,7 @@ START_TEST(visual) texkill_test(); x8l8v8u8_test(); volume_v16u16_test();
- v16u16_test(); constant_clamp_ps_test(); cnd_test(); dp2add_ps_test();
2015-02-20 13:29 GMT+01:00 Stefan Dösinger stefandoesinger@gmail.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I am working on a more comprehensive test for V8U8, V16U16, L6V5U5, X8L8V8U8 and Q8W8V8U8. I have attached the current status of this test. I am still struggling with finding the right precision that makes all Windows machines happy. There are also some problems with our conversion code.
Yes, I've noticed that too. I haven't really looked into it but the float-to-signed conversion has always been a bit tricky. In OpenGL AFAIK the conversion formula changed at some point (e.g. see table 2.9 in the 2.1 spec vs paragraph 2.3.5.1 in the 4.5 spec), it might be we have to use one instead of the other in our fallback conversion functions too. No idea if something like that applies to Windows drivers too.
Your test tests the case of a non-even width, whereas my test doesn't do that. I can build that into my test as well.
We can still commit your test if you want, and I'll remove it again in my patch (together with x8l8v8u8_test).
I just wrote (more like copypasted and edited) this test to make sure I didn't screw up patch 1/5 and since I wrote it I though "why not send it too". It's fine for me either way.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-02-20 um 13:50 schrieb Matteo Bruni:
Yes, I've noticed that too. I haven't really looked into it but the float-to-signed conversion has always been a bit tricky. In OpenGL AFAIK the conversion formula changed at some point (e.g. see table 2.9 in the 2.1 spec vs paragraph 2.3.5.1 in the 4.5 spec), it might be we have to use one instead of the other in our fallback conversion functions too. No idea if something like that applies to Windows drivers too.
Well, one problem we have in e.g. L6V5U5 is that we simply left-shift by 3. So the input value 15 / 0xf, which is the highest possible value for the signed channels becomes 120 (0x78). This doesn't give the same float result.
The code Henri uses in convert_s1_uint_d15_unorm looks reasonable, but I did not find a textbook explanation for it. Repeating the high bits in the extra space seems reasonable, but I'm not sure what the reason for ORing the least significant bit is.
Also I'm not sure what the correct handling of negative ranges is. I *think* it's enough to just left-shift them, but I am not sure.
Also, as the OpenGL spec says, representing zero is an issue.
On 20 February 2015 at 13:59, Stefan Dösinger stefandoesinger@gmail.com wrote:
The code Henri uses in convert_s1_uint_d15_unorm looks reasonable, but I did not find a textbook explanation for it. Repeating the high bits in the extra space seems reasonable, but I'm not sure what the reason for ORing the least significant bit is.
It's supposed to be the stencil data. Note that that code probably hasn't seen a lot of testing though, since in practice it's probably only used for the upload of the initial surface contents. I.e., zeroes.
-
Henri Verbeet -
Matteo Bruni -
Stefan Dösinger