http://bugs.winehq.org/show_bug.cgi?id=34480
--- Comment #7 from Stefan Dösinger stefan@codeweavers.com 2013-09-23 09:41:45 CDT --- Created attachment 46054 --> http://bugs.winehq.org/attachment.cgi?id=46054 Test case
Wine supports compressed mipmaps smaller than the block size just fine. The problem here is that LoL writes past the end of the first mipmap (Usually 64x64 one), causing a memory corruption. By luck it only happens to do that with textures that have mipmap levels < 4x4.
It gets away with the broken memory write on Windows because the texture is a D3DPOOL_MANAGED texture and Windows allocates the memory for all mipmaps as one block. Thus when it writes past the memory of level 0, it just writes to the memory of level 1, 2, 3, etc. On Wine it writes into memory owned by the heap manager.
The proper fix to do is to fix LoL itself. The next best thing is to replicate Windows' memory allocation strategy. To do so, we have to move responsibility for allocating memory from the individual surfaces to the containing texture.
The attached patch is a test that tests the memory allocation behavior of Windows. A quick and dirty workaround would be to allocate twice the amount of memory for each resource in wined3d_resource_allocate_sysmem().