[PATCH 0/1] MR126: Draft: ddraw: Limit max texture size to fit a 16bit signed integer

[Fabian Maurer (＠DarkShadow44)]

Since ddraw propably never allowed sizes that big anyways,
this should not cause any issues.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51512
Signed-off-by: Fabian Maurer

[PATCH 1/1] ddraw: Limit max texture size to fit a 16bit signed integer

[Fabian Maurer]

From: Fabian Maurer

Since ddraw propably never allowed sizes that big anyways,
this should not cause any issues.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51512
Signed-off-by: Fabian Maurer 
---
 dlls/ddraw/ddraw.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c
index f6770e59fb6..5a25bd58c4e 100644
--- a/dlls/ddraw/ddraw.c
+++ b/dlls/ddraw/ddraw.c
@@ -1287,8 +1287,9 @@ HRESULT ddraw_get_d3dcaps(const struct ddraw *ddraw, D3DDEVICEDESC7 *caps)
     caps->dpcLineCaps.dwTextureFilterCaps = wined3d_caps.TextureFilterCaps;
     caps->dpcLineCaps.dwTextureAddressCaps = wined3d_caps.TextureAddressCaps;

-    caps->dwMaxTextureWidth = wined3d_caps.MaxTextureWidth;
-    caps->dwMaxTextureHeight = wined3d_caps.MaxTextureHeight;
+    /* Some games (like "warning forever") assume the texture size fits a signed 16bit integer, so we limit the size artificially */
+    caps->dwMaxTextureWidth = min(wined3d_caps.MaxTextureWidth, 16384);
+    caps->dwMaxTextureHeight = min(wined3d_caps.MaxTextureHeight, 16384);

caps->dwMaxTextureRepeat = wined3d_caps.MaxTextureRepeat;
     caps->dwMaxTextureAspectRatio = wined3d_caps.MaxTextureAspectRatio;

[PATCH 1/1] ddraw: Limit max texture size to fit a 16bit signed integer

[Marvin]

Hi,

While running your changed tests, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?

Full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=115414

Your paranoid android.

=== debian11 (32 bit Chinese:China report) ===

Report validation errors:
ddraw7: Timeout

=== debian11 (build log) ===

WineRunWineTest.pl:error: The task timed out

=== debian11 (64 bit WoW report) ===

Report validation errors:
ddraw7: Timeout

=== debian11 (build log) ===

WineRunWineTest.pl:error: The task timed out

[PATCH 1/1] ddraw: Limit max texture size to fit a 16bit signed integer

[Henri Verbeet]

On Wed, 25 May 2022 at 02:02, Fabian Maurer  wrote:
> Since ddraw propably never allowed sizes that big anyways,
> this should not cause any issues.

This seems like something it would be easy to write tests for.

[Stefan Dösinger (＠stefan)]

Should we enforce the limit as well in ddraw_surface_create()? Right now wined3d will do it for us if the application requests a texture that's too large.

[Fabian Maurer (＠DarkShadow44)]

Not entirely sure, but this application doesn't care.
Just so I understand correctly, you mean an application can still manually request a 32000x32000 texture when it ignores the caps and would also get it if possible, right?
My personal option would be to allow that, until we should find another application that gets broken by this. The only problem with the big size is that this application expects the size to be able to fit into a 16bit signed int.
Of course, we could also just make it consistent right now. What do you say?

[Stefan Dösinger (＠stefan)]

Yeah, we'll probably end up going this way, but I'd like to do some due diligence here. ddraw caps are an incredibly fragile thing, with applications making stupid assumptions.

There are some GL games that query GPU capabilities via ddraw. I came across at least one ancient game that broke if certain properties mismatched between ddraw and d3d8. (Though I think in both cases games were more interested in PCI IDs and video memory size than minutiae texture stuff)

I'll see if one of my Windows boxes supports large enough textures to check how Windows handles the situation. It's possible that the game is just broken on Windows, or held together by some compatibility shim.

[Fabian Maurer (＠DarkShadow44)]

On Thu Jun  2 13:17:37 2022 +0000, **** wrote:
> Henri Verbeet replied on the mailing list:
> On Wed, 25 May 2022 at 02:02, Fabian Maurer <[e-mail]> wrote:
> > Since ddraw propably never allowed sizes that big anyways,
> > this should not cause any issues.
> This seems like something it would be easy to write tests for.

Those tests would only work if your GPU advertises 32768x32768 textures though. Would the testbot be able to handle that?

[Henri Verbeet]

On Thu, 2 Jun 2022 at 17:39, Fabian Maurer (@DarkShadow44)
 wrote:
> On Thu Jun  2 13:17:37 2022 +0000, **** wrote:
> > Henri Verbeet replied on the mailing list:
> > On Wed, 25 May 2022 at 02:02, Fabian Maurer <[e-mail]> wrote:
> > > Since ddraw propably never allowed sizes that big anyways,
> > > this should not cause any issues.
> > This seems like something it would be easy to write tests for.
>
> Those tests would only work if your GPU advertises 32768x32768 textures though. Would the testbot be able to handle that?

I suspect not, even feature level 12_1 only requires 16384 as maximum
texture dimensions. But a test testing that ddraw never advertises
dwMaxTextureWidth/dwMaxTextureHeight larger than 16384 would still
pass there. You'd need such a GPU to verify the change is in fact
correct, but presumably you already did that.

[Stefan Dösinger (＠stefan)]

Even if we can't test it on the testbot we can test the behavior on real windows machines with a test.

The other interesting thing would be if native ddraw limits the size of sysmem surfaces and/or textures. I vaguely remember that topic coming up in the past too, although I think it was about applications trying to create sysmem surfaces that would occupy more than 4GB of address space.