On 11 April 2013 11:32, Stefan Dösinger stefan@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...
On 12 April 2013 09:52, Stefan Dösinger stefandoesinger@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.
On 12 April 2013 11:44, Stefan Dösinger stefandoesinger@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.
-
Henri Verbeet -
Stefan Dösinger