[Bug 45375] Halo Online: Weird black display problems.

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=45375

--- Comment #24 from Paul Gofman <gofmanp at gmail.com> ---
I've tested the game. As already discussed above, there are two absolutely
unrelated problems here, memory exhaustion and 0 * inf handling in shaders. The
latter is a duplicate of bug #34266, so I suggest to make this bug about memory
issue which has some specifics in this case.

1. Memory issue.
    I could immediately reproduce that when loading "Diamondback" level. The
hack I mentioned above is irrelevant here as the game's executable already has
LARGE_ADDRESS_AWARE flag. The memory allocation failures does not occur often,
it seems to happen only around initializing a few big 3D textures by the game
one after another. The sequence is like this:

---
0009:trace:d3d9:d3d9_device_CreateVolumeTexture iface 0C5796C8, width 1536,
height 1536, depth 8, levels 1, usage 0, format 0x35545844, pool 0x2, texture
0032F724, shared_handle 00000000.
0009:trace:d3d9:device_parent_texture_sub_resource_created device_parent
0C5796CC, type 0x4, wined3d_texture 767ACE20, sub_resource_idx 0, parent
767ACFF8, parent_ops 767ACFFC.
0009:trace:d3d9:device_parent_texture_sub_resource_created Created volume
767AD020.
0009:trace:d3d9:d3d9_device_AddRef 0C5796C8 increasing refcount to 16617.
0009:trace:d3d9:d3d9_device_CreateVolumeTexture Created volume texture
767ACDE8.
0009:trace:d3d9:d3d9_texture_3d_LockBox iface 767ACDE8, level 0, locked_box
0032F700, box 00000000, flags 0.
0009:trace:d3d9:d3d9_volume_LockBox iface 767AD020, locked_box 0032F700, box
00000000, flags 0.
0009:trace:d3d9:d3d9_texture_3d_UnlockBox iface 767ACDE8, level 0.
0009:trace:d3d9:d3d9_volume_UnlockBox iface 767AD020.
0009:trace:d3d9:d3d9_device_CreateVolumeTexture iface 0C5796C8, width 1536,
height 1536, depth 8, levels 1, usage 0, format 0x35545844, pool 0, texture
0032F724, shared_handle 00000000.
0009:trace:d3d9:device_parent_texture_sub_resource_created device_parent
0C5796CC, type 0x4, wined3d_texture 767AD080, sub_resource_idx 0, parent
767AD258, parent_ops 767AD25C.
0009:trace:d3d9:device_parent_texture_sub_resource_created Created volume
767AD280.
0009:trace:d3d9:d3d9_device_AddRef 0C5796C8 increasing refcount to 16618.
0009:trace:d3d9:d3d9_device_CreateVolumeTexture Created volume texture
767AD048.
0009:trace:d3d9:d3d9_device_UpdateTexture iface 0C5796C8, src_texture 767ACDE8,
dst_texture 767AD048.

---

The game does that for a few textures. Usually heap_alloc fails in
wined3d_texture_gl_upload_data(), sometimes it is accompanied by GL complaining
about system memory, but once 3d textures initialization is done there is no
new such errors.

So this looks like more like memory fragmentation issue rather than a complete
exhaustion. Besides, uploading 3d textures in wined3d can probably be made much
less memory consuming (as comment in wined3d_texture_gl_upload_data()
suggests), which I suppose may solve the issue for this game.

The workaround that worked for me was changing texture resolution to 'Medium'
in game settings.

Another interesting workaround was to disable CSMT
(HKCU\\Software\\Wine\\Direct3D\\csmt set to 0, DWORD value). With CSMT, the
internal wined3d memory allocation goes in parallel with the next 3D texture
creation, and the memory is exhausted. With CSMT off and thus sequential
operation, I did not have memory allocation errors, so it was enough continuous
memory to hold the texture + convertion buffer once, but not twice). I don't
know how stable this workaround is though, did not test it much.

2. 0 * inf issue

    With the memory issue worked around by setting texture resolution to
medium, I briefly tested a few maps for this problem. Without any tweaks the
apparently corrupted image parts were present in a few maps. With
multiply_special = 2 Staging workaround (which is a more thorough one), I could
not spot any apparent glitches. With multiply_special = 1 I detected only one
in "Edge" map: some herbs hanging on the rocks were completely black. That was
due to the overflow in POW operation in a couple of shaders. Adding a clamp to
[0, FLT_MAX] range in POW solved the issue with 'multiply_special = 1'. The
staging patch is updated to include the workaround for RSQ function (in
addition to RCP, RSQ and LOG).
    If you find more glitches with the latest change in Staging and
multiply_special = 1 or 2 (after working around memory issue and having log
clean from that), it would be great to know.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.