Can confirm 20.9.1 not working on RX5700

In T75319#1019603, @Diogo Valadares Reis dos Santos (DiogoX2) wrote:

Did anyone try the 20.9.1 driver?

Did anyone try the 20.9.1 driver?

Would it be a better idea to set the socket ID to 22 (next unused socket id) rather than 18? It's breaking all existing scripts that reference socket 18 otherwise.

I finished adding it to the following importers/exporters (ready for review):

D4971 has landed.

Probably, for me atm Blender 2.9 is working with driver version 20.5.1 .

I am going to need to update the Collada importer to handle RGBM encoding similar to how I am doing for OBJ in another patch.

maybe this "fix" only include AMD video cards from this generation then.

In T75319#1017997, @Diogo Valadares Reis dos Santos (DiogoX2) wrote:

If anyone is having problems like these the only solution for now is to try to revert the drivers to the last stable ones(20.4.2)

If anyone is having problems like these the only solution for now is to try to revert the drivers to the last stable ones(20.4.2)

Hi Guys,
very similar Problem for me too, I've got some random crashes with cycles seem like, for me the sample count is important with 128s@1080p that's fine, but with 1024s@1080p it's just a matter of time till blender crashes, sometimes the AMD driver only, sometimes the complete system.
It's very annoying and not matter which blender version, it's the same for me...
Somebody can confirm the sample count dependency? Any News or Workaround at least?

New issue created for glTF emission strength here: https://github.com/KhronosGroup/glTF-Blender-IO/issues/1216

In T75319#1017323, @Arnold (kingsushi001) wrote:

Is anyone actually looking at this problem? Because this piece of fuck trash AMD calls a GPU is going back. Going back to NVidia

@Julien DUROURE (julien) this needs updates in glTF import/export. As noted above @Alex Strand (astrand130) is working on updating importers and exporters, but as I understand it there is no glTF code yet, so up to you two to figure out who does it.

Thanks for the report. This GPU is below the minimum requirements for Blender, so there is no longer support for it. https://www.blender.org/download/requirements/

Is anyone actually looking at this problem? Because this piece of fuck trash AMD calls a GPU is going back. Going back to NVidia

In D8906#218688, @Brecht Van Lommel (brecht) wrote:

BLI_cpu_brand_string needs to be fixed as well.

renderer: 'Mesa DRI Intel(R) HD Graphics 2000 (SNB GT1)'
vendor: 'Intel Open Source Technology Center'
version: '3.3 (Core Profile) Mesa 20.0.8'

BLI_cpu_brand_string needs to be fixed as well.

Unfortunately I don't have intel GPU to confirm. Can you add intel GPU model and driver version to the report? You can use Help > Report a Bug to generate this information.

Maybe information about the limitations of each compute device should appear as an information box somewhere below the choice of compute device in the preferences? That way users could see immediately as they change between compute devices what the pros/cons are for each one.

It's mentioned way over here: https://docs.blender.org/manual/en/dev/render/cycles/gpu_rendering.html#supported-features-and-limitations

thats my wish for christmas :)

Any updates so far? Anything for next iteration of 2.9? That is a must in a lot of archviz production, highly needed feature to exclude objects from light source.

Bumping this thread as I am really waiting for this bug fix as it could really speedup my production.

I have a RX580 and I also have this problem. While using Cycles with OpenCL on the GPU, my PC BOSDs.

In T78011#1014604, @Juan Gea (juang3d) wrote:

You can test some of the sampling patches in our build, in graphicall.org, the bonemaster build

This is one of the patches, the other one is the scramble distance. Brecht has to test if it’s feasible for the blender production standards, and I’m not sure if there will be more patches around

You can test some of the sampling patches in our build, in graphicall.org, the bonemaster build

From the looks of it, plus notes from the "Tuesday talks", it seems blue-noise dithered sampling is planned to be implemented by the end of bcon2. But keep in mind that things may change.

In my case, it rebuilds every time I change a settings in the shader. I added a brightness contrast node. If I change any of the two parameters, it reloads. It's unusable.

In T78011#1014317, @Zijun Zhou (Eary) wrote:

It says bcon 2 features, does it mean it is possible to see this feature in 2.91 after Sept 16 by next week?

