On Tue May 16 20:41:25 2023 +0000, Stefan Dösinger wrote:
--- random musings, ignore anything that doesn't make sense --- I ran the test on my r200 GPU (from circa 2002 - a directx 8 native chip, shader model 1 support, but not shader model 2). It has MaxSimultaneousTextures=6 and MaxTextureBlendStages=8. The test passes as is. I think though that binding something to e.g. texture unit 7 is fine as long as no more than 6 textures are read in total by the fixed function pipeline setup. I think version 1.x shaders can only access textures 0-5. There are only 6 "texture registers". A shader trying to use t6 or t7 should fail static validation. I don't think we have tests for this or enforce this restriction though. Fixed function fragment processing can access textures 6 and 7 by using D3DTA_TEXTURE in texture stage 6 or 7. A sufficient number of lower texture stages will have to not read a texture for this to work though. We implement support for this, see wined3d_context_gl_map_fixed_function_samplers. A similar setup is used to make vertex and fragment samplers coexist peacefully. In this case the application will have to use D3DTSS_TEXCOORDINDEX to source an appropriate set of texture coordinates. --- end random musings --- So my 2c:
- Try to change the implementation to simply ignore
D3DERR_UNSUPPORTEDTEXTUREFILTER in d3d8's ValidateDevice and return D3D_OK. There is the question of priority of errors. E.g. assume a d3d9 application fails two of the checks in wined3d_device_validate_device - the filter type and using a depth stencil that is smaller than the render target (D3DERR_CONFLICTINGRENDERSTATE). If d3d9 gets D3DERR_UNSUPPORTEDTEXTUREFILTER, but d3d8 expects D3DERR_CONFLICTINGRENDERSTATE, there's an issue. But I am happy to ignore this situation until we find an application that cares about this. 2) Add more invalid values to d3d9's test_filter(), port the test to d3d8 and adjust the expected return values accordingly. 3) If you are motivated, write tests testing the rendering result with 'invalid' filters. wined3d_sampler_desc_from_sampler_states() already has handling for them, but I don't think we check if the result is correct. E.g. we'd treat a mag filter of D3DTEXF_ANISOTROPIC as D3DTEXF_LINEAR. It's possible the correct behavior is to treat it as D3DTEXF_POINT. This is a question that applies to d3d8 and d3d9. D3d9's ValidateDevice() rejects the bad mag filter, but there's no guarantee applications call ValidateDevice or do something sensible if it returns failure. Personally I don't care about rendering tests - what we seem to need for bug 54898 is for ValidateDevice to succeed. The existing handling of invalid filter values in rendering seems to be ok.
Thanks for all the (arcane) details, much appreciated!
Ignoring the error in d3d8's ValidateDevice is definitely much simpler, I'll go with that. Concerning test_filter(), I'm not yet sure if d3d8 supports a similar "unfilterable" texture format, but I'll try to figure something out... or simply remove this particular case.
I did some _very_ quick rendering tests with invalid min/mag filters and apart from WINED3D_TEXF_NONE they seem to get treated as D3DTEXF_LINEAR. So it looks to me as if wine already does the right thing in wined3d_sampler_desc_from_sampler_states(). (Thanks for pointing me to this function, btw.)