Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
I think the misconception is the belief that if you use Linux you'll be more secure than if you use Windows. Personally, the only security issue that has affected me in the decades I've been using computers is the Equifax fiasco, which had nothing to do with Windows or Linux. It was a 3rd party that held my data, along with over half the US population. Otherwise, I don't recall EVER being a victim of a hack.
Nobody can say that Linux will be more secure in the future, only that "well, we think it should be..". But the vast majority of users never get hacked, so does it really matter? What matters is stuff like 3rd parties holding our most important data and not knowing how to take care of it, because that actually happened.
Seriously; you can wipe the whole system with a command, and Linux lets you. It looks like to me, that Linux presumes users have a clue and are adults (or at least responsible), whereas Windows considers all users idiots.
Let's drop the Linux vs. Windows stuff please, it's a distraction from the main topic even if it is unusually civil on this occasion.
To the main purpose of the topic, I didn't know that Windows 10 reserved vRAM, I will check that and come back after .. But from now I'm not at my home.
I will be at my home this night !
Perhaps the fact that other very popular threads are joking about illegal drugs and marmalade leads others to believe that sticking to the topic (whatever that may be) isn't that important. Please forgive our confusion.
What's illegal in the US may not be in other countries.
And what's a misdemeanor on the US carries a death penalty, or lengthy prison sentence in other countries. What's your point?
The thread referred to isn't on a substantial topic, this thread is (and it isn't the topic of what posts are allowed, if you have queries please email the forum team).
Just being a bit nitpicky, I think you mean WannaCry. WannaCry is ransomware malware that is effectively migitigated by keeping up on updates from Microsoft as well as blocking inbound connections from any source on port 445. The malware starts out as probes on port 445 using two exploits: DoublePulsar or EternalBlue--both of which were revealed by WikiLeaks releases of old NSA exploits.
I have combated this malware at a very large company and can safely say if current Windows updates are installed and you have an Internet facing firewall blocking all incoming port 445 connections (both TCP and UDP) you will be safe against this malware unless you have a laptop or other portable Windows based computer that you use outside your personal network. In that case, make sure your anti-virus is up to date,, your AV firewall is blocking incoming 445 cnnections and do not enable file/drive sharing. Port 445 is used for Windows file/drive sharing.
If you are in a large corporation, IPS with current signatures applied and properly configured, there should be no issue. IPS will stop this at the border and internally if so deployed.
The only way to be safe with Windows is to keep your computer off the network. That said, it's impractical. So keeping up on Windows and antivirus updates is your best protection. Currently I use McAfee and Malwarebytes together and have run into no issues with DAZ and those AV products. Your mileage may vary.
Scott
Back on the main topic about VRAM reservation in Windows 10:
Skipped some pages when it went off topic, so I might have missed something.
People where discussing how much VRAM would be required to hold a single screen frame.
From a raw standpoint at 8 bits per color per pixel, a 4k (3840*2160) being renderd at 32bit depth (Red ,Green ,Blue ,Alpha):
3840x2160 = 8,294,400 pixels
Each pixel requires 32bits of data
265,420,800 bits or roughly 33MB
This number is all fine and dandy until you take into consideration that every item on your screen is handled as a direct3d object.
A maximized web browser window will take at least 33MB of texture memory for example. It's most likely storing all of your open tabs as it's own textures. Start menu, task bar, all of the system icons, mouse cursor, and desktop background are all their own D3D objects. Heck as you read this Kyoto Kid's animataed gifs are using some of your avaliable VRAM.
On top of this you need to have enough VRAM set aside to run all of the built in windows annimations and transitions.
Very interesting as always @JamesJAB !
Don't know if that works, as I'm still on Win7 but the following link may be a solution
https://docs.nvidia.com/gameworks/content/developertools/desktop/nsight/setup_local_headless_debugging.htm
It's called Linux; sadly, getting Studio to work on it is doable but does take time.
If you're referring to a solution for the "Windows 10 grabbing VRAM" issue, I don't think the linked article is really relevant. I recently posted in the DAZ Studio forum in a thread with a similar topic and described the real issue based on info from NVIDIA.
Bottom line, Windows 10 does NOT greedily "grab VRAM". In fact, I've done tests that show across multiple processes I can fill my GTX-1080ti's 11 GB of VRAM to over 10.7 GB.
What W10 DOES do is make it so that any individual process cannot greedily grab too much VRAM, making it unavailable to other processes. NVIDIA has said that from their discussions with Microsoft they've determined that CUDA can allocate up to 90% of the GPU's VRAM, and an individual process within that can allocate 90% of that 90%, or 81%. My tests using CUDA code I wrote (using "cudaMalloc()") has shown that an individual CUDA process can grab up to about 82-83% of installed VRAM.
Since one of the primary jobs of an operating system is to manage each application's access to the system hardware resources, it's also responsible for making sure each process has reasonable and fair access to those system resources. So Windows 10 doesn't greedily block off a bunch of VRAM and keep anyone from using it. In fact it allows virtually all of the VRAM to be used across all processes. I believe I posted an image in the other thread showing 10.8 of my 11GB VRAM being used by all system processes.
And no, Desktop Windows Manager doesn't grab a ton of VRAM for display purposes. My 1080ti is running 3 monitors, and the dwm process generally uses less than 0.3 GB.
Now you may argue that 81% for an individual process is a bit tight, and I'd tend to agree, although I'm not the type to fire up a video game while waiting for a render. But apparently NVIDIA has requested that Microsoft change that limit, so I'll be interested to see what happens in the next Windows 10 update.
Don't know if it's effective. Headless for me means No Display. No Display = no reservation for Framebuffer. That is the case in TCC mode.
Then 90% of 100% is better than 90% of 90%.
Please be aware that this thread was created in October 2016 and was reactivated after almost a year without activity.
The following questions had been submitted in request Request #273017 on June 5, 2018:
"1) Based on what rules does Iray assign VRAM to the workspace?
2a) What does the log entry at startup of DAZ Studio 11 GiB total, 9.14774 GiB available actually indicate?
2b) Why is the entry not indicating 11 GiB total, 11 GiB available on GPU devices that have no display attached?
3) Can the DAZ 3D or Iray developers comment if the issue with Windows 10 and VRAM allocation made public by Otoy in 2015 still exists?"
The last status update by DAZ3D staff was on September 12, 2018:
It was confirmed that the questions had been forwarded to the devs but support staff has not received any information.
Support staff will share an answer when they get one.
- - -
linvanchene, like I posted above yesterday I already have a recent answer from NVIDIA.
I will not participate in any further speculation or debate about information without a public source.
For those interested it seems reasonable to wait for an official public answer by either DAZ3D or Nvidia staff to fully understand what those numbers mean in the DAZ Studio Iray log file.
.
Yeah, it's definitely true. Below is a screenshot of my total GPU VRAM usage while running DAZ Studio plus another app with some CUDA code I wrote in Visual Studio to load the VRAM up to the limit it could allocate (> 81% of installed VRAM). And yeah, it got up to around 10.7 GB of the installed 11 GB.
I think the confusion comes in due to the mistaken belief that W10 somehow grabs 1-3 GB of VRAM on a 1080ti and blocks it from ANYONE using it. That's just not the case. However, what is true (and confirmed by the NVIDIA response I mentioned, as well as my CUDA tests) is that any one process can't access more than around 81-83% of installed VRAM.
Personally, it seems reasonable that an OS would limit how much system resources an individual process can grab, especially since if I'm writing code I'd want to grab as much as I could.
But I'd much rather have Windows accept a user setting that allowed us to adjust that limit.
BTW, here are the details about what I did to get over 10.7 GB of VRAM used on my GTX-1080ti. The image below (CLICK IMAGE TO ENLARGE) shows the console output of the CUDA code I wrote (called "MemAvail.exe") to allocate as much VRAM on my 1080ti as allowed, which was just over 9 GB of the 11 GB. And you can see in the Task Manager/Details tab that the CUDA process (called "MemAvail.exe") is using about 9 GB (the number shown is kbytes, not GB, so you have to divide by 1024^2).
So CUDA tells me I can access 9.098 GB (which is 82.7% of installed VRAM), so I allocate just under that much on the GPU, and what's left to that process is 137 MB. And the total VRAM usage across all processes at that point is shown in the below image from Task Manager, and the answer is around 9.5 GB.
Next I start up DAZ Studio with an empty scene and Iray preview ON (with my CUDA app still taking over 9 GB of VRAM), and as you can see in the below image it takes a little over 2 GB. So between my CUDA app and Studio it's taking over 11 GB, on a GPU with only 11 GB installed. How is that possible?
Well take a look at the "Shared GPU Memory" for my MemAvail CUDA app. Note that since I started Studio, the Shared memory used by my VRAM-grabbing app is now increased from 54 MB to almost 840 MB. Which means that Windows "paged" some of my "VRAM-grabbing" memory usage out to system RAM so that Studio could make use of what it requested, since it is now the active application.
And the result is the image above, where over 10.7 GB of the 11 GB is being used across all processes, and some VRAM used by my VRAM-grabbing CUDA app was "paged" out to system RAM to make way for Studio's request for VRAM.
So actually the processes using GPU VRAM are accessing MORE than the installed 11 GB on the 1080ti, although some of that (less than 1 GB) is now located in the slower system RAM.
Just so I understand, you are running TWO instances of Studio in order to access all of the available GPU ram on your 1080ti..???, one instance of approx 9gb and one instance of approx 2bg.?
No. Like I said I wrote a CUDA app called "MemAvail.exe" that is grabbing/allocating about 9 GB of the GPU VRAM, and at the same time I'm running an empty, 2+ GB scene in Studio.
Ok.,
but your memAvail.exe app is only able to call/have access to 83% of the available GPU memory., as a single instance/program, or could it request more. ??
swordkensia please read my posts above where I explain all of this as clearly as I can. Thanks.
I'm sorry it was a simple question, either your App can access more than 9 gigs(the 83%), as single call/request or it can't. If it cannot then how does this help if you have a scene that requires access to more than the 83% single instance cap.???
What you seem to have proven is that the 'restricted' memory, the remaining 2 gigs in this instance, IS accessable/usable, but by another program, which could be running in parallel with studio.
So YOU CAN utilize ALL of your GPU's memory, and indeed even a certain amount of paged memory, just not all of it within a single application.
Once again I apologies if I am coming across as obtuse, just seeking to understand.
You're correct. However there's a very important distinction here: Blocking VRAM so nobody can access it is a big deal, however allowing a separate process to access that VRAM is fairly minor in software terms.
It's a lot like the discussion of VRAM stacking. Iray can access almost all of the remaining VRAM if it can perform the simple task of starting another process and having a portion of the render done in that separate process. Just like those who believe that developers can write code to stack VRAM across SLI/NVLink-connected RTX GPU's when there's a slow SLI link in the way, writing a second process to access VRAM on the same GPU is presumably a simple task with no performance hit. As long as they can pull out part of the rendering process as a new system process, that is.
And the point of my CUDA experiment was to show how simple it is to write a separate process that can access the remaining VRAM. In fact, all you need is a few lines of code to allocate VRAM to your app/process.
Now if for some reason it's not possible for Iray to pull out a portion of the render task to effectively "stack VRAM" on the same GPU with a different process, then yeah, the 81% limit on VRAM allocation for a single process should (and may be) changed. However, keep in mind the purpose of the limit is to provide high speed VRAM for other processes you might want to run simultaneously. And if you've ever dealt with VRAM paged to system RAM, it's something you might very much appreciate. But personally, I'm hoping the NVIDIA/Microsoft discussions result in a user-configurable setting for VRAM limits.
BTW, if you want to see how a single app can launch MANY processes, just look at your Task Manager under Details, and press "Name" at the top of the colum to sort by process name. In my case, Chrome alone has something like 50 processes it generated, all grabbing some piece of system RAM.
...not all of us here write code though.