st/nine: Hack to generate resource if it doesn't exist when getting view

Buffers in the MANAGED pool are supposed to have the content in a ram buffer,
a copy in VRAM if there is enough memory (driver manages memory and decide when
to delete the buffer in VRAM).

This is not implemented properly in nine, and a VRAM copy is going to be created
when the RAM memory is filled, and the VRAM copy will get synced with the RAM
memory updates.

Due to some issues (in the implementation or in app logic), it can happen
we try to create a sampler view of the resource while we haven't created the
VRAM resource. This hack creates the resource when we hit this case, which prevents
crashing, but doesn't help with the resource content.

This fixes several games crashing at launch.

Acked-by: Axel Davy <axel.davy@ens.fr>
Acked-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Stanislaw Halik <sthalik@misaki.pl>
Cc: "10.4" <mesa-stable@lists.freedesktop.org>

diff --git a/src/gallium/state_trackers/nine/basetexture9.c b/src/gallium/state_trackers/nine/basetexture9.c
index efa884f4ac0853f093d6d3fa7f4bb2e53b193b26..6341dd35ac08e8457012b49e3eaad718dbb10dd0 100644 (file)
--- a/src/gallium/state_trackers/nine/basetexture9.c
+++ b/src/gallium/state_trackers/nine/basetexture9.c
@@ -457,6 +457,9 @@ NineBaseTexture9_UpdateSamplerView( struct NineBaseTexture9 *This,
        if (unlikely(This->format == D3DFMT_NULL))
             return D3D_OK;
         NineBaseTexture9_Dump(This);
+        /* hack due to incorrect POOL_MANAGED handling */
+        NineBaseTexture9_GenerateMipSubLevels(This);
+        resource = This->base.resource;
     }
     assert(resource);