[PATCH 1/6] d3d11: Implement d3d11_device_CheckMultisampleQualityLevels().

Henri Verbeet hverbeet at gmail.com
Fri Jan 29 08:35:05 CST 2016


On 29 January 2016 at 00:51, Matteo Bruni <mbruni at codeweavers.com> wrote:
> +    if (sample_count > 32)
> +        return E_FAIL;
I think that's D3D11_MAX_MULTISAMPLE_SAMPLE_COUNT.

> +    if (sample_count > 16)
> +    {
> +        FIXME("sample_count %u not handled yet.\n", sample_count);
> +        return S_OK;
> +    }
I think that belongs in wined3d_check_device_multisample_type().

> +    hr = wined3d_device_check_multisample_quality_levels(device->wined3d_device,
> +            wined3dformat_from_dxgi_format(format), sample_count, quality_level_count);
> +    if (hr == WINED3DERR_INVALIDCALL)
> +        return E_INVALIDARG;
> +    if (hr == WINED3DERR_NOTAVAILABLE)
> +        return S_OK;
This is fine, but the d3d10+ API probably makes more sense in the long
run. I.e., eventually we'd want to handle the difference in d3d8/9
instead.

> +HRESULT CDECL wined3d_device_check_multisample_quality_levels(const struct wined3d_device *device,
> +        enum wined3d_format_id format_id, enum wined3d_multisample_type multisample_type,
> +        DWORD *quality_level_count)
I don't think we really want to introduce a new entry point for this.
I guess the issue is that we can't get at the wined3d object that
created the device from inside d3d11, but I think it would be
preferable to do something about that instead. It seems likely that
CheckFeatureSupport() and CheckFormatSupport() would run into this as
well.



More information about the wine-devel mailing list