Support for Titan X

[narphous]

Hi Boris,

Since the new Titan series cards come with 12GB of frame buffer memory and ENB is currently limited to 10GB, will you be increasing the supported frame buffer memory? Or do you expect that current ENB binaries will work fine, just not take advantage of the additional memory? Or is it not correct that VideoMemorySizeMb is limited to 10240 as a maximum setting?

[kingeric1992]

VideoMemorySizeMb is not limited at 10gb, it is up to 192gb as I recalled. check the enb download page, there is a update log about this.

[ENBSeries]

Definetly limit is much bigger, you are wrong.

[narphous]

I never said it was limited to 10240, but everything I found says it is. I missed the update log saying it'll support up to 128 GB, but it is in the readme. So really, that's all you had to say.

[ENBSeries]

readme:

Version 0.250:
Changed ENBoost, now it support up to 128 Gb of memory or about 192 when compression enabled

[Sigurd44]

Hi Boris,

I ordered 2 x EGVA Geforce Titan X for SLI and as a first step for my future UHD setup (displays in lower price segments still lack somewhat, TN-Panels aren't the best for displaying colors and for point of view impressions) and I wonder what values I need to set in the enblocal.ini for such beasts. I still have 16 GB DDR3 system RAM.

In your enblocal.ini guide you explain that VideoMemorySizeMb=x should set to the amount of VRAM you actually have and use (for SLI systems just the VRAM of one card, because in SLI you won't double your VRAM amount/usage). So for my current Titan classic cards I should set that to 6144. Many others I know and myself too, set that even to higher values and it seems to work out well (10240).

On the other side you often stumble over a formula for setting VRAM in the enblocal.ini on the internet: VRAM + RAM - 2048 (...and I have no idea where this formula actually comes from and how true it is...).

What would be a solid value for a 12 GB VRAM Titan X card (SLI) while running 16 GB system RAM ?


PS: Btw, anyone did read about the rumors that VRAM in SLI systems might become or might be in theory already stackable in SLI DX12 systems ? How probable is that ?

[ENBSeries]

Btw, anyone did read about the rumors that VRAM in SLI systems might become or might be in theory already stackable in SLI DX12 systems ? How probable is that ?

Do you know how much slower mod is running with sli/crossfire and temporary antialiasing enabled? Performance is almost twice lower, like single card is used. Current bridges do not provide fast enough bandwidth for sharing vram between several videocards, nobody need extra memory which have horrible latency and speed, system memory have the same "features" already.

VRAM + RAM - 2048

It do not work, was made by me only for certain systems. Total memory available for videocard can be viewed by special tools as summ of vram and some ram (minus os memory and some software, like browsers), so use it (autodetect vram size also compute this, probably i need to write it to statistics window). For stable performance (but stuttering at some conditions), set size a bit lower than vram size.

[Sigurd44]

Btw, anyone did read about the rumors that VRAM in SLI systems might become or might be in theory already stackable in SLI DX12 systems ? How probable is that ?

Do you know how much slower mod is running with sli/crossfire and temporary antialiasing enabled? Performance is almost twice lower, like single card is used. Current bridges do not provide fast enough bandwidth for sharing vram between several videocards, nobody need extra memory which have horrible latency and speed, system memory have the same "features" already.

I saw posts where people said that it is possible in theory, but mentioned the same reason like you, that it won't work out well practically and performance wise. I didn't knew that temporary AA actually works with SLI enabled at all. I always set that to false in your local.ini. On 1440p (in future maybe even 2160p) my demand for AA is next to nothing anyways. Such pixel loads are like "inbuilt" AA.

VRAM + RAM - 2048

It do not work, was made by me only for certain systems. Total memory available for videocard can be viewed by special tools as summ of vram and some ram (minus os memory and some software, like browsers), so use it (autodetect vram size also compute this, probably i need to write it to statistics window). For stable performance (but stuttering at some conditions), set size a bit lower than vram size.

Thx.

[Jafin16]

Do you know how much slower mod is running with sli/crossfire and temporary antialiasing enabled? Performance is almost twice lower, like single card is used. Current bridges do not provide fast enough bandwidth for sharing vram between several videocards, nobody need extra memory which have horrible latency and speed, system memory have the same "features" already.

Is this information only for ENB or does it apply to all games/real-time graphics more or less equally? Also, with their Hawaii chips first, later Tonga and soon Fiji and a number of new GPU's, AMD has made a bridge unnecessary and the multicard interconnect happens directly through the PCI-E bus. Nvidia will likely come up with a similar solution for SLI soon, but anyways, could this method make the latency less and increase the speed and thus make VRAM sharing between GPU's a viable option?

Sigurd44
Btw, I heard it may also be possible in DX12 applications to use both Nvidia and AMD cards in tandem... not sure if that's still on the table but presents some interesting possibilities.

[ENBSeries]

Jafin16
Low performance of ENBSeries when temporal antialiasing enabled and SLI/Crossfire is a fact for any videocard. There is no much data to transfer between videocards each frame, about 4 copies of screen resolution 32 bit buffers, but the drivers fails to do that, because SLI/Crossfire is just driver hack not guaranteed to work.
Transfering data between videocards via PCI-EX is not better than crossfire/sli bridges. The general idea of shared vram is fail, because main reason videocards are fast is huge vram bandwidth, there is no way to work with huge textures and render targets at good fps when you insert any latency barrier, it's worse than simple lower bandwidth. The only possible usage of dx12 shared memory between videocards is procesing something small in parallel on second gpu at beginning of the frame, then start to send result to main videocard somewhere at the middle of frame and recieve full copy for usage closer to end of frame. But on practice this is hard to implement, because drivers accumulate commands for execution instead of draw immediately, syncing processing of two cards kills performance. If developer will take control over this process, performance will be much lower, because they do mistakes in general and when things comes to optimization, it's just *facepalm*.