After sharing this [[ https://devtalk.blender.org/t/bad-dependencies-between-viewport-render-and-actual-memory-consumption-in-headleass-background-mode/24537 | post ]]linking to our conversation

@Alaska (Alaska) oh, thanks, thats interesting!

rB342e12d6d921: Subdiv: support interpolating orco coordinates in subdivision surfaces is the first bad commit.
Cc. @Brecht Van Lommel (brecht)

@Vyacheslav (hitrpr) The file provided below uses an alternative method to create the dispersion and produces a "alright" result with MNEE Caustics. This doesn't "fix the bug", but it's something useful for users wanting to use dispersion with MNEE caustics with the current limitation.

Can I confirm. It's a recent regression.
Looking for the commit that caused the problem...

It was only intended as a guide given context constraints of the design of Looks etc., and as such, the False Colour will fall apart. Doubly so with a 3D LUT. There were a number of reasons to make concessions. I would expect it to fall to bits!

"The RGB to BW is done in Filmic Log" Is that so in Blender? If that is the case it is a bug.

In T98405#1365673, @Brecht Van Lommel (brecht) wrote:

It's multiplying with the luminance coefficients in log space, but they only make scene in linear space

In T98366#1364419, @Jacques Lucke (JacquesLucke) wrote:

I don't think that's ideal indeed, but I guess there is still an intent to mark with float2 attributes are UV maps, or not?

Yes, that still sounds reasonable to me, but it's not very urgent to me currently, especially when we've solved the "active uv map" issue in a different way.
Such a tag would still be useful when some node does special handling for uv maps for reasons that I don't know right now.

If your GPU usage before rendering is 5.6GB than this would fail as rendering process takes around 4GB.

alight, not what i was hoping for, given i have no desire to go debug ocloc but progress nonetheless

soo.. some good news, bad news.

I am just saying that this memory is not only allocated for rendering, but also for other things that Blender does, so it is not entirely unreasonable that the visibility of objects in the view layer might have an effect this. I would just wait for a more informed answer on devtalk.

you dont think viewport flags should not affect background mode render ?

The memory usage at the start of the status line accounts for all allocations that Blender made, even outside of any rendering operations, so I think it is expected to see an elevated memory usage when more objects are involved in the view layer update.
I am probably not the right person to give you insights, but since this tracker is for bugs and errors, I would suggest you post this in https://devtalk.blender.org/, where you might get better insights. But arching this for now.

I made the update and worked for me, now i have optix enable with my RTX 3060. Now i´ll enjoy faster render times!
Thank you so much sir!

Yes, I've had faster render times with Optix than with just CUDA.

If all tools, modifiers and nodes automatically set the active UV map on creation, are there cases where this would happen and users would have to go and fix the active UV map?

Guess that depends on how the ui for creating uv maps look like. We could e.g. have a drop down in the Store Named Attribute node that allows the user to pick "uv map", and then the default uv map would be set on the mesh automatically. The same would be needed in the modifier ui or node group output ui (where it's possible to create named attributes as well). With that, I don't think users would have to manually set the default uv map in almost all cases. A special node for that might still be useful when importing external data within a node, where it's not clear what attribute is a uv map.

In T98366#1364403, @Jacques Lucke (JacquesLucke) wrote:

I think if no name is set, or the attribute does not exist, then no attribute should be used. These heuristics of where to use which attributes seem to cause us more trouble than it's worth.

Thanks for your attention, I have downloaded the last alpha today and I still have the issue.
I have uploaded the logs and the problem can be seen in there. My GPU usage before rendering is around 5.6 GB / 8 GB. It varies a bit depending the view in the viewport. Fun fact I have just discovered, depending on that view in the viewport, the "rendered mode" works sometimes. In this case I can change the view and navigate in the viewport without any issue (and even very smooth).

but this will require adding validation in various places that add/remove attributes, not just manually by the user but also in the modifier stack or geometry nodes.

• Storing a name seems reasonable to me, but this will require adding validation in various places that add/remove attributes, not just manually by the user but also in the modifier stack or geometry nodes.
• If no name is set, will just the first attribute with the appropriate type in the list of attributes be used? Or would it be valid for none to be active?
• Merging meshes with different active attribute names is no new problem I think, is already something users may need to handle.
• I think it makes sense to have "default" and "edit" attributes. Not sure the term "active" is needed still.

Thanks for the contribution.

I was able to reproduce this issue with a 5700XT + Ubuntu 20.04 + ROCm 5.1.2 with bmw and classroom scenes. I'm looking into this.

Right, sorry, I misunderstood the report. I guess there should be an appropriate error indeed, but this is not strictly a bug, so I will tag the module to see if something can be done about this.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

I think you double counted igc in dpcpp. On my system it's closer to 300M.
libigc is indeed very large... gzip compression improves the situation a little bit but we can make it more reasonable by stripping debug symbols:
994M libigc.so.1.0.1
327M libigc.so.1.0.1.gz
85M libigc.so.1.0.1_stripped-debug-symbols

Oh nice! I´ll try with that version of driver. With optix enable the renders go faster, rigth?

I've had problems with newer drivers. I rolled back to Studio Driver version 472.84.

Hi, i updated my drivers to Studio drivers and i still having the error. How can i fix it?
i have windows 10 and a RTX 3060
32GB of RAM
and Ryzen 3700x.

I can't reproduce here, .blend file did render without issues.
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.65

all the buildscripts should be complete, they should build with no issues on both windows and centos (centos7 disclaimer, the stock flex is outdated, needs to be replaced with a build from source 2.6.4 or you'll have build errors), the blender windows build with dg2 enabled I made @Xavier Hallade (xavier) was able to confirm as working, on linux all the puzzle pieces are in place but due to my centos container running out of ram i could not complete a blender build there.

Okay, you are right, that seems significant indeed.