On 29 January 2016 at 00:51, Matteo Bruni mbruni@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.
2016-01-29 15:35 GMT+01:00 Henri Verbeet hverbeet@gmail.com:
On 29 January 2016 at 00:51, Matteo Bruni mbruni@codeweavers.com wrote:
- 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.
Yes, agreed, but handling the (d3d9-only) D3DMULTISAMPLE_NONMASKABLE setting outside of wined3d seems to be a bit awkward. Other possible options might be to keep the non-maskable option (and the enum wined3d_multisample_type instead of the sample count) but otherwise follow the d3d10+ API or simply return the multisample_types field from struct wined3d_format and let the clients deal with it.
Mostly for curiosity I had a quick look at the d3d12 API on MSDN, at a first glance it mostly resembles the d3d10 interface except that there isn't a separate function for it i.e. it's been merged into CheckFeatureSupport().
Anyway, for the time being I've kept the current API although I can certainly change that.