Proposol: Can me merge this patch to official releases of Blender?

[newillusion]

What we need to accept this path to agreate it into general Blenader release? Is this possible?

[Limezero]

My hunch is that it's probably a bit too hacky to be accepted into the mainline code (reimplementing Windows API functions with hardcoded values). Wrapping the relevant API calls with #ifdef blocks and defining an alternative on Win 7 would be more elegant.

Of course if they cared enough to do that, this project wouldn't need to exist in the first place, so go figure.

[newillusion]

Can we (users of last personal Windows) make a some sort of "soft pressure" on the Blender developers?

[Limezero]

Not in a way that doesn't involve a gun and violating Netherlands law. They seem pretty set on not supporting 7 anymore, even though its marketshare is still higher than every other version of Windows and macOS combined, does receive security updates until 2024, and Blender only uses a handful of API calls exclusive to 8/10. On that note you can also look forward to them dropping 8 and 10 support in the coming years and mandating that everyone uses Win 11 due to "sEcUrITy".

At least Blender is open source, so it only takes 1-2 people to keep up with the changes and support it until the end of time, assuming they don't do anything ridiculous like rewriting the entire application in UWP.

[nalexandru]

A non-hacky solution for Blender would be to check if the entry points exist at runtime and use them if available. That is what they did until this commit: https://git.blender.org/gitweb/gitweb.cgi/blender.git/commitdiff/aebeb85fe013a671f71f47d6f210c192598f408f

As for how long it will still run on 7 it depends, there could be changes to 3rd-party libraries that can't be corrected. Another problem might be after they switch Eevee to Vulkan. While Vulkan works on Win7, it has a limitation, there is a bit of VRAM accessible from the CPU that is not present on 7 and 8.1, but is present on 10 and 11.

[nalexandru]

@Illasera I don't think it's related to your issue. More details on that: GPUinfo report for an RTX 2080, driver version 466.11: Windows 7 - https://vulkan.gpuinfo.org/displayreport.php?id=11469#memory Windows 10 - https://vulkan.gpuinfo.org/displayreport.php?id=11124#memory On Windows 10, there is an additional memory heap (Memory heap 2) which is DEVICE_LOCAL, HOST_VISIBLE & HOST_COHERENT. This is the CPU accessible VRAM i was talking about. AMD exposes this memory on 7, but using it may cause WDDM to move allocations to system memory. (https://zeux.io/2020/02/27/writing-an-efficient-vulkan-renderer)

Regarding memory in SLI: When you say you have 8GB of VRAM in SLI, do you mean 2 GPUs with 4GB each ? If so, the total VRAM you have is 4GB. This is because both GPUs have the same data in their memory due to how SLI works: https://docs.nvidia.com/gameworks/content/technologies/desktop/sli.htm. In SFR mode GPU 1 draws half of the screen and GPU 2 the other half. In AFR GPU 1 draws frame n, GPU 2 frame n+1.

In order to use all 8GB of VRAM, SLI must be disabled and the application must use each GPU independently. This can be done in Vulkan and D3D12, but the only game i know of that does this is Ashes of the Singularity.

Another possibility could be the program you're using is written in D3D9 which has a limitation of 4GB.

[nalexandru]

@Illasera Yes, from what you said it's clear that they don't want to revive Win 7 support.

I must've missed the 1080 bit of the message, yes there are only 8GB versions. Regarding D3D9, i have a single RTX2080 with 8GB. I used the VideoMemory sample provided in the DX SDK and this is the result: