Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Hmm. I'm looking at your GPU-Z memory numbers and I have a bit of a guess: Can you try loading increasing scene sizes and report the GPU-Z numbers versus the numbers reported by Octane Render? And if possible, try to fill it up all the way to max?
Test scene - Snow Bison and Snow mountain
Geometries used
- 1 high poly count Bison with fiber hair
- 1 high poly count mountain terrain
- - -
- - -
VRAM on card 6144 MB (dedicated rendering GPU not assigned to the display)
Total VRAM available for use 5087 MB
VRAM used by scene 3621 MB
- Engine runtime data 341 MB
- Image textures 188. 3 MB
- Geometry 3 GB
etc.
-> unavailable VRAM 1 GB
- - -
Please keep in mind that you can download the OctaneRender demo and test this for yourselves.
https://home.otoy.com/render/octane-render/demo/
- - -
I used the previous scene and kept adding new objects by connecting them to the geometry group.
Test scene - Filling VRAM 4867 - 5082 - 6144
Geometries used
- multiple random .obj, .abc
- - -
- - -
VRAM on card 6144 MB (dedicated rendering GPU not assigned to the display)
Total VRAM available for use 5082 MB
VRAM used by scene 4867 MB
- Engine runtime data 341 MB
- Image textures 730. 3 MB
- Geometry 3.7 GB
etc.
-> unavailable VRAM 1 GB
- - -
@ differences in numbers
The differences between the numbers in GPU-Z and OctaneRender are around 100MB.
I would not get hung up on that but rather worry about the 1 GB that is not useable...
People who tested this with the GTX 1080 reported numbers around 2GB that are not useable.
Even higher numbers were reported when using Titan X and the Pascal Titan X
- - -
@ What happens if you go beyond the limit on the VRAM impossed by Windows 10:
IF you go beyond the limit impossed by Windows 10
- in OctaneRender your render will simply fail
- in Iray you fall back to the CPU render mode
- on a card with 6144 MB VRAM GPU-Z stopped detecting addtional geometry added to the scene at 5149 MB:
well I seem actually to have a bit over 6GB useable on my 980ti and have actually had scenes that use 6GB
not sure how that works
Without further information my guess is that you simply did not notice that Iray defaulted back to CPU render mode...
when I can I will post one, in Octane render standalone
am busy rendering something at the moment
Yeah, these new numbers are totally unexpected. For reference, I've been able to render a scene all the way up to almost the full 4GB on my card with zero issues, with GPU load at 100%... Hmm.
Occasionally, I do notice that my card loads the scene into VRAM but the GPU doesn't "work". That was solved by closing and reopening DAZ Studio. That may not be related to this issue, but thought I put it out there as there *is* a bug with continuously loading and unloading scenes into VRAM.
If it has video ouputs then W10 is going to create a framebuffer for it -- period. It is to keep the card from crashing the system if an output is attached. When MS created Win2000 they moved the video drivers below the HAL (hardware abstraction layer) instead of being controlled by it. That means that a video card fault can completely lock the system and can't be caught. This situation is the same today. Earlier systems allocated a standard VESA framebuffer at 8 bit for this purpose (hence the reason many systems flickered to a blank black screen before showing the desktop), however some modern monitors CANNOT display a VESA screen (out of range errors) so MS ended up allocating a full fledged DIB for the screens. This can take a serious amount of VRAM depending on the numbers that are returned by the card's hardware to the gfx subsystem in use. The more "enhanced" the desktop the more VRAM will be reserved. If you're using all of the "bells and whistles" on your desktop then that is what will be used for the allocation.
There are hardware "justifications" for this and it is why MS is not entertaining the efforts to "fix" it.
Kendall
Kendall, I pointed that out earlier, but the most recent test numbers presented above has a separate card driving the display.
I think Kendall is saying this happens if the card could drive a dispaly, regardless of whether or not it is doing so. The fix might be, if possible, to disable the video outputs on the card (internally, not just ripping the hardware off the outside).
If the card has video outputs even if not used (see Kendall's statement above).
Indeed. If the card HAS THE HARDWARE to host a display, a framebuffer will be allocated for it whether it has a display physically attached to it or not. As a "for instance": a Quadro FX-5800 and a Tesla C1060 are the same hardware except that the C1060 has no capability to generate a display. Windows will allocate a framebuffer for the FX-5800 but will not for the C1060. This is the case whether the FX has a monitor connected or not. The buffer is created *in case* a monitor is connected while the system is running. The more "displays" the card is capable of running, the more memory is allocated. If the card can run 4 physical displays, then windows will allocate 4 buffers, even if only 1 display port is used and even if no ports are used on the card.
As I said there are "justifications" for this behaviour, but these are only applicable to WIndows and the way the video is handled there.
Kendall
Hm, Windows allocating framebuffer regardless? I should test this out myself with the OctaneRender demo when I have the time.
My experience has been that the framebuffer is not loaded onto my PEG from a cold boot if I'm running from my IGP, but GPU-Z may not be reporting the reserved VRAM correctly...
BTW everybody, none of this is new and has been the case since W2K. In the past, though, the amounts of VRAM used by the framebuffer was minimal since only a base VESA screen needed to be allocated. Those who use VMs are well aware of this requirement because almost all of them will scream if a Windows VM session is set up without appropriate "VRAM" amounts in place for the resolutions expected for the hardware.
I think the big "issue" is the vast amounts of VRAM that W10 is allocating due to all of the "eye-candy" that comes as default. Even as far back as W7, WIndows could become a card hog if Aero with all of the 3D bits were activated and the card lacked the VRAM. Those with integrated graphics and shared memory set too low in their BIOS ran into this problem HARD back then.
SOOOO.... it really isn't something to be surprised about. If you use Windows, it is part of the "price you pay."
EDIT: Also, the move of the video drivers to below the HAL was the reason that the original Windows NT crew resigned their positions at Microsoft in protest and a major reason that the BSOD was/is so prominent an issue with Windows.
Kendall
Thank you all for providing valuable background information that makes it a bit easier to understand what is going on.
- - -
I now retested the scene with two GTX 1080:
VRAM on card 8192 MB (dedicated rendering GPU not assigned to the display)
Total VRAM available for use 6689 MB
VRAM used by scene 4479 MB
- Engine runtime data 341 MB
- Image textures 681. 3 MB
- Geometry 3.4 GB
etc.
-> unavailable VRAM 1.4 GB
- - -
update / edit:
removed addtional commentary to keep this entry shorter and focus on the test results
- - -
Update - Test with GTX 1080 Ti:
As far as you can gather from other threads the issue of a significant amount of VRAM not available for use with Windows 10 is still being bounced around between customers trying to contact Microsoft and Nvidia Support.
A crucial factor in tracking down this issue is the lack of software that properly indicates VRAM usage under Windows 10.
This is the reason why I post my test results with the latest version of OctaneRender standalone that features detailed information about VRAM usage during rendering.
I update this thread with my latest test results in order to have at least some results in the same place that show how the amount of VRAM reserved by Windows 10 has continued to increase with each new GPU.
- - -
@ Where can I find more information on this issue?
Microsoft Technet
https://social.technet.microsoft.com/Forums/windows/en-US/15b9654e-5da7-45b7-93de-e8b63faef064/windows-10-does-not-let-cuda-applications-to-use-all-vram-on-especially-secondary-graphics-cards?forum=win10itprohardware
Reddit
https://www.reddit.com/r/skyrimmods/comments/4khp06/gtx_1080_and_windows_10_4gb_vram_limit/
AnandTech
https://forums.anandtech.com/threads/losing-1-8th-of-total-usable-vram-with-cuda-and-353-62-w10.2442754/
Otoy (login required)
https://render.otoy.com/forum/viewtopic.php?f=12&t=51992
- - -
@ Users with cards with 4 GB of VRAM or less
I am aware that many users on the DAZ3D forum may use cards with 4 GB and less may not be able to observe this issue.
-> In the Nvidia Geforce driver documentation you can read about VRAM TAG reporting issues that
appear with cards that have more than 4 GB of VRAM. Nvidia categorized that issue
"Known Product Limitations", "beyond the control of NVIDIA"
http://us.download.nvidia.com/Windows/375.70/375.70-win10-win8-win7-desktop-release-notes.pdf
Speculation:
I currently am not aware of any official verification that those issues are directly related.
But some reports by users suggest indeed a connection between
- Windows Display Driver Model (WDDM) -> reserving VRAM under Windows 10
- and the way the Total Available Graphics memory (TAG) is reported.
- - -
@ Latest Test results with GTX 1080 Ti
Test computer setup:
Display: 1x Asus GTX 1080 STRIX A8G
Rendering: 2 x Asus GTX 1080 Ti FE
Nvidia Driver: 361.85
Tested with OctaneRender Standalone 3.06 Test 4
- - -
-> Windows 10 is reserving 2 GB of VRAM of 11 GB cards.
- - -
Escalation of unavailable VRAM space:
Windows 10 is reserving 1 GB of VRAM of 6 GB cards
Windows 10 is reserving 1.4 GB of VRAM of 8 GB cards
Windows 10 is reserving 2.0 GB of VRAM of 11 GB cards
- - -
If you can observe this issue yourself please contact Nvidia and Mircosoft support with your test results.
This community is small the voice of everyone counts.
Please do not wait around and hope this will be resolved on its own without additional feedback from more affected users.
If DAZ3D staff is willing to help a huge step forward would be to add tools that monitor and display VRAM usage with Nvidia Iray to DAZ Studio as well!
- - -
As Kendall pointed out that is not a bug but an intended design meant to stop video cards from crashing Windows 10.
I don't have an nVidia card but it would be interesting if this new Windows 10 'Gaming Mode' would decrease the amount of VRAM to reserving for itself. One might be able to run DAZ Studio in Windows 10 'Gaming Mode' However, from what I read about Windows 10 Gaming Mode it didn't mention anything of the sort but sounds more like Windows 10 throttles these terminate and stay resident daemons while in gaming mode.
Update / Edit:
Rephrased this post to be more precise.
Kendall gave great background information how the reasoning behind this might (!) have been.
Nevertheless that "intended design" is not something customers should accept.
Furthermore the replys posted by official microsoft and nvidia staff to customer requests based on this matter gave no indication that this "VRAM reservation" is intended or a known behavior.
However that may be in the end it is not a question if it is a "bug" or not.
-> A decision was made conscious or unconscious somewhere at microsoft to change the working VRAM behavior from windows 7 to windows 10.
This now has a huge negative side effect on not only people using GPU rendering but any other people that use GPU for calculations (AI research) or other design applications that rely on VRAM.
- - -
No, Kendall was not guessing. Windows 10 is designed that way as a security feature.
No, Kendall was not guessing. Windows 10 is designed that way as a security requirement.
Update / Edit:
Rephrased to focus on what exactly is troublesome with the current situation.
I rephrased my last post to be more precise. Please read it again to clear up any potential confusion.
- - -
I made this thread in order to raise awareness for a situation that has a huge negative side effect on our hobby or job when rendering with multiple GPU.
Do your really want this trend to continue?
What about when cards with 16 GB VRAM arrive on the market?
Then it would be acceptable that a huge amount of potentially 3+ GB may not be available?
We struggle for every bit of VRAM with GPU rendering. It is not acceptable that VRAM we paid for (!) is just wasted.
It was working with windows 7 and it is reasonable to propose that the same behavior is restored with windows 10.
- - -
How do you explain that both microsoft and nividia customer support are still not able to properly answer any inquires about this issue?
If this extreme VRAM reservation that continous to grow with each new card that offers more VRAM was intended behavior then they surely would say so, wouldn't they?
- - -
Hey thanks for posting a link. That is way better than the gup tool EVGA gave us with our graphic cards.
Much appreciated
Agreed; reserving memory if there is no monitor connected is just rediculus. It should only be reserved if there is one connected, not based on the possibility of one being connected.
..all the more I'll stick to W7. These cards are expensive enough on my tight budget. Not thrilled about getting less performance than I paid for because of an OS 'feature".
Whether it was a "security design" or not, the behavior of allocating VRAM on the off chance that a monitor will be plugged in while the OS is running is unacceptable when that VRAM is not released after a reasonable time.
If the video card manufactures gave us a way to disable video ports/hide them from the OS then we could at least work around the issue.
I personally dont see Win10 Pro 1607 build on my machine hording Vram at all.
CPUID and GPUz both show about 90mb vram used on the main card and only 3MB on the second card when idle.
Both are Zotac AMP Extreme 980TI - 6GB.
I have rendered images recently that had 5 or more Genesis figures in it where each had diffuse, normal and SSS maps and it did not crash or fall back to the CPU.
CPUID and GPUz do NOT show you the amount of unavailable VRAM
Those tools show you the total amount of VRAM actively being used.
Windows 10 reserving / blocking VRAM means:
On a 11 GB card you can add geometry and textures up to 9 GB and then you will notice that you cannot anymore add more.
I tested this behavior myself and posted the results above,
https://www.daz3d.com/forums/discussion/comment/1718261/#Comment_1718261
-> Windows 10 RESERVES / BLOCKS VRAM and prevents it from being used. It is not actually USING it and thats the most ridiculous part of this whole situation.
- - -
CPUID and GPUz were NOT created with the intention to show the remaining VRAM available for rendering.
It does not show you
- the exact amount used for geometry
- the exact amount used for textures
- the exact amount used by other software
- the amount not available at all because it is blocked / reserved / but not used by windows 10
- - -
OctaneRender standalone clearly was designed by an experienced company familiar with GPU rendering.
If you do not trust me, fine.
But please trust Otoy as a company to be competent enough to create software that shows the real available amount of VRAM. You can download the demo version and test this yourselves!!!!
https://home.otoy.com/render/octane-render/demo/
- - -
It can be disabled; I have done so, plus a lot of other stuff.