I was just going to leave this one alone, since it was clear OP was just getting defensive, and there was nothing more to be gained, but as I see other people are reading the thread, I thought it would be prudent to at least raise the risks of enabling resizable bar, and explain why 7D2D doesn't really benefit from it.
1) To enable Resizable Bar, you need to disable CSM (Compatibility Support Module). If you do this and are using non-UEFI devices - especially a non-UEFI hard drive, you can completely break your computer to the point where it will not boot. This is temporary, and re-enabling CSM will fix it.
2) 7D2D is CPU bound. Not GPU bound, and definitely not VRAM bandwidth bound. You can check this for yourself by pinning task manager "always on top" with the GPU usage stats visible. You'll probably have 4 cores running at about 80%, and other cores soaking up the other 10-20% (Hyperthreading makes a single physical core look like two cores which then share time.) Meanwhile, most modern GPUs will be sitting around 30-40% utilisation even on quite high resolutions and texture qualities.
3) I used an over simplified analogy above to explain how resizeable bar works, and either misled OP, or gave him some kind of confirmation bias. It's not quite as simple as that. PCIE 4.0 16x - which is what most modern Resizable Bar GPUs would be running on (Some vendors back ported it into PCIE 3.0, but let's ignore that for now) - can move data at 32Gbps. Resizeable bar or not, that's the speed limit. The 7D2D VRAM usage is around 3-4GB, depending on your settings. In other words, in an ideal world, you could load your entire set of textures in a little over 1 second. (Being 8 bits per byte, plus overhead so 32 gigabits per second, is about 3.2 gigabytes per second).
Without resizeable bar, that 3-4GB needs to be broken down into 256MB chunks, and each chunk will be sent separately - But it will still be sent at 32Gbps - there is no change in speed. What there is, is a bit more overhead in the CPU to package that data, and signal to the GPU that it wants to write to the VRAM. By sending 1 x 4Gb, instead of 16 x 256Gb, you can save a bit of overhead.
Whether resizeable bar benefits the game depends on how it was originally loading textures. If it tried to load up all all the textures at once in very large chunks, then you will see improvement. If it tried to load up smaller textures over time as needed, then you won't see much improvement. Indeed, if the loads were under 256Mb in the first place, you might even see degradation, as there's an extra step to actually do the resize.
7D2D textures tend to be reasonably small. I mean, look closely at the ground, do you see nice sharp pebbles and soil? Nope. They're scaled up from lower resolutions. So whether you're running 1080p or 4k, you're not going to see a huge improvement from enabling resizeable bar, which is exactly what Naz found in the post I linked.
By all means, if you know what UEFI and CSM is, enable resizeable bar (But I suspect if you did know what it is, you would have already enabled resizeable bar). It's free performance gain for the majority of modern games. But it's also only about 5-10% with the occasional game that gets more than that, and some games will suffer. However, if you were hoping that enabling resizable bar would give you an extra 35FPS+ or 55% performance boost, sorry to disappoint you, it's not likely to happen, and in the worst case, you could make your PC non-bootable.
for 
