[PATCH 0/1] MR126: Draft: ddraw: Limit max texture size to fit a 16bit signed integer
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 <dark.shadow4(a)web.de> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/126
From: Fabian Maurer <dark.shadow4(a)web.de> 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 <dark.shadow4(a)web.de> --- 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; -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/126
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
On Wed, 25 May 2022 at 02:02, Fabian Maurer <wine(a)gitlab.winehq.org> 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.
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/126#note_1199
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? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/126#note_1214
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/126#note_1235
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 <wine(a)gitlab.winehq.org> 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?
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/126#note_1518
On Thu, 2 Jun 2022 at 17:39, Fabian Maurer (@DarkShadow44) <wine(a)gitlab.winehq.org> 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 <wine(a)gitlab.winehq.org> 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.
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/126#note_1520
participants (5)
-
Fabian Maurer -
Fabian Maurer (＠DarkShadow44)
-
Henri Verbeet -
Marvin -
Stefan Dösinger