CNA-BUG-104: DIRECTX9 reports AnisotropicFiltering and MultiSampleAntiAliasing unconditionally and writes MaxAnisotropy to the sampler without clamping to the device cap

CNA snapshot 009d40f5  ·  Known Issues › Current bugs  ·  source links pinned to 009d40f5

DirectX9Renderer inherits the interface's default true capability answers, and its fixed-function/stock ApplySamplerState passes the requested MaxAnisotropy straight to D3DSAMP_MAXANISOTROPY, although its compiled-effect path clamps to D3DCAPS9::MaxAnisotropy.

Identifier

CNA-BUG-104

Category

Bug

Subsystem

Graphics & renderers

Status

Open

Verified against

CNA 009d40f5 (009d40f5dd085c4e674d3479675fac84b12b3e0a)

Severity

Low (a triage suggestion, not a project priority)

Evidence basis

Source-verified: read at TARGET, not executed

Tests touching this area

None

Affected contract

GraphicsDevice::SupportsCapability(AnisotropicFiltering / MultiSampleAntiAliasing) and SamplerState.MaxAnisotropy on DIRECTX9

Expected behaviour

A capability answer should describe the device, and a sampler value should be clamped to what the device accepts, as the renderer's own compiled-effect route does.

Actual behaviour at TARGET

DirectX9Renderer.cpp has no SupportsCapability override, so the default in IGraphicsRenderer answers true for anisotropic filtering and MSAA on every device, while multisampling itself is decided later by CheckDeviceMultiSampleType in ClampMultiSampleCountEXT. ApplySamplerState sets D3DSAMP_MAXANISOTROPY to the requested value unchecked; D3D9CompiledEffect.cpp clamps the same state to [1, caps.MaxAnisotropy].

Source locations

• modules/renderers/directx9/src/DirectX9Renderer.cpp — DirectX9Renderer::ApplySamplerState and ClampMultiSampleCountEXT; no SupportsCapability override
• modules/renderers/directx9/src/D3D9CompiledEffect.cpp — ApplyNativeSampler clamp to caps MaxAnisotropy

Evidence

Checked by reading the named sources at 009d40f5; nothing was built or executed for this entry. Direct3D 9 drivers generally tolerate out-of-range anisotropy values, so the visible effect is driver-dependent; the capability answer is wrong only on devices without the feature.

Focused reproduction

No focused reproduction is known. Nothing has been invented here; the evidence above is what exists.

Current tests

No DIRECTX9 test checks the capability answers against D3DCAPS9 or the sampler value against the cap.

Regression test

A DIRECTX9 capability test deriving both answers from D3DCAPS9 (RasterCaps/TextureFilterCaps and CheckDeviceMultiSampleType) and asserting the applied anisotropy is clamped.

Blast radius

Code that branches on these capabilities on DIRECTX9, and devices with a low anisotropy cap.

Workaround

Clamp SamplerState.MaxAnisotropy yourself on DIRECTX9.