On Tue May 16 07:24:05 2023 +0000, Sebastian Mayr wrote:
Hmm, good point... For the most part I just copied this from `test_limits()`. Do you know if this limit also affects the usable indices, or does it just limit the number of textures that are set simultaneously? If it's the latter, the test should be fine, because the texture is unset at the end of the loop. But I guess testing all possible texture stages is not very relevant here, it might be better to just test stage 0? (like `test_filter()` is doing).
--- 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:
1) 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.