[FIX] Small resources are given more memory (solves issues with mipmaps)

[Dietr1ch]

LoL's shop worked for me after this patch, the games was not worth playing without it, it's like playing CS without guns.

I don't fully understand why this works. The patch was suggested at Arch's wiki.

This shouldn't break anything, but it will make small allocs bigger :c

[Haringat]

This is more a hack than an actual solution. It just looks whether the size of a ressource is smaller or equal to 64x64 and then doubles (or maybe even quadruples?) the size of its buffer so that if a mipmap is created for the image there will be enough space for it to fit in. This is wasteful (because a texture with mipmap is always 4/3 of the original texture size) and does not always work as you get problems with mipmaps for textures bigger than 64x64 (e.g. 128x128) and on small images that do not use mipmaps it would be even more a waste. In my opinion a better solution would be to allocate a new buffer when the mipmap is actually created, copy the original image in there and then create the mipmap on the new bigger buffer and free the old (no longer needed) one.

[Dietr1ch]

It's indeed hackish, but it served as a quick workaround to play lol at the time. I'm not familiar with computer graphics, but definitely memory is being wasted if only 1/3x extra memory is needed (instead of 3x extra).

The patch is wasting resources, but for the time being it's better than getting terminated by the kernel, although I'd prefer a memory efficient patch.

[Haringat]

Actually the memorywaste is a pity but i think the bigger problem with this hack is that it (as i mentioned before) only works for textures up to 64x64. And if 4k gaming becomes standard we will have bigger textures (and their mipmaps) in games and we will again have segfaults. Of course you could then raise the limit in the code to let's say 256x256 but then each single graphic that would be up to 256x256 would be given 4 times the space needed no matter if they actually use mipmaps or not. So until we have a memory-efficient patch I would advice to not merge this patch.

And for LoL: I used tuxlol when I played LoL. I think it just removes the mipmaps from textures.
https://bitbucket.org/Xargoth/tuxlol/wiki/Home

[Dietr1ch]

I understood that the patch is not general enough, but it still allows lol to run.

Basically we should be replacing the patch by:
UINT size = (4*resource->size+2)/3;

which would allocate ceil( 4/3 * size) and get the extra third space for the mipmaps.

right?

[Haringat]

Basically yes, although I have no idea how opengl aligns the smaller versions on the plain. That could still lead to problems...

[Dietr1ch]

At least the 2x alloc seem (not 4x) to work fine for small cases (< 64x64 as on the original path), but it will probably be a waste until someone with deeper understanding/knowledge of computer graphics, d3d and opengl review this.

[ghost]

The solution can also be to try another component. AMD and Nvidia never gave same result. Drivers update and etc.

[mrpippy]

@Dietr1ch I'm trying to find out who created/admins this repo (wine-mirror/wine), do you know? This is the first pull request on the repo.

[yurikoles]

@Dietr1ch I'm trying to find out who created/admins this repo (wine-mirror/wine), do you know? This is the first pull request on the repo.

As you said, it's just a read-only mirror. From the README:

• Gitlab: Wine development is hosted at https://gitlab.winehq.org

[Neustradamus]

Dear @wine-mirror team,

I would like to know who manage this organization and this repository.

Thanks in advance.