Something wrong with the VRAM #92139
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#92139
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 472.12
Blender Version
Broken: version: 2.93.3, branch: master, commit date: 2021-08-17 18:30, hash:
8b80d19f36Short description of error
The VRAM occupies 4GIB when i set a new empty project with Cycles's Viewport Shading，Even if I delete all assets。
Except blender, no other program occupies the VRAM.
I have try to reset the blender,and reset the 3080 drive，but doesn't work.
Is same to the blender 3.0.
Exact steps for others to reproduce the error
Just creat a new project, and set the Cycles Viewport Shading work with GPU.
Added subscriber: @dawn123
Added subscriber: @iss
Changed status from 'Needs Triage' to: 'Needs User Info'
Can't reproduce this VRAM usage is around 0.8GB by Blender here.
That said, Blender reports total VRAM usage (includes other apps) so please check if this is really exclusively used by Blender (close Blender and look at change in task manager)
Thank you for your reply!
The fluctuation of VRAM obviously comes from Blender，Before and after the test, I took screenshots. Please have a look。
And i found a user who had a 3080 ,and he reproduce this problem.
But the 2060's user or 3060's user,they are work in the right way.
I think it's probobly because of the 3080.
By the way, our 3080 is limit hash rate version. I don't know if it's related。
Changed status from 'Needs User Info' to: 'Needs Triage'
Added subscriber: @Sergey
@Sergey Do you know if different GPU models in same series can use significantly different amount of memory? Really not sure if this could be bug or how to tell even.
Cycles requires a state for the paths to be allocated on the device, and this state is not really dependent on the scene complexity. A bit weird though to see 4GiB use, but maybe it's how the math based on the number of multiprocessors and threads on the device.
Run Blender from the command line:
blender --debug-cycles --verbose 3and look for theGPU queue concurrent statesmessage. It will give number of states and approximate memory usage for them.P.S. There is also memory used by the path tracing kernels themselves, but I am not sure if we can see how much of VRAM those are using.
I didn‘t find out the GPU queue concurrent states message.
Please use file attachment, inlining logs converts conversation to be unreadable very quickly.
I didn't realize you are talking about 2.93 (i thought it's about latest Blender, where Cycles got a major re-write). In 2.93. it only will be memory allocated for the kernel by the driver. Don't think we have control over that.
Give it a try with the latest Blender 3.0 from the buildbot!
sorry for that.
I just download the Blender3.0(2021-10-11) and test.
The VRAM Proportion is Same as the old version ：(
Can you run same command with alpha version and upload output here?
Blender3.0 .txt
Don't see anything out of ordinary really. I thought that perhaps screen resolution would have impact, but I don't see much increase in memory usage when rendering on 4K monitor.
I've tested in 2K or 1080p screen resolution and there's no improvement.
I think i should creat a huge project and test on the other Video card，Compare the VRAM on work.
I'll report lately.
I created a project with some textrues and tested it, is compare 9.2G VRAM in 3080.
And compare 7.5G VRAM in 2060.
Added subscriber: @Alaska
The 2060 Super only has 6GB of VRAM. This means the value being reported is inaccurate. Maybe you're talking about a RTX 2060 Super which has 8GB of VRAM. But in that case, this is probably expected. You'll never utilize 9GB of VRAM on a 6GB or 8GB card.
It should also be noted that Ampere (RTX 30 series) has a bug in it's drivers which results in higher VRAM usage over previous generations when rendering with in Cycles with OptiX (and certain settings?). I'm not sure if this bug has been fixed yet. It was talked about here: #90143 (Failed to build OptiX acceleration structure when using Image Sequence instead of Single Image with Geometry Nodes (with Motion Blur))
As for your other issues with Blender and Cycles taking up 4GB of VRAM in a empty scene, I'm not sure what's causing that.
Sorry!That's my fault，is 2070 MQ with 8GB VRAM,not the 2060.
Thank's for your reply.
It also looks like you have a collection of add-ons installed that might be impacting this in some way. Are you able to try loading Blender factory defaults, enabling your GPU, then testing again? To load factory defaults, select from the top of Blender
File -> Defaults -> Load Factory Settingsthen enable your GPU and test your simple scene to see if that helped at all.As a side note for @iss or @Sergey for you two to use as reference:
Here is a chart of VRAM usage for Blender + Cycles in various configurations as reported by
nvidia-smi. This does NOT include VRAM used by other applications. In all cases, I am using the default scene for Blender obtained byloading factory settingsI also decided to grab the
GPU queue concurrent statesinformation for you to use as reference:GPU queue concurrent states: 2015232, using up to 1.04GSystem Information
Operating system: Linux-5.14.0-2-amd64-x86_64-with-glibc2.33 64 Bits
Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 470.63.01
Monitor: 1920x1080 resolution at 120hz
Blender Version:
Broken: version: 3.0.0 Alpha, branch: master, commit date: 2021-10-14 04:36, hash:
5fec6eda55After loading Blender factory defaults.
System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 472.12
Monitor: 3840x2160 32bit 60hz
Blender Version:
3.0.0 Alpha, branch: master, commit date: 2021-10-11 23:14, hash:
4b31a21bcdWhere did you get the VRAM usage from and what is it measuring? Is it measuring the VRAM used on your GPU (Blender + Everything else), or is it measuring the VRAM used by just Blender?
This comment was removed by @dawn123
I get it from nvidia-smi , is Blender + Everything else.
Before I open the Blender,the VRAM is 0.5G.
In that case, it seems VRAM scaling as you enable the Cycles viewport is similar to my computer. And unless we're both experiencing the same bug, then it seems Cycles is working as expected.
The main issue seems to come from the fact Blender uses roughly 900MiB after loading factory defaults. And I'm not really sure what's causing that. Hopefully others can help you in figuring that out?
Yes,I don't know if this is a bug，
I thought it was preloaded VRAM, but when I added assets, VRAM will still improve.
I'm a technical rookie, but I think the default scene occupies 3G VRAM, which is a little strange compared with other graphics cards.
Thank you,bro.
One thing that should be noted, increasing my resolution to 3840x2160 results in the VRAM usage for Blender while it is open in the default scene prior to enabling viewport rendering has
nvidia-smireporting Blenders VRAM usage to be477MiB()As would be expected when you increase the pixel count). This means Blender running on @dawn123 s computer is taking up an extra 400ish MiB compared to mine. Still not sure what's causing that? Maybe it's just a difference between Linux and Windows?Added subscriber: @lichtwerk
Changed status from 'Needs Triage' to: 'Needs User Info'
Just to be sure (since this has been lying around for so long -- sorry about that): this is still happening in fresh 3.1 / 3.2 builds from https://builder.blender.org/download/daily/ with updated drivers?
Changed status from 'Needs User Info' to: 'Archived'
No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.
Thanks again for the report. If the problem persists please open a new report with the required information.