Re: [PATCH 2/5] d3d9/tests: Add a test for 2D D3DFMT_V16U16 textures.
-----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; + else + pool = 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();
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5yi0AAoJEN0/YqbEcdMwXdcP/2QHNZaeHncB/4If+JfpQEOv Vto9Z3ip/eGDuOCRylNjiL47VZfYyuqXHe8EoGzKkuGmtGvPjr2ZhkebUf0l9OIN g2LAqQIa17nYTJFnO6ofzHjcWb++mdIDG1lVUJFKyhIS2vl0xjfB3V4wteMLDffS R6CTtAS49vxFL2lzDwrWaEj2SYhnnybNoKLdhOY5jXH31kcz5W9k3Fzr5Umb2dPB q3tyZHZtYHHsR5kXCmJO6DA456y8euFqzR9GK5/0nDUlh8CGV74pPL6pZMnoPn7c ssXU4HzPB9zPI6zVZBTV8+oOmHWFDn1YZL1M/w50rxY35XvjkU3vs4oezuHMkZBS wXt30QYWBRhFFB3Z2lq9jv9JZXA9V2+A8WmJMbblgv662QsctIAmT9ZAc2xycm7R ye89fHEC3xXFmM6jdJqS1k5MrA5R1li5YFbS18ujcAXVYCW3v8JtK0G05h2zy9e1 KifoVA8o+cVV0Sh2GtYoifLSNvpYo2AlCrP7/cjOyR6igiShK5pF+pktRIlsraM2 3Hl0wGjr2TPhTCTQQPKsskVNvKE+017e4+fwaFI8fRgF3zYSgLSKZELPFY05bzBX OOcbNSEqjRkFtoQoerBR7vx7yrU+85lwd945AGS3URF8KqkavK1LYsAfmLnFu90y YltdeSdbSvQDHCQ4CmmL =D2Pe -----END PGP SIGNATURE-----
2015-02-20 13:29 GMT+01:00 Stefan Dösinger <stefandoesinger(a)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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5y+xAAoJEN0/YqbEcdMwzYEP/30SOtzipbgTFGyU9i5uvAl2 wnDxoteqdBQjk8UwIqM933uHDsuDBXZBLzEvtG7lWq83Sf/n7qWkQf69n/Ek5vuh EWgdxN2jVXa3jboBHdSWAagcS0uBlj4Z5BHewiXXdNHHbPOO34aKHOztK+j8B1Sp PhcHR4LT1XZy6KkXS4nh6L3V9vyB8U0FADmDuumy47RcZ0b+cGsghpk/AZ5ULb4K uck1XwjOVWV+i9j9YErxzoCBzDooKG2oUYuQti2N2G5ae4pqGc9H8dTvQJ2l/Pt4 MxT0R/wa05mPSLCNl+u9qHWRlZ677g8JlvWD5diqgeD2k09dvlS2aahMSveFreu9 33uBil2eRP8hKioafCVNJ/efDnFCKcayi/UmUTfISpwZ3gwI3V/aNKaoN6CGtlAm DtTGn25lDWZrPOt/h2zon+NoYBLFMkW+ZOnEIrVVB6OBtRrAnJDKVkj2CE7XMJkz Vzw9xozGRJ+nHi2RdsEOqT4dcAzKvZgdtVL2+jgKehNzAagOKPTjfhmf+kcyOu05 V3cNwowaZmagvrknxDWaMzI0TM530UTimqEkXhY7oIwpHV3qT40GOFyjQM/hu1nB ZvMLB7978IK0fMLAhZi8KuM7eFTsHWgOtTyf2AvxzIZnSADJkGs2FlKXvOkTCnaP Dmbwu+WVecEXL/3xRAdK =Kr2P -----END PGP SIGNATURE-----
On 20 February 2015 at 13:59, Stefan Dösinger <stefandoesinger(a)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.
participants (3)
-
Henri Verbeet -
Matteo Bruni -
Stefan Dösinger