From: Henri Verbeet Subject: Re: [PATCH 1/2] wined3d: Introduce wined3d_output_get_ordinal(). Message-Id: Date: Mon, 23 Nov 2020 19:03:42 +0330 In-Reply-To: <1cbba055-be92-9363-514c-f4eaa2566bf7@codeweavers.com> References: <3b6153fa-e3bb-35f3-3249-afe2db230d2e@codeweavers.com> <1cbba055-be92-9363-514c-f4eaa2566bf7@codeweavers.com> On Mon, 23 Nov 2020 at 18:50, Zhiyi Zhang wrote: > On 2020/11/23 22:54, Henri Verbeet wrote: > > On Mon, 23 Nov 2020 at 18:06, Zhiyi Zhang wrote: > >> On 2020/11/23 21:32, Henri Verbeet wrote: > >>> On Fri, 13 Nov 2020 at 11:19, Zhiyi Zhang wrote: > >>>> Secondhand Lands calls d3d9_device_GetDeviceCaps() frequently. Introduce a wined3d_output_get_ordinal() > >>>> to get output ordinal only instead of using the more expensive wined3d_output_get_desc(). > >>>> > >>> Avoiding calls to EnumDisplaySettingsExW() is fine in principle, but I > >>> don't think these two patches are quite enough to avoid the underlying > >>> issue. In particular, wined3d_output_get_raster_status() is a > >>> potential source of frequent wined3d_output_get_display_mode() calls, > >>> either through d3d9_swapchain_GetRasterStatus() or > >>> ddraw7_GetVerticalBlankStatus()/ddraw7_GetScanLine(). See also bug > >>> 30538 and related bugs. > >> Yes. I am aware of the root cause being that EnumDisplaySettingsExW() is too expensive. > >> I plan to optimize it later. Meanwhile, I think these two patches are reasonable. Are you > >> proposing another way to fix this? > >> > > Mostly just making sure that you're aware there are other places > > affected by this. I also don't particularly love introducing an extra > > wined3d export for this though; shouldn't the 2/2 patch on its own be > > enough to fix the immediate regression? > Yes, for that bug, the 2/2 patch is enough to make the game run at 30fps limit. > I just think that d3d9_device_GetDeviceCaps() only needs output ordinals. So calling > wined3d_output_get_desc() will do a monitor enumeration that can be avoided, which > should improve performance for other applications. > If it ends up taking significant CPU time even after patch 2/2, perhaps it would make sense to simply store the converted D3DCAPS9 structure in struct d3d9; its contents should be stable across calls.