Re: [PATCH 1/2] wined3d: Use the np2_fixup to find out if a RECT texture is used
On 11 April 2013 11:32, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
@@ -1069,17 +1069,17 @@ static void shader_generate_glsl_declarations(const struct wined3d_context *cont shader_addline(buffer, "uniform sampler1D %s_sampler%u;\n", prefix, i); break; case WINED3DSTT_2D: - texture = state->textures[i]; + tex_rect = version->type == WINED3D_SHADER_TYPE_PIXEL && (ps_args->np2_fixup & (1 << i));
The basic idea is ok, but the conditions for when np2_fixup is set are a bit more complicated than that. Specifically, look at how the WINED3D_TEXTURE_POW2_MAT_IDENT texture flag is set / cleared in texture_init().
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-04-11 13:40, schrieb Henri Verbeet:
The basic idea is ok, but the conditions for when np2_fixup is set are a bit more complicated than that. Specifically, look at how the WINED3D_TEXTURE_POW2_MAT_IDENT texture flag is set / cleared in texture_init(). I think this should be 'fixed' by supporting conditional NP2 textures only when texture_rectangle is supported and get rid of other situations where we scale coordinates.
- -> Fake NP2 cube textures: I don't see how this can possibly work. We're merely length-scaling a directional vector. - -> GPUs that don't support ARB_texture_rectangle: Unfortunately I don't have one of those, but not advertising NP2_CONDITIONAL on those should be legitimate. - -> Fallback for P8 textures and EXT_paletted_textures: Problematic because I can't test this. Not sure if the code even works... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZ70nAAoJEN0/YqbEcdMww1MQAIYlL31TtEyZ0z60Ki4KfX4w bGeaFbfMJPEcgOVzCHxEStmUaHOJFsJufdeEvw16Fs0ZoRHh45O5hRaNaEGCEE7i bFu5j1eBRXqHmYOrgwoJ328SG/wLAUy2DHyt6EeiebBKsrhvyUnzVDi6qocvie5V 6KNN9y+PB8PE6yipR4Qtts+GBP8jOYvMc38l6S2q9Bq2jNv6fPwXtYsIlQ2Ltl8a RCsQMSVJashOsBsne6VOJ124DbCT9KzIIwy0/lKMwqxoN+Jvj+Xo9jO4XPEZNUOp 7AsbKl+ssp4JyTjjvxVu4QXXK3EzrpxmCverUxkNG1MS5RUAivKkn+gpCjRVM84w e2BUy6F5blmig64JuvIb77b7DI5DT3aZlsenGkYkBaITE71szjjssiWlTAbLHf7/ hGIrXklXvf3xL2g+0dCg10lvHA8/1ty5iwG/O1ZH51o5zBCBUHg5+GYNBx66mRgZ oMXHds3QYU6XIp5S79TmIQPXRBlK553O/N0pwicq98uFh025qjC8GIEkflAqJaKk CSuAA7diizPLYLWUX4XdAcnDx8H3Xp+JS4SpqsaL61+mOD1gqgnDd5Hx5GgwvqV4 EM0riZq3TeoRjfCzBmn39PSvRIajdVU0Civ9JOj/raKKfQqzIG7KiSYG6T8n9Vl8 7XUAIf0TzEYEbO5P5XF9 =c0yJ -----END PGP SIGNATURE-----
On 12 April 2013 09:52, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
I think this should be 'fixed' by supporting conditional NP2 textures only when texture_rectangle is supported and get rid of other situations where we scale coordinates.
Possibly, although the only really problematic condition is the 1x1 texture one. If you make that go away, the condition comes down to ARB_texture_rectangle being supported, having a 2D texture, and the appropriate bit in np2_fixup being set.
- -> Fake NP2 cube textures: I don't see how this can possibly work. We're merely length-scaling a directional vector.
Yeah, that looks wrong. It doesn't really affect this patch though, since cube maps are never rect textures.
- -> GPUs that don't support ARB_texture_rectangle: Unfortunately I don't have one of those, but not advertising NP2_CONDITIONAL on those should be legitimate.
Yeah, though that's also more of a generic NPOT texture cleanup, it's trivial to check for rect texture support in the shader code.
- -> Fallback for P8 textures and EXT_paletted_textures: Problematic because I can't test this. Not sure if the code even works...
Supposedly we can't really texture from P8 anyway, and certainly not from shaders. I'm not sure if there's any still supported hardware / driver combination that supports EXT_paletted_texture either. We should probably just get rid of any remaining EXT_paletted_texture support.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-04-12 10:34, schrieb Henri Verbeet:
Possibly, although the only really problematic condition is the 1x1 texture one. If you make that go away, the condition comes down to ARB_texture_rectangle being supported, having a 2D texture, and the appropriate bit in np2_fixup being set. I missed that one, but isn't that dead code already? 1 is a power of 2, and the code that calculates pow2_width should recognize it as such. So there shouldn't be a 1x1 RECT texture, and thus no RECT texture that doesn't have WINED3D_TEXTURE_POW2_MAT_IDENT set.
- -> GPUs that don't support ARB_texture_rectangle: Unfortunately I don't have one of those, but not advertising NP2_CONDITIONAL on those should be legitimate.
Yeah, though that's also more of a generic NPOT texture cleanup, it's trivial to check for rect texture support in the shader code. My prehistoric mach64 GPU might not have conditional NPOT support. If I ever feel like messing with the empty cmos battery in that laptop I'll install Windows again and write some tests.
Supposedly we can't really texture from P8 anyway, and certainly not from shaders. I'm not sure if there's any still supported hardware / driver combination that supports EXT_paletted_texture either. We should probably just get rid of any remaining EXT_paletted_texture support. I think the point of that code was to support P8 presents, and GeForce 5 and earlier cards supposedly have support for EXT_paletted_texture.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZ9djAAoJEN0/YqbEcdMwS+YP/jagWaMrf8TX3u4+qVwUtM8P wsgmIdQR+AAP7tr79cA8YzCEOomH7KvtrucfNDooGiRvvMV7lsEWUEM0lPjqoQEj NLUwZTaF0kKPOOnj6Mozf+T9acnu73Jvy4ghk1bzmvy53yHhS9DaMQ5smGavPimy 1EbS2ZG3hFJtZmDNmPlBRGJLHg4noUhGiDpbt93ztz8PtuoryTfVeq9TT/rdu0zm 7njg1kgY+Dvzyk5bSv4HxVGrrlmoY0FmFxM5u/7CjzkJCxZhqxpBuySrl7toWH4P pgWyeWsdM4PYnbjI0JUq+dIzp6Kn0HgCqEZWNqsdUg9VE/FOS705KmJH5uVUybdG y3peEav4PKHvgvjK9L3m1lzr8pWQUOqIuK6LiV8pC6WhM18TWTfWCnfRW4xjE1q/ a9yqKU///YX5FKYt8MHIk1/3boFN1V3pewuJ33M1oJ7Tc/D/FG8rGZlpKFXez8m+ SwgOUoGjcAWmSWnYQbSc9Gqo6hbivWZoAtbg0e78k3CjmYyK9OGpNgI6vMrfTt65 lamECLjBkVdf0O4Zgkg7Agsd6y4DtymNaEy5Kk4JwMX6OGb2EtyPYHS6sOGNmMpw rmCKmwiYr8yU71Td058kUL6h/CjrhOCA0pa6IfbngykaRfgfFUEMWdxiLSSefdnz q8f34ubBt3NZVidCS3UF =WWCJ -----END PGP SIGNATURE-----
On 12 April 2013 11:44, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
I missed that one, but isn't that dead code already? 1 is a power of 2, and the code that calculates pow2_width should recognize it as such. So there shouldn't be a 1x1 RECT texture, and thus no RECT texture that doesn't have WINED3D_TEXTURE_POW2_MAT_IDENT set.
True, so that code should go away regardless of this patch.
Supposedly we can't really texture from P8 anyway, and certainly not from shaders. I'm not sure if there's any still supported hardware / driver combination that supports EXT_paletted_texture either. We should probably just get rid of any remaining EXT_paletted_texture support. I think the point of that code was to support P8 presents, and GeForce 5 and earlier cards supposedly have support for EXT_paletted_texture.
Perhaps that was the idea for ddraw at some point, but certainly not for d3d8 and later where you actually have shaders, since there's no way to Present() from a texture there. As for EXT_paletted_texture support, I don't have EXT_paletted_texture on my nv17 with Mesa, and I'm not sure if you can really count GeForce 5 and before as "supported" by the proprietary nvidia driver. Also note that on GeForce 5 in particular we can do blits using shaders, and would never want to use fixed function based blits anyway.
participants (2)
-
Henri Verbeet -
Stefan Dösinger