On 15 December 2016 at 13:45, Józef Kucia jkucia@codeweavers.com wrote:
It's enough to enable this workaround for ddraw.
So would it then also be enough to just fixup things in ddraw7_GetAvailableVidMem()? In fact, the documentation suggests that's actually the proper place, and that this shouldn't be specific to the Windows version. You could probably use wined3d_get_adapter_display_mode() together with wined3d_calculate_format_pitch() to calculate the primary surface size.
On Fri, Dec 16, 2016 at 10:13 AM, Henri Verbeet hverbeet@gmail.com wrote:
On 15 December 2016 at 13:45, Józef Kucia jkucia@codeweavers.com wrote:
It's enough to enable this workaround for ddraw.
So would it then also be enough to just fixup things in ddraw7_GetAvailableVidMem()? In fact, the documentation suggests that's actually the proper place, and that this shouldn't be specific to the Windows version. You could probably use wined3d_get_adapter_display_mode() together with wined3d_calculate_format_pitch() to calculate the primary surface size.
Possibly yes, but then memory accounting would be inconsistent. There is also a consideration if the reported memory amount should change when the application switches the display mode. When it comes to whether this should be version specific I think we should enable this workaround only for older Windows versions. It's important to note that these applications aren't expected to work on modern Windows because GetAvailableVidMem() reports more memory than INT_MAX. It's just a workaround to make these buggy applications to work in Wine.
On 16 December 2016 at 10:51, Józef Kucia joseph.kucia@gmail.com wrote:
Possibly yes, but then memory accounting would be inconsistent.
Not necessarily, ddraw7_GetAvailableVidMem() exposes both total and free memory, and is the only place in ddraw that exposes those. There's perhaps an argument that it would allow more resources to be created than would fit in the reported total available video memory, but I don't think that's actually true. The documentation from GetAvailableVidMem() suggests to me that memory for the primary surface is just not counted with the total.
There is also a consideration if the reported memory amount should change when the application switches the display mode. When it comes to whether this should be version specific I think we should enable this workaround only for older Windows versions. It's important to note that these applications aren't expected to work on modern Windows because GetAvailableVidMem() reports more memory than INT_MAX. It's just a workaround to make these buggy applications to work in Wine.
The limit to INT_MAX, yes, and I wouldn't necessarily expect that to be specific to ddraw. Subtracting the memory for the primary surface from the total on the other hand looks like the way ddraw is intended to work to me, regardless of the Windows version.
-
Henri Verbeet -
Józef Kucia