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
AS far as GPU-Z, I believe it's a 32 bit application. And I recall reading some concerns over 32 bit applications reporting memory values from a 64-bit OS, and maybe they're incorrect (which seems reasonable). That was just one of the responses I saw regarding this issue of W10 hogging VRAM, and that the concern might be rooted, at least partially, in incorrect reporting by 32 bit apps. Just another reason I tend to believe the new W10 performance manager GPU reporting.
updated:
- to provide the current result of the log file created at start of DAZ Studio with an empty scene.
- rephrased some sentences
@ ebergerly
Can you please share a screenshot of your DAZ Studio log file that shows the following lines for your system:
- - -
"2018-06-05 17:16:12.014 Iray INFO - module:category(IRAY:RENDER): 1.1 IRAY rend info : Your NVIDIA driver supports CUDA version up to 9.2; iray requires CUDA version 8.0; all is good.
2018-06-05 17:16:12.030 Iray INFO - module:category(IRAY:RENDER): 1.1 IRAY rend info : Using iray plugin version 4.6-beta, build 287000.7672 n, 23 May 2017, nt-x86-64-vc11.
2018-06-05 17:16:12.159 Iray INFO - module:category(IRAY:RENDER): 1.1 IRAY rend info : CUDA device 0 (GeForce GTX 1080 Ti): compute capability 6.1, 11 GiB total, 9.14774 GiB available
2018-06-05 17:16:12.296 Iray INFO - module:category(IRAY:RENDER): 1.1 IRAY rend info : CUDA device 2 (GeForce GTX 1080): compute capability 6.1, 8 GiB total, 6.64077 GiB available, display attached
2018-06-05 17:16:12.436 Iray INFO - module:category(IRAY:RENDER): 1.1 IRAY rend info : CUDA device 1 (GeForce GTX 1080 Ti): compute capability 6.1, 11 GiB total, 9.14924 GiB available
- - -
Just to be clear:
At the startup of DAZ Studio it is checked which GPU devices are installed and how much VRAM is available.
The result of this check is then written into the log file as showed in the screenshot.
This means this data is gathered from an empty (!) scene.
- - -
Even after reading trough all the blog entries I honestly do not know how exactly GPU-Z and the Windows Task manager calculate their VRAM utilization data.
My impression is that GPU-Z and the windows task manager may give some indication how much VRAM is used for general purposes but are not providing the detailed and accurate data that is needed to manage the VRAM of a render engine.
On the other hand both Nvidia and Otoy employ provide specialised tools and log files that gather the relevant data for CUDA applications like Iray and Octane.
Therefore the data that should matter for DAZ Studio users is the available, total and "memory used" VRAM numbers indicated in the DAZ Studio log file.
- - -
There is of course a chance that the numbers indicated by the DAZ Studio log files and OctaneRender tools specifically created for CUDA applications are both wrong at the same time.
But without anyone showing me specific proof I will seriously doubt that.
I really believe that both Nvidia and Otoy employees know how to properly gather the available VRAM data that is actually available to use with Iray or OctaneRender.
- - -
@ anyone
Can you please share some screenshots of your DAZ Studio log files as shown in the example above?
That way it would be possible to get a better understanding how the data looks on other systems.
- - -
This post is linked to support ticket #273017
2018 - 06 - 11: updated this entry to provide links to posts about
- VRAM numbers of the same scene in OctaneRender standalone
- DAZ Studio log entries about VRAM assinged as "work space"
- - -
How the Windows task manager may be calculating VRAM stats
- Open DAZ Studio
- Open Windows Task manager
- In DAZ Studio add a simple cube with one division = 8 vertices to the scene.
- Activate the Nvidia Iray live preview
Now watch the used VRAM jump up to around 2.3 GB in the windows task manager
- - -
So what happend here?
Edited 2018 06 11
Another look at the DAZ Studio Iray log seems to indicate that 1.65624 GiB is allocated as "workspace"
2018-06-10 16:22:39.035 Iray INFO - module:category(IRAY:RENDER): 1.9 IRAY rend info : CUDA device 1 (GeForce GTX 1080 Ti): Allocated 1.65625 GiB of work space (2048k active samples in 0.061s)
compare later post:
https://www.daz3d.com/forums/discussion/comment/3699976/#Comment_3699976
- - -
Looking at the windows task manager results of the scene in OctaneRender shows less VRAM as used.
https://www.daz3d.com/forums/discussion/comment/3688546/#Comment_3688546
In OctaneRender standalone only 0.5 GB is used for the same 8 vertices cube sceen.
- - -
-> Based on that it seems more likely that the jump to 2.3 GB of VRAM shown as being used in the windows task manger is caused by the VRAM allocated as work space.
I leave the following rest of the post unchanged so people can still follow how we got to that part of the discussion:.
Original impressions:
My impression is that the number of "reserved" or "not available" VRAM that is not used by windows 10 is just added to the actually used VRAM data whenever a Cuda application is started.
In the windows task manager you then see the sum of those numbers.
- - -
On my system the explanation of how I got to 2.3 GB of 11 GB VRAM used by a simple 8 vertices cube seems to be:
11 GiB total, 9.14774 GiB available (as shown in the DAZ Studio log file)
11 - 9 = 1.85226 -> This is the "blocked" or "reserved" amount of VRAM that is not available to use with CUDA applications on windows 10 for a GTX 1080 Ti.
2.3 - 1.85226 = 0.44774 -> This is the amount of VRAM that is needed to manage all the open Cuda applications like Nvidia Iray.
- - -
Or does anyone else have a solid idea why 8 vertices would need 2.3 GB of VRAM with DAZ Studio Iray open?
- - -
I submitted this latest findings as
Request #273017
- - -
Have you tried adding another object after the initial cube? My contention has been that there is no direct relationship which is why I started this thread. I noticed that a scene with only two figures was hogging a surprisingly large amount of VRAM but I also noticed that adding another figure didn't increase that VRAM count as expected. So instead of being restricted to two fully clotherd figures as well as the room and props, I ended up with four and still didn't fall back to CPU.
With just the 8 vertices cube 2.3 GB of VRAM are indicated as used in the Windows task manager.
When adding a Genesis 8 female figure the active vertice count raises to 67'434 from which are 17'028 in base resolution.
In the Windows task manager now 2.5 GB of VRAM are showing as utilized.
- - -
This means a 0.2 GB of VRAM increase which seems reasonable.
What seems puzzling is the 2.3 GB that are created at start by just adding a 8 vertices cube.
- - -
retested 2018 06 11
compare later post about Allocated 1.65625 GiB of work space
https://www.daz3d.com/forums/discussion/comment/3699976/#Comment_3699976
It seems just adding one more Genesis 8 female figure does not change the VRAM size assigned to the work space.
- - -
For those interested to figure this out I suggest to also use the OctaneRender standalone version with the same scenes.
Then compare the numbers of used VRAM
- of the OctaneRender standalone VRAM statistics
- of the DAZ Studio Iray log file
- of the Windows Task Manager
- - -
Thanks for the clarification, linvanchene. I was wondering why I didn't see that "available" data in the log file during rendering. I'll have to check it with an empty scene.
Which makes me wonder, BTW, why it doesn't appear when Studio starts a render with an actual scene where it has all the ACTUAL scene data loaded into VRAM...
In any case, it sounds like it comes down to what we choose to believe, without a definitive answer available at this point. I guess my position is "heck, I don't know, but the info I have seen tends to lean me (slightly) in the direction of it not being a real issue". And the reason is this:
If, according to the new Windows 10 task manager, I can load up my two GPU's within 1 GB of their limit (maybe more if I do some more tests), and the scheduling task software (VidMm, which tells me that info and actually controls and schedules the GPU), was developed by Microsoft, who also developed the task manager, it seems to me to be more believeable than some 3rd party developers who presumably don't know the internals of how Windows 10 and VidMm operates, and apparently expressed their concerns a few years ago (?). Maybe something has changed in the last few years with recent releases that perhaps made this issue (if it was one) go away? Have Otoy or NVIDIA posted anything recently that confirms "yeah, we talked to MS and they said there's a bug or something in VidMm"?.
But again, that's just my sense at this point, and I may be wrong.
Regarding your question about why would the task manager show 2GB of dedicated GPU VRAM usage for just a single cube in a scene...
I don't know, but from a software developer perspective, there are some legitimate reasons. When you prepare for calculating something like a big Iray scene (or any other large calculations) you first initialize everything, and form matrices and grab ("allocate") storage locations in memory that you think you'll need for your storage and calculations. Doesn't mean you'll use it all (or maybe you'll use more), but it's ready if you need it. Perhaps that's what Studio/Iray is doing, just assuming it will need a block of GPU storage space for the initial calculations in a "standard" scene, or as a place to store the scene data prior to calculations, and grabs a chunk of VRAM for its own use in preparation. Not out of greed like it's believed that W10 is doing, but out of necessity to make sure the GPU is ready to accept the scene data without delay, and with adequate size. So when/if you add characters, etc., to the scene as most people are expected to do, it's all ready for you. And so users don't complain "hey, why does it take so long for my scene to load when I have a super expensive and super fast GPU just sitting there?" :)
Maybe that explains marble's observations of a beginning chunk of VRAM being grabbed, and it doesn't change as more is added to the scene.
Again, I don't know the answer, just saying that looks can be deceiving, and maybe what looks obvious is something else.
Later I'll check my log file as you request, but honestly if it says the same thing as you posted it doesn't (for me) answer anything. There are a lot of reasons why it might say that at startup, but change as you add real data and real big scenes. Or it's possible that "available" doesn't mean what you might think it means. Which seems reasonably likely, since it appears that I can load my 1070 and 1080ti up to within 1GB of their limit (if you believe Task Manager). So it comes down to whether the log file "available" data is correct, or the Task Manager "dedicated" is correct, or maybe both are correct (with different meanings), or maybe neither is telling us what we think it is.
And maybe "available" at startup isn't the actual "available" when you load a serious scene. Just because memory doesn't appear to be "available" at one time doesn't mean it can't be released for use later on upon request. In the software world, grabbing and releasing memory is standard practice in just about every software app.
Heck, I don't know what the real answer is. I just want to be careful and not jump to conclusions without all the data.
FWIW, I checked my log file after opening D|S, and here's what it says:
2018-06-05 16:28:37.774 Iray INFO - module:category(IRAY:RENDER): 1.1 IRAY rend info : CUDA device 0 (GeForce GTX 1080 Ti): compute capability 6.1, 11 GiB total, 9.14774 GiB available
2018-06-05 16:28:37.924 Iray INFO - module:category(IRAY:RENDER): 1.1 IRAY rend info : CUDA device 1 (GeForce GTX 1070): compute capability 6.1, 8 GiB total, 6.66179 GiB available, display attached
Which tells me that at 4:28pm, after starting D|S with an empty scene, Iray reports my 1080ti has 9.1 of 11GB "available" (whatever that means), and the GTX 1070 has 6.7 of 8 GB "available".
Maybe when I load a bigger scene at 4:36 pm, Iray can request VidMm to give it more and it will. Who knows?
Thank you for checking.
It seems at least on your system similar numbers are indicated.
This helps as an indication that there is nothing "wrong" or special about my system in a way that I would see completly different numbers as everyone else.
But yes, we may interpret the same numbers differently based on other information we have available and how much we trust a 3rd party source.
- - -
I made some further tests how much VRAM the cube test scene uses in OctaneRender standalone.
In OctaneRender below the viewport you can see the numbers:
312 / 9161 / 11264 MB
In the preferences this data is explained more detailed as
- Engine Runtime data 302 MB
- Geometry 1.5 KB
- Film Buff 10 MB
- Unavailabe 2.1 GB
- - -
It seems that the 312 MB is the actually used amount of VRAM as sum of Geometry (1.5 KB), Film Buff (10 MB) and the Engine Runtime Data 302 MB.
The total number of VRAM of a GTX 1080 Ti is indicated as 11264. This is similar to the 11 GiB total indicated in the DAZ Studio log file Iray.
9161 is indicated as available for use in OctaneRender standalone . This is pretty similar to the 9.14774 GiB available indicated in the DAZ Studio log file Iray.
OctaneRender indicates that 2.1 GB is unavailable. In Iray it is indicated that 1.85226 is not available. (11 - 9.14774 )
I agree that some official clarification what the log entry
11 GiB total, 9.14774 GiB available
actually measures would be very welcome at this point.
- - -
What is completly different is the amount of VRAM used indicated in the Windows Task Manager.
With OcaneRender running the cube scene the dedicated GPU memory shows 0.5 GB as being used.
In DAZ Studio Iray 2.3 GB were shown as being used.
This difference now seems very odd.
Why would DAZ Studio Iray need 1.8 GB of VRAM more to run a simple scene with a 1.5 KB 8 vertices cube?
- - -
This leads again to the question
Why does DAZ Studio Iray need 2.3 GB of VRAM to run a scene with a 8 vertices cube that only has geometry of 1.5 KB?
I updated Request #273017.
For me it is impossible to judge if there is a different issue going on here that has nothing to do at all with the differences indicated of the total and available VRAM in the DAZ Studio log file.
Maybe the developers can explain this so we do not have to speculate further.
- - -
DAZ3D staff has forwarded the questions to developers on friday.
It seems that what you are describing is a part of what is going on.
Additional Log file details for the 8 vertices cube test scene:
2018-06-10 16:22:38.571 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Initializing local rendering.
2018-06-10 16:22:38.641 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Rendering with 2 device(s):
2018-06-10 16:22:38.641 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : CUDA device 0 (GeForce GTX 1080 Ti)
2018-06-10 16:22:38.641 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : CUDA device 1 (GeForce GTX 1080 Ti)
2018-06-10 16:22:38.641 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Rendering...
2018-06-10 16:22:38.647 Iray INFO - module:category(IRAY:RENDER): 1.5 IRAY rend info : Initializing light hierarchy.
2018-06-10 16:22:38.650 Iray INFO - module:category(IRAY:RENDER): 1.5 IRAY rend info : Light hierarchy initialization took 0.00s
2018-06-10 16:22:38.894 Iray INFO - module:category(IRAY:RENDER): 1.2 IRAY rend info : CUDA device 0 (GeForce GTX 1080 Ti): Scene processed in 0.252s
2018-06-10 16:22:38.896 Iray INFO - module:category(IRAY:RENDER): 1.5 IRAY rend info : CUDA device 0 (GeForce GTX 1080 Ti): Allocated 2.05682 MiB for frame buffer
2018-06-10 16:22:38.900 Iray INFO - module:category(IRAY:RENDER): 1.9 IRAY rend info : CUDA device 1 (GeForce GTX 1080 Ti): Scene processed in 0.258s
2018-06-10 16:22:38.905 Iray INFO - module:category(IRAY:RENDER): 1.13 IRAY rend info : CUDA device 1 (GeForce GTX 1080 Ti): Allocated 2.05684 MiB for frame buffer
2018-06-10 16:22:38.959 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Received update to 00001 iterations after 0.313s.
2018-06-10 16:22:38.964 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Rendering...
2018-06-10 16:22:38.975 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Received update to 00002 iterations after 0.325s.
2018-06-10 16:22:39.035 Iray INFO - module:category(IRAY:RENDER): 1.9 IRAY rend info : CUDA device 1 (GeForce GTX 1080 Ti): Allocated 1.65625 GiB of work space (2048k active samples in 0.061s)
2018-06-10 16:22:39.036 Iray INFO - module:category(IRAY:RENDER): 1.2 IRAY rend info : CUDA device 0 (GeForce GTX 1080 Ti): Allocated 1.65625 GiB of work space (2048k active samples in 0.062s)
2018-06-10 16:22:39.050 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Received update to 00004 iterations after 0.399s.
2018-06-10 16:22:39.064 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Received update to 00008 iterations after 0.413s.
2018-06-10 16:22:39.079 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Received update to 00013 iterations after 0.429s.
2018-06-10 16:22:39.094 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Received update to 00018 iterations after 0.444s.
2018-06-10 16:22:39.098 Iray VERBOSE - module:category(IRAY:RENDER): 1.9 IRAY rend progr: CUDA device 1 (GeForce GTX 1080 Ti): Processing scene...
2018-06-10 16:22:39.098 Iray VERBOSE - module:category(IRAY:RENDER): 1.2 IRAY rend progr: CUDA device 0 (GeForce GTX 1080 Ti): Processing scene...
2018-06-10 16:22:39.098 Iray VERBOSE - module:category(IRAY:RENDER): 1.5 IRAY rend stat : Geometry memory consumption: 1.44531 KiB (device 0), 0 B (host)
2018-06-10 16:22:39.099 Iray VERBOSE - module:category(IRAY:RENDER): 1.13 IRAY rend stat : Geometry memory consumption: 1.44531 KiB (device 1), 0 B (host)
2018-06-10 16:22:39.099 Iray VERBOSE - module:category(IRAY:RENDER): 1.5 IRAY rend stat : Texture memory consumption: 1024 B (device 0)
2018-06-10 16:22:39.099 Iray VERBOSE - module:category(IRAY:RENDER): 1.13 IRAY rend stat : Texture memory consumption: 1024 B (device 1)
2018-06-10 16:22:39.099 Iray VERBOSE - module:category(IRAY:RENDER): 1.5 IRAY rend stat : Lights memory consumption: 948 B (device 0)
2018-06-10 16:22:39.100 Iray VERBOSE - module:category(IRAY:RENDER): 1.13 IRAY rend stat : Lights memory consumption: 948 B (device 1)
2018-06-10 16:22:39.100 Iray VERBOSE - module:category(IRAY:RENDER): 1.5 IRAY rend stat : Material measurement memory consumption: 0 B (GPU)
2018-06-10 16:22:39.100 Iray VERBOSE - module:category(IRAY:RENDER): 1.5 IRAY rend stat : Materials memory consumption: 16.5156 KiB (GPU)
2018-06-10 16:22:39.110 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Received update to 00023 iterations after 0.460s.
- - -
Note that this log entry is created when the scene starts rendering.
VRAM used for workspace
The relevant part for the current questions seems to be the line:
2018-06-10 16:22:39.035 Iray INFO - module:category(IRAY:RENDER): 1.9 IRAY rend info : CUDA device 1 (GeForce GTX 1080 Ti): Allocated 1.65625 GiB of work space (2048k active samples in 0.061s)
To get a better understanding how VRAM is allocated to the workspace it would now be necessary to check how this parameter changes on different systems when adding geometry to the scene.
-> check with laptop, cards with different total VRAM space, small scenes, large scenes etc.
- - -
Side note:
When I learned to work with GPU render engines in 2013 I had to do it with a 2 GB VRAM card.
At this time render engines used around 400 MB to run the software of the "engine" and the "frame buffer" etc.
This means people had around 1.6 GB of VRAM for geometry and textures to create their scenes.
It was necessary to learn
- how to use detailed textures and geometry on objects in the foreground.
- how to save memory on objects in the background by using lower resolution geometry and texture versions
- render out different areas of an image seperately and composite in photoshop
Today with 11 GB cards some users who create scenes with detailed geometry still struggle with available VRAM space.
We are supposed to be the GPU rendering specialists at the office.
When superiors and partners are asking why a scene is not fitting the VRAM we should be in the position to explain them what exactly is going on in order to find practical solutions how to render the project.
For that very reason it is crucial that Iray developers provide detailed information how exactly Iray is using the VRAM and for what reasons.
- Tracking the Iray log file for relevant entries and their changes over time takes a lot of time and is unpractical.
-> accurate additional tools that display this data in a conveniant graphical way in the user interface would help a lot
- official explanations what this data actually means would be very much appreciated
- - -
Open Questions
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?
FWIW, I noticed an article on the tech website "ExtremeTech" from last year, prior to the W10 Fall update being released. They asked Microsoft what the new GPU reporting functions would do. They also noted a difference in GPU VRAM reporting between "requested" and actually "utilized" VRAM reporting, saying that W10 now shows actually utilized VRAM, not just requested (like GPU-Z apparently). Here’s what Microsoft had to say, direct from the horse's mouth as they say:
"...we questioned whether the GPU would report total memory requested (which is what tools like GPU-Z do) or actually report total memory utilized. Here's what MIcrosoft had to say:
BTW, it seems that GPU-Z now shows the same dedicated/utilized GPU VRAM values that W10 shows for my 1080ti, but not my 1070. Maybe that was due to a recent update.
In any case, clearly there are differences/confusion regarding what the different reporting apps are actually reporting. And maybe that's the case with the Iray log numbers? But if we can believe the MS statements above, and my Task Manager results after loading up my system with some monster scenes, then both GPU's can use up to 1 to 1.5GB below their installed capacity, not 2-3 below like some have reported.
Another thing I've noticed...
I've found it very difficult to get to the point where my system drops from GPU rendering to CPU, due to overload of the VRAM. It seems I need to get a scene that takes 30+ GB of my system RAM before the VRAM runs out. And I have 64GB system RAM, so I'm wondering how others with significantly less RAM can get to that point. Maybe something else is causing them to drop to CPU rendering?
Some more food for thought, for what it’s worth…
I was trying to think of how a VRAM manager/scheduler software like the W10 “VidMm” should operate, to better understand how it does operate. And it occurred to me, if I were to make a memory scheduler, I’d have to keep some of the following in mind:
Now I’m certainly not sure that’s how things actually work with VidMm, but at least it seems like a reasonable possibility. And also a reason not to jump to conclusions and assume that W10 is being unnecessarily greedy in VRAM allocation.
Just throwing my two cents here.
I often work with scenes that are pretty demanding on my 1080 Ti both in geoemetry and (especialyl) textures. One thing I've noticed is that OptiX acceleration often plays a role in whether I can render a heavy scene or not. For some reason when a scene kicks back on the CPU, I can go and turn off OptiX, and it will render on the GPU in the end (even if it's a tad bit slower).
I don't think Iray assigns VRAM to the workspace (question #1). I think W10's "VidMm" and "VidSch" do. They are the controller and scheduler of GPU VRAM. I think Iray is just a user and it makes requests to VidMm/VidSch. Or something like that.
Here's the blog entry from the Microsoft engineer that explains it:
https://blogs.msdn.microsoft.com/directx/2017/07/21/gpus-in-the-task-manager/
And in Question 2b, I don't think it's reasonable to expect that there will be the entire installed VRAM available to all apps, independent of whether there is a display attached, for the reasons I've already mentioned. Although that depends on the logic VidMm uses to do its scheduling, and what "available" actually means. Does it mean "available now and forevermore to any app who asks first", or "available now, but that can change in the future if you ask for it", or "It's what we will assign to any particular app at this moment, but that's what's available across all apps might be different because it's not fair for one app to own the entire VRAM", or something else?
And I even question whether the Iray log entry is reflecting a correct and meaningful value, since maybe when it was developed the correct information wasn't available from W10. And maybe it's still using outdated numbers and not taking advantage of the VidMm and VidSch actual numbers. Maybe a new Iray version uses more accurate numbers?
Interesting...
I did some tests after modifying the pagefile size on my machine and was successful in utilizing the VRAM on my GPU's up to less than 1GB below their capacity. My 1080ti used 10.1 GB of its 11.0 GB installed capacity (per W10 Task Manager).
I had read in a couple of places that a properly configured pagefile would help to utilize more of your GPU's VRAM, but dismissed it as being irrelevant because I couldn't see any connection. But then I went in and configured a custom pagefile size (min = 16GB, max = 32GB) rather than the default of allowing W10 to manage it at around 9GB. I have no clue if the values I set are appropriate or even reasonable, since my system RAM is 64GB, and they say you can set it at 1.5x that for min, and 3x that for max pagefile sizes. But that seemed like a lot of pagefile size, so I cranked it down a lot.
Anyway, compared to the W10 managed pagefile, my GPU VRAM utilization went from 1.0 to 1.5 GB below installed capacity, to only 0.9 GB below installed. Maybe if I crank it up even more it will knock that down (based on the Task Manager numbers, after I loaded 40+GB of scene into my RAM).
So I'm starting to think that maybe installed system RAM and pagefile/storage size might also affect this issue and how much W10 takes from your GPU VRAM. Though I have no clue why. Maybe something about W10 not allowing an app to use too much VRAM if there's insufficient RAM or pagefile to back it up or something? Who knows?
This stuff is complicated. Which is why I caution folks not to jump to conclusions.
So are you suggesting that IRay is capable of offloading some content (probably textures, if anything) to system RAM? I know that Octane supports that (out-of-core I believe is the term) but I've never heard of it happening with IRay.
https://www.mediaworkstations.net/2017/06/22/otoys-octanerender-fastest-render-engine-gpu-rendering/
Nothing to do with the paging file(as far as I know). I have 32 GB and a 1080Ti and can get to an utilization of 10.6 - 10.8 GB. Everything above 10 GB is a bit random. Sometimes it works, sometimes it doesn't. My guess is that other processes might also require some (small) chunk of VRAM which makes it a bit iffy if a scene will fit.
Like I said, I'm not convinced this pagefile thing is relevant, but I am open minded enough to allow that there might be a connection that I'd never considered rather than just dismiss it. Dismissing stuff is easy, but actually proving it should be dismissed takes some thought and some work. And I'm also cautioning those who might view this "VRAM grabbing" issue as nothing more than "the Iray log says only XX GB available, so it's time for legal action against Microsoft" to consider some possible alternatives to explain what they're seeing. I'm convinced these VRAM interactions are very complex.
And the thing that seems at least worthy of discussion in this case is that the function of a pagefile is if your system runs low on system RAM, it offloads some to your hard drive in the pagefile file so it acts like "virtual" RAM. So if Windows does that management role for system RAM, would VidMm/VidSch also do something like that for GPU VRAM? I don't know, but it seems like a reasonable possibility at least.
Or, as I initially thought, it could be irrelevant....
I'm thinking that what's in VRAM is a compressed extract of what was loaded into system RAM (the D|S scene in our case), and it's converted into Iray calculations, so it's different than what's in system RAM. In my case, system RAM loaded over 40GB of a monster scene, but in VRAM it's less than 20GB total across both GPU's. And if you want to offload that compressed VRAM data in case the VRAM runs low, where do you put it? Maybe in the pagefile? I don't know, but perhaps if my pagefile isn't large enough to support the needs of my combined VRAM from my 1070 and 1080ti (8GB plus 11GB, total of 19GB) then it won't allow an app to grab more than the 9GB that Windows 10 assigned to my pagefile. Or something like that.
Now all of that might be nonsense, but at least it's food for thought. And I'm also wondering if there's a connection between the amount of VRAM an app will be allocated by W10 VidMm/VidSch and the total system RAM installed on the machine. Kind of like how you need to get a bigger power supply when you buy a GPU, and a new motherboard with a good PCIe bus, maybe you might need more system RAM to support the VRAM? Again, that could be nonsense, but with 64GB of system RAM I can utilize up to 0.9GB below the installed GPU VRAM capacity of 11GB. Sounds like schouwenberg is in a similar situation, with a lot of system RAM (32GB), and high GPU VRAM utilization.
- updated my previous posts to make it hopefully more clear what is after new tests allready "outdated or possibly wrong speculation" on my part and what is information or data provided by 3rd parties.
- read all the other posts as well but refraining from commenting on some details in order not to create even further confusion.
- waiting for a clarifcation or explanation by DAZ3D staff what the information in the DAZ Studio log file about GiB total / available and work space means.
- - -
Just some links about terms that got mentioned but may not be well known to everyone:
Page File
"A page file (also known as a "paging file") is an optional, hidden system file on a hard disk. The page file can be used to "back" (or support) system crash dumps and extend how much system-committed memory (also known as “virtual memory”) a system can back. It also enables the system to remove infrequently accessed modified pages from physical memory to let the system use physical memory more efficiently for more frequently accessed pages."
Source:
https://support.microsoft.com/en-us/help/2860880/how-to-determine-the-appropriate-page-file-size-for-64-bit-versions-of
alternatively:
https://www.howtogeek.com/126430/htg-explains-what-is-the-windows-page-file-and-should-you-disable-it/:
I am not aware of any way to use textures or geometry out-of-core OOC with Iray.
Out-of-core textures
The ability to move textures from the VRAM of your GPU to the system RAM was introduced for OctaneRender 2 in April 2015.
Out-of-core geometry
The ability to also move geometry from the VRAM of your GPU to the system RAM was announced as a feature for OctaneRender 4 in March 2018. Development builds are available to download for testing purposes on the Otoy forum for users with a regular or a subscription license.
- - -
BTW, I forgot to post the screenshot of my system when I've merged a bunch of scenes and it fills my system RAM to over 40GB when I start rendering, then fills my GPUs' VRAM to 10.1 GB out of 11.0 GB. I believe this was when it was preparing to start rendering, and then the VRAM got overloaded and it ended up rendering on CPU. I've found that on my system, the breaking point seems to be around 30+ GB of scene filling system RAM before it drops to CPU rendering. And FWIW, I had set a custom pagefile of 16/32GB on my 64GB system.
If you believe these numbers actually reflect the GPU VRAM usage, then all but 8% of the 11GB are being used by IRAY/Studio. Seems pretty reasonable (and low overhead) to me.
It sounds like JD_Mortal was contending that W10 isn't actually managing the VRAM, and instead Iray does (if I understand his posts correctly). But that seems in direct contradiction to the MS engineers' explanations of VidMm and VidSch doing the VRAM scheduling. It would be great if he could post some backup data from Microsoft or other trusted resource to explain what's happening.
I'm slowly trying to chip away at this issue in hopes that at some point it can be resolved.
So I decided to remove Iray and Studio from the equation and try to deal with the GPU directly, which means writing some CUDA code. There's a simple function in CUDA called "cudaMemGetInfo", which returns the "total" and "free" bytes of memory in the GPU, and if you take the difference you can get the "used" bytes. So I pretty much copied a piece of NVIDIA sample code to use this function, and tweaked it a bit to have it report on both my GPU's.
And the results so far are interesting...
For both GPU's (GTX-1080ti and GTX-1070), the "free" bytes of memory on the GPU, reported by "cudaMemGetInfo" when my system has no significant apps running, are almost identical to the "available" GPU VRAM numbers from the Iray log after starting up Studio with a blank scene:
cudaMemGetInfo: 9.09 GB free on the 1080ti, and 6.63 GB free on the 1070
Iray log: 9.15 GB available on the 1080ti, and 6.66 available on the 1070
So it seems reasonable to assume that the Iray log is getting its numbers from "cudaMemGetInfo".
So one of the concerns about the Iray log was that it only reports on available VRAM BEFORE you load or render a scene, because "available" doesn't necessarily mean "I can't get it even if I request it". Maybe once the scene loads and starts rendering a request is made by Iray to grab more memory.
So I ran my "cudaMemGetInfo" application while a huge scene (30GB of system RAM) was rendering to see how much was used and free. The results are:
1080ti:
1070:
These numbers seem to agree with the Task Manager "dedicated GPU VRAM" numbers that I get for the same scene, but interestingly they are not exactly the same. I usually get around 10GB and 7GB, respectively, being used, and these show a bit higher utilization. Screenshots of both are attached.
Now, as I've said before this stuff is extremely complicated. A GPU has a bunch of different "memory" types on the board, and some are even in the GPU chip itself. When you run thousands of threads simultaneously you need onboard memory to handle interactions between threads (local memory and others), as well as the global memory chips on the board.
And you need memory for the CUDA driver, and local memory for the GPU to reference in its calculations (heap memory, stack memory, etc, etc.). So it's very complicated, and the question becomes: "How much memory is Windows 10 REALLY using, and how much is being used by all the stuff needed by the GPU to do all those calculations?"
But these results seem to imply that the GPU's are only being blocked from using less than 1GB of VRAM, as the Task Manager numbers say, not the 2-3GB the Iray log and others seem to imply and believe. And they also imply that things change significantly VRAM-wise before the scene is loaded and while it's rendering, so that perhaps the Iray log pre-scene-loading numbers are accurate at the time, but ultimately somewhat irrelevant in determining how much VRAM can ACTUALLY be used by Iray/Studio/whatever.
I guess the next step is to see if I can allocate, via CUDA, a fixed amount of VRAM (say, 11GB on the 1080ti) and see what happens...
Well, as I suspected, the deeper I get into this the more complicated it becomes. Apparently a few years ago, with the introduction of CUDA 6 and the Pascal GPU architecture, there's a new concept in memory management called "Unified Memory". As shown in the NVIDIA blog post below, it seems to allow you to go beyond the limits of installed GPU VRAM and access a "unified" memory. And the CUDA function that folks were using to allocate memory ("cudaMalloc") was replaced by "cudaMallocManaged".
As it says in the link: "With the legacy GPU programming model there is no easy way to “just run” your application when you’re oversubscribing GPU memory. Even if your dataset is only slightly larger than the available capacity, you would still need to manage the active working set in GPU memory. Unified Memory is a much more intelligent memory management system that simplifies GPU development by providing a single memory space directly accessible by all GPUs and CPUs in the system, with automatic page migration for data locality. "
Now, I'm not sure that the observations of Windows 10 hogging VRAM were due to users not using the new Unified Memory, or not using it correctly, but it seems like the rules for memory management changed a few years ago. And maybe what the Iray log is showing is the old way, and doesn't reflect this new memory management. In any case, the plot thickens and finding a real answer might be difficult.
Anyway, here's the link to the NVIDIA blog from about a year and a half ago:
https://devblogs.nvidia.com/beyond-gpu-memory-limits-unified-memory-pascal/
For what it's worth, I think this issue has been pretty much resolved. And I think the conclusion is that Windows 10 doesn't hog GPU VRAM, but instead it makes sure that individual processes don't hog VRAM. You can easily prove that to yourself by firing up a bunch of apps that use some of your GPU's VRAM, and together you can utilize almost all of the VRAM. My 11GB 1080ti can easily have 10.8 GB of that utilized by a bunch of processes/applications. And that's pretty much what Microsoft has said. Even though reports of "free" or "available" VRAM might show a limit, the limit is only imposed on an individual app so it doesn't use the entire VRAM.
So for example, an app might ask for the available VRAM at the moment, and Windows will respond. And let's say that on an 11GB 1080ti the response comes back "9 GB available". That doesn't mean that Windows has locked off 2 GB and made it unavailable to everyone, it means that the requesting app/process can only use 9GB for that particular process. But if the same software initiates another process, it can access the remainder of the available VRAM. Or a different app/process can request the remaining 2 GB and grab it.
A further complication is CUDA, which has, as I mentioned, something called Universal Memory, in which all GPU and system RAM is treated like a single chunk of memory. So with CUDA there's other stuff going on where it can move memory in and out (over the PCIe) bus, in what's also called "shared" memory, so that more memory (albeit much slower) can be accessed. And you can watch that in Task Manager's Details tab, where you can configure it to watch the GPU VRAM usage of each individual process. And as new processes/apps start up and grab VRAM, existing processes might have some of their GPU VRAM moved into shared/universal memory so the active app can have it. And I think there's some other "under the hood" stuff that CUDA can do to access additional VRAM directly.
Which raises another issue...I'm kind of excited in the hopes that a new PCIe generation will vastly improve transfers from GPU to system RAM so that GPU VRAM will have a reasonably high speed backup in case you run out of VRAM and want to take advantage of system RAM. Kind of like the idea behind NVLINK, though apparently the only reasonable NVLINK for consumers will be between GPU's equipped with it, which are pretty few and expensive, with no real CPU's and motherboards that support it for CPU/RAM usage.
So anyway, pretty much the entire VRAM of your GPU is available (aside from a small amount of system-required memory for stuff like Desktop Window Manager, etc., to run the monitors, which from what I've seen usually takes only around 0.2 - 0.5GB) for ALL processes, although an individual process isn't allowed to hog it all. So then it is up to the application to figure how to access more VRAM by initiating additional processes (if possible).
Attached is a screenshot of my Task Manager reporting on my 1080ti's VRAM usage after I ran some code I wrote in Visual Studio to fill up the VRAM as much as possible (8.5 GB), and then I ran Studio with a blank scene with Iray preview on (2.2 GB), for a total of 10.7 GB.
Now you can argue that Windows shouldn't impose a large limit on individual processes (whatever that limit might be), and I'd tend to agree, since I'm not a big user of simultaneous GPU apps. But I assume there are a lot of users who like to be working on renders, and then fire up a game while they wait for the render to complete, for example, and might be very upset if they can't get a decent framerate on their game.
So ebergerly I have been trying to read all of your findings, yes about 3 months late. I have been a victim of constant DAZ renders reverting to CPU and even crashing to bugs and such for about 1.5 years. I have a similar setup with a 1080 Ti and a 2080 where I use to have two additional 1070's. I had my pagefile set to 0 and just changed it to 16GB minimum and 32GB maximum. Not sure this has helped with anything but attached is a screen shot of my Task Manager.
Are you saying that expanding from 32GB of RAM to 64GB is something that will help this situation? Or is this simply saying that I can utilize more of the RAM on the GPU's? I seem to crash out on the 2080 when I get to around 6.6GB of of the GPU's RAM. And on the 1080 Ti I seem to get to use just about 9GB before it poops out. For me I am using EVGA Precision X1 to monitor the memory usage on the GPU's.
Set pagefile to be managed by Windows.