It says bcon 2 features, does it mean it is possible to see this feature in 2.91 after Sept 16 by next week?

Obj MTL Importer/Exporter has been updated. https://developer.blender.org/D8868

Problem still persists when using generated coordinates. Scale and location are a bit off.

renamed for clarity of scope and succinctness- the description should probably be where the supposed cause or influencing variables go, not the title, and it was overly redundant. Apologies for the multiple edits- kept finding out of date information, files, and redundant text, and my current test file was far better as exposing the bug/artifact.

I agree with William here. Improving the UI layout is fine, but other than that I think everything should be left in the same place.

In T80292#1011602, @ibra (ibraz12z) wrote:

there is a solution to this problem?

I found out that if I export 'lier-scan' and 'remeshed' to .obj files and I import them both in a clean .blend the problem goes away. So somehow something got messed up in this specific .blend and it's not the geometry/topology that's causing the crash.

The circular dependency is (imho) a false positive. The image lier-model is attached to the remeshed base color image texture. But the color data is coming from lier-scan, which has a different material. Remeshed is the target object and it's texture is only written to. My guess is that the dependency checker ignores the 'selected to active' setting.

@Julian Eisel (Severin) do you agree with William here? If so, how about we keep the panel visible but not active with a text label saying to enable the mist pass.

there is a solution to this problem?

A note that there's a circular dependency "Circular dependency for image "lier-model" from object "remeshed"" . It should be removed.

If I continue from this error I immediately end up in the crash from the above stacktrace. With index consistently set to 3974, but width seems to be filled with random data, because it is different on each run and I've even seen negative values for it.

If you use a debugger (on linux VSCode or QtCreator may help [1]), Blender stops right after the assert with the variables and stack preserved, instead of printing the trace and exiting.

"index >= 0 && index < width", file=0xfa660e8 "blender/intern/cycles/kernel/../kernel/kernel_compat_cpu.h", line=77,

Cross linking it with T79707: blender 2.9 macOS 10.15.3 crash cycles rendering with viewport / into image T78793: Mac crash with cycles and any mesh (T 78581 revisited with new video card)

Could you make a simple blend file from scratch that could help us test this issue with linked objects ?

Thank you so much for debugging this out!
note to self to try to redo it.

Yes. Linked objects have some limitations with fluids cache by now.
No problem since i only link unfinished objects as a preview for the whole scene. I would use imported objects for animation purpouses once all final setups are done.

Does that mean that you have resolved the problem by clearing caches?

I want to add to this topic.
I've tried my RX 480 and RX 5700(XT bios), both are not working.
On Radeon settings 20.7.1 and 20.8.3 neither are working, sometimes it get just white like this{F8846987}
while other times Blender just crashes after a while.
On Radeon settings 20.5.1 HWS from Guru3D the viewport rendering works, but F12 is still broken for me.
I haven't tried, but I'm going to assume older drivers work just fine, also, the Radeon ProRenderer works perfectly on any driver version.

note i’ve been running into a similar issue all of a sudden using 2.82. tried upgrading to 2.9 but the issue still persists.

Is this patch alive?
Would be great if this patch becomes a feature someday.

I have this same bug and Blender crashes when using GPU, I use Sapphire Radeon Nitro+ RX 590, but my AMD Ryzen 5 2600 CPU works. They probably won't fix this because mods keep closing it and not getting attention.

Sorry everybody. Linked file Candle Final that has pre cached fluids for the flame is the problem.
Thanks. I will keep testing 2.9.

@Joselu (Xeluaxeman) what is your OS? Can you update GPU drivers?
Does this happen, when you click on File > Load Factory Settings, load your file and render?

I've got this backtrace, tried 3 times just to be sure:

What caught my eye when giving this scene a try was that your hair rendering geometry was set to:

CUDA of course. I guess something went wrong from 2.8 to 2.9. I will make some more tests but 2.9 is unstable in my case and will only keep 2.8 files until the issue is fixed.

@Joselu (Xeluaxeman), rendering with CPU or GPU?
Have you tried Optix, Cuda and OpenCL?

Just gave this scene a try and it renders without problems here:

Confirmed. In 2.83.5 you can even add plenty of geometry and external objects and works fine.

This scene rendered without problems in 2.8.
It is a project i left unfinished but had no problems until opened in 2.9 for testing pupouses.
All is optimized and i am sure it is not hardware limitation.
I think i could add more objects to the scene in 2.8 and will render.

@Brecht Van Lommel (brecht) I have investigated other exporters and am currently working on updating them. It has come to my attention that material export functionality in some exporters (particularly OBJ and FBX) are in rather poor condition and I would like to fix them. Before I am able to do that it would be very helpful if this patch could get merged and D8777 could get reviewed soon so these addons and exporters can be updated. Thank you.

It didn't crash here, but I also can't render with GPU because this OpenCL error:

OpenCL error: CL_INVALID_VALUE in clEnqueueCopyBuffer(device->cqCommandQueue, CL_MEM_PTR(buffer->device_pointer), CL_MEM_PTR(new_buffer->device_pointer), allocation->desc.offset, offset, allocation->mem->memory_size(), 0, NULL, NULL) (C:\Germano\Dev\BlenderDev\blender\intern\cycles\device\opencl\memory_manager.cpp:114)
OpenCL error: CL_INVALID_VALUE in clEnqueueCopyBuffer(device->cqCommandQueue, CL_MEM_PTR(buffer->device_pointer), CL_MEM_PTR(new_buffer->device_pointer), allocation->desc.offset, offset, allocation->mem->memory_size(), 0, NULL, NULL) (C:\Germano\Dev\BlenderDev\blender\intern\cycles\device\opencl\memory_manager.cpp:114)
OpenCL error: CL_INVALID_VALUE in clEnqueueCopyBuffer(device->cqCommandQueue, CL_MEM_PTR(buffer->device_pointer), CL_MEM_PTR(new_buffer->device_pointer), allocation->desc.offset, offset, allocation->mem->memory_size(), 0, NULL, NULL) (C:\Germano\Dev\BlenderDev\blender\intern\cycles\device\opencl\memory_manager.cpp:114)
OpenCL error: CL_INVALID_VALUE in clEnqueueCopyBuffer(device->cqCommandQueue, CL_MEM_PTR(buffer->device_pointer), CL_MEM_PTR(new_buffer->device_pointer), allocation->desc.offset, offset, allocation->mem->memory_size(), 0, NULL, NULL) (C:\Germano\Dev\BlenderDev\blender\intern\cycles\device\opencl\memory_manager.cpp:114)
OpenCL error: CL_INVALID_VALUE in clEnqueueWriteBuffer(device->cqCommandQueue, CL_MEM_PTR(new_buffer->device_pointer), CL_FALSE, offset, allocation->mem->memory_size(), allocation->mem->host_pointer, 0, NULL, NULL) (C:\Germano\Dev\BlenderDev\blender\intern\cycles\device\opencl\memory_manager.cpp:99)
OpenCL error: CL_INVALID_VALUE in clEnqueueWriteBuffer(device->cqCommandQueue, CL_MEM_PTR(new_buffer->device_pointer), CL_FALSE, offset, allocation->mem->memory_size(), allocation->mem->host_pointer, 0, NULL, NULL) (C:\Germano\Dev\BlenderDev\blender\intern\cycles\device\opencl\memory_manager.cpp:99)
Error: OpenCL error: CL_INVALID_VALUE in clEnqueueCopyBuffer(device->cqCommandQueue, CL_MEM_PTR(buffer->device_pointer), CL_MEM_PTR(new_buffer->device_pointer), allocation->desc.offset, offset, allocation->mem->memory_size(), 0, NULL, NULL) (C:\Germano\Dev\BlenderDev\blender\intern\cycles\device\opencl\memory_manager.cpp:114)

I don't know what can lead to this error, but apparently it is a memory problem, which is not surprising since this file is very complex.
For valid bug reports it is recommended that the file be simplified to the maximum. This makes it easy to identify the problem.

From reading code and descriptions seems fine.

The addition of Device::bvh_device() could be short lived - I would like to eventually postpone the Embree BVH build until after geometry has been synced to the device (similar to OptiX), that way Embree can share Cycles' vertex and index arrays instead of creating separate copies.