Viewport rendered preview freezes when using OpenCL on GPU #71258
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
19 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#71258
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?
Blender version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash:
f6cb5f5449, type: Release build date: 2019-07-29, 17:17:04platform: Linux Mint 19.2 and Ubuntu 18.04 with amd-gpu and amd-gpu-pro
Graphics card: AMD Radeon rx 570
Short description of error
Viewport rendered preview freezes when using OpenCL on GPU.
Exact steps for others to reproduce the error
LucaScheller_WaterUberShader_Tutorial_Finished.blend
Added subscriber: @schulze1963
#89121 was marked as duplicate of this issue
#79090 was marked as duplicate of this issue
#82283 was marked as duplicate of this issue
blender/blender-addons#76719 was marked as duplicate of this issue
Added subscriber: @Jeroen-Bakker
This report does not contain all the requested information, which is required for us to investigate the issue. Please test with the latest test build in order to check that this issue hasn't been solved already. Also make sure that you test with the factory settings to make sure that software that is installed on your system is not interferring.
Please attach your
system info.txtgenerated from blender (Help -> Save System Info). An example file so we can reproduce the issue.system-info.txt
system-info_2.81.txt
LucaScheller_WaterUberShader_Tutorial_Finished.blend
Files are uploadet and i test it with the factory settings and the latest 2.81 test build
Added subscriber: @iss
Changed status from 'Needs Triage' to: 'Confirmed'
Initially no crash occurs, wiewport is stuck at 1st pass of path tracing.
As soon as you try to do anything in viewport whole application becomes unresponsive
Radeon RX550 / OpenCL
opencl vieportshading with cycles and volumen objekt crash Blender and somtimes the whole systemto Viewport rendered preview freezes when using OpenCL on GPUAdded subscriber: @hyperchango
Can confirm the bug persists on 2.82a.
The application becomes completely unresponsive upon selecting "Rendered" on Viewport menu when using Cycles on GPU OpenCL.
Final render with F12 works as expected.
CPU OpenCL rendering on viewport works as expected.
Ubuntu 18.04
Sapphire Radeon RX480 4GB
amdgpu-pro 19.30 drivers
freeze_test.blend
system-info.txt
Added subscriber: @kayfee
I am also facing the same problem in my scene . blender takes to much time to render in viewport while in gpu compute(openCL) .viewport got nonresponsive if I click on screen. I tried another .blend file of my previous project and it works fine .and then another .blend file but ya same problem again occures . some of my .blend file works fine , some not . but CPU on openCL working ok . it bugging while in GPU . system-info.txt
Added subscriber: @brecht
Changed status from 'Confirmed' to: 'Needs User Info'
For Linux users, please run ./blender --debug-cycles &> cycles_debug_log.txt from the command line, trigger the bug, and attach the resulting file here.
https://docs.blender.org/manual/en/latest/advanced/command_line/launch/linux.html
It may also help to upgrade to the last amdgpu-pro 20.x drivers.
For Windows users, please run
blender_debug_log.cmdbundled with Blender, trigger the bug, and attach the resulting files here.Added subscriber: @robodraif
Added subscriber: @Sash2001
This comment was removed by @Sash2001
The same issue happened with me when i updated from blender 2.80 to 2.82a today. I had turned on OpenCL GPU rendering in cycles, viewport samples were at 32. As soon as the viewport rendered at the final sample, the whole software freezed and i had to restart my laptop. Also, the rendered samples in the viewport were white matte, not showing any of the materials/textures applied. I am using AMD Radeon R4 Graphics which has a GCN architecture support.
Have attatched the debug logs, system info and a screenshot of the viewport while rendering. Hope it is fixed soon.
blender_system_info.txt
blender_debug_output.txt
In my particular case, I could make it work on Linux by downloading latest graphics drivers from AMD, currently
amdgpu-pro-20.10-1048554-ubuntu-18.04, and installing them with the following command from console:I did notice that on the very first switch to Rendered Viewport after loading a scene for the first time, it freezes for ~2-3 minutes. Subsequent viewport switches take effect immediately as intended.
Sorry I have missed this request.
Blender will only freeze, so debug log will be only up to point when that happens. Also I have trouble reproducing outside of debugger.
But here is stack when blender was frozen
Main:
I can not see any other thread running.
Added subscriber: @(Deleted)
I can't upload/paste my terminal output right now (long night) but I've tried from 2.82 to the last available version and the issue happens if you try to use any volumetric material/node. You can be even working with no issues at all and just connect ANYTHING to the volume input and it will freeze the system.
This can be (temporary workaround if someone need it) solved by deleting old cache folders and the cycles compiled kernels folder as well. You may also want to delete your preferences.
It works for me and I can use the GPU viewport shading. But... Is terribly laggy and slower than my CPU.
At rendering time the GPU works fine alimg with the CPU.
I tested this with an nvidia card on other PC with no issues. I don't plan to purchase nvidia hardware anytime soon so I'll stick to my radeon pro...
I'll post my output as soon as I get some sleep. Hope this can be solved.
Cheers.
I'm attaching here what I describe. I started blender from command line, it just freezed using a volumetric material as described. No aditional info on the CLI just frozen as Elsa...
This happened on another computer using a RX 590 8GB. I'm on fedora, with full OpenCL support. You can also check my clinfo command to notice that. But, also happens with other distros and other video cards (AMD and recent) again with fully open CL support from the propietary AMD driver, and with other soft like davinci resolve working smooth.
clinfo
Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'
One detail, if it matters:
After trying every version above 2.80 and either get a system freeze or a pain killing blender from the system monitor, I downloaded 2.80, deleted cycles cache, every config file, and (at least) 2.80 is able to render volumes without issues (apart from some laggy viewport experience) using both evee and cycles.
Again: I'm using the AMD propietary driver with a rx 590 (8gb) running in Fedora.
I'm atacching screenshots. whatever is causing this issue, wasn't there in 2.80.
These are pretty simple case scenarios. I must also say that is literally eating for breakfast a core i7 8700 and 32gb of system RAM...
I reproduced this with no avail at all on Ubuntu with the AMD propietary driver (full pro variant) is frustrating... same results as before. frozen at the first sample with volmetric materials. Lux render works fine both on ubuntu and fedora and so does davinci resolve.
I'll go to windows... I don't like to do do. but for the time being I don't see a reliable way to use most radeon cards on Blender. Is amazing that 2.80 was working flawlessly and then ?????
a real shame. since 2.8 beta is a bug nest and I will not go for the RTX "solution" I ratter preffer to go for Maya.
I'll leave the screenshots and clinfo from ubuntu. I don't see any chance of getting this solved since 2.83 is "LTS" apart from blender, everything else works perfectly fine.
clinfo
Last post since I exhausted every option (at least reproducing this on different environments) the same happened with the latest AMD drivers on windows 10.
Basically, I'd say that cycles will freeze on viewport shading if you are using volumes. I use volumetric lights pretty often so it's a pain... The bug triggers with volume scatter.
well, Fedora, Ubuntu and Windows 10. All of them working with the AMD drivers, same result with cycles.
Added subscriber: @GAPsWorld
I use fedora 32, am using a HP Laptop Intel/Radeon hybrid, set the graphics driver to MESA to start with the AMD R7 m340, Blender 2.82 works with all Open CL and CPU modes for EEVEE, Cycles and Luxrender.
Upon using 2.83.1-5, 2.90, 2.91 even with factory defaults, at some stage freeze the screen for everything in linux, so i then have to do a user logout and restart the session, no amunt of debug helps because information is lost on user logout, i seem to get screen freeze and the cursor turns into a corrupted square and i just loose all ability to see where my pointer starts and ends and zero screen interaction with anything i had up.
i have another PC which i prefer not to use with a 1060GTX which works fine with all versions, so this seems to be an issue with blender/fedora/AMD combination. as if Blender 2.83 and above makes a UI/screen call that causes the driver or GPU memory to crash or go out of bounds or somethinng and corrupts the screen until the user is refreshed maybe? its really weird that it only happened after v2.82.
This is exactly the problem i am experencing
https://archived.forum.manjaro.org/t/using-blender-recently-inevitably-causes-desktop-display-crash/153768
I have not tried reverting to Kernal 5.4 LTS though as i am currently on Kernal 5.7 and no previous kernal version has worked before that using B283+ at this point
Added subscriber: @gary-4
I'm still getting this issues on: Fedora 32, Ubuntu and Windows 10. All of them seem to be related to volume scatter.
As for fedora, I'm using amdgpu (open source) and Opencl (from amd) to do it just uncompress the ubuntu/rhel drivers (only the openCl needed stuff) and luxrender works like a charm and so does davinci resolce and darktable.
Ubuntu: No need to get into complications. Just use the AMD privative drivers. Same result. freezes using volume scatter, so any volumetric material crash and burn.. Obviously, this doesn't happens with EEVEE It's using OpenGl. so it works fine even without any aditional driver.
Windows: Same as ubuntu.
@gary-4 Parris You say that you are using an R7 card? That's an old architecture and even on windows cycles is not supported. I tested it with a R9 270x and I don't have any opencl support, both in windows and Linux.
I recently reproduced the same on centos. So, I would not say that this is fedora only.
One more thing: Nvidia cards won't cause any issue no matter the system, OS, distro. I tested a 150TI and a 1080TI. fine in both cases.
This seems to be related to the polaris architecture of some AMD cards, and that's not good. At all.
NO! I am using a laptop with hybrid intel/Radeon R7 m340/440 it works in open cl on blender v282 in cycles/EEVEE/Luxcore render without problems, so no you are wrong about the capability of the GPU which is built into the laptop which is just 2years old!
It is a problem that exists between blender/fedora/AMD GPU's. I appreciate your response but your test and assumptions are incorrect about the R7 m340/440, because it wouldn't work in luxcore nor blender 282.
@gary-4 Parris
Sorry. I might have confused your card model (not very familiarized with laptops..) But I reproduced this on Fedora, Ubuntu and windows. And yet again, Not only poor performance on the viewport using cycles. But is a persistent issue across more than one distro and OS.
On my case, as I said, the viewport goes brutally faster with my core I9 than with a RX 590 8GB. also tested with a RX580. Both have Polaris architecture. Both fail with volumes.
You can check the screenshots that I posted. Right now, I'm using EEVEE and avoiding cycles.
If someone can reproduce this with the same or similar (Polaris) AMD cards would be nice and a step forward.
You are wrong assuming that is a "fedora combo issue" IT IS NOT.
yet again, if no one reproduces the issue we'll never know. I already posted what I know. BTW: I still have this issue and right now I'm using windows...
I'll hit the bed. Bye.
By the way. EEVEE WILL NOT USE OPENCL. Is OPENGL... you can use it without any openCL driver.
Bedtime...
No problem sleep well, the issue is reproduce able, see the link I posted. Also I set hardware to none in blender I only choose CPU or GPU in any mode, and path or bdir + metropolis in b282. Luxcore recognises the GPU in all blender versions when I select GPU, but regardless b283+ continues to freeze no mater what is loaded and used and any add ons from the default clean factory loaded or anything else.
@gary-4 stocker (gary) Well, then we have to llok at AMD and their drivers. The linux versions seems to be just like the windows adrenaline version.
A curiosity (or not) is that using their "pro" driver on windows the cycles viewport takes an eternity to gather 32 samples and feels laggy. But in spite of that, is able to render volumes although I have to use CPU for the viewport to avoid freezing and hangs, everything goes smooth rendering with the GPU + CPU.
I'm using 2.83 LTS. Lux render works like a charm, both as standalone in Maya or as lux core addon in blender.
I think that the polaris arch of my Video card has a lot to do with it, and that is no good new at all. But I'll stick to radeon cards for the time being the cost benefit beats Nvidia I about to purchase a pro card so I'll test there on the same scenarios and post what I can. So far, I can't post any error log, I don't have any!! the computer hangs I have to hard reset it using the power button pressed for a while so i can't get the terminal output and don't find any error log.
2.8 is becoming both a pleasant experience and a pain. EEVEE is an amazing thing for animations a quick sims but cycles is giving me a huge pain so I switched to lux.
Hope this can be fixed. Sometimes, making the same materials over and over for two render engines is not funny. And right now, EEVEE is my choice for VFX. lux can't cover that. on the other hand... I also need cycles to bake textures for games.
Nice mess...
when it works like in B2.82a it works well, i have also tested Luxcore 2.3 on B2.82a/2.83.5/2.90a/2.91 and it works fine on CPU, iv've also tried Luxcore 2.5 and choosing GPU crashes blender in the latest 2.90/2.91 so thats interesting, it also doesnt show the GPU in device list.
You can use cycles materials in Luxcore + in 2.4 its a lot faster doing so, but i love Luxcore for its Glass caustics etc etc which is why i use it!
but theres definitely some GPU RAM suspicious things going on when using AMD that needs looking into... i dont understand why its causing more problems with Blender than the NVIDIA cards :O(
Here are some files for system info from Blender with screenshots
blender-system-info.txt
@gary-4 Parris AMD (or better said, openCL) is not the best companion to work with blender. an example, is that a basic Nvidia GTX 1050TI 4GB can handle the cycles viewport like a champ compared with a Radeon RX 590 or even a 5700. I've been using lux for a long time instead of cycles due to this. I'll attach more info later. Right now, I have a rx 590 and a rx580 both polaris.
Yes. Is an issue with AMD cards, and persistent along blender versions. I'll post info when I can but the viewport is a mess and the freezing (on my case) happens using volume scatter ON CYCLES ONLY every other soft works fast as hell compared with a 1050ti.
I'll try to get some logs.
Added subscriber: @IgnisCogitare
i have since 2.90.1+ been able to use the commanline DRI_PRIME=1 /home/yourloginname/blender-2.91.0/blender and have had no more freezes or crashes experienced before, for the last month i have been able to use all blender versions like this. this needs to be out there for others to run blender without freezing on multiGPU laptops.
I've been following this, to see if any solution or bug fix came up to solve this. every single 2.8.x version causes my computer to freeze using volumetric materials/shaders and by freeze I mean, that I need to hard reset my computer. I already tried with different scenarios:
1- Using windows with both the AMD "pro" and "adrenalin" up to date drivers. No avail.
2- The entire propietary AMD driver on Ubuntu, No avail
3- CentOS 8 with the entire propietary AMD driver. again, no avail.
4- Any other Linux distro using only the OpenCL propietary part. same result.
So, basically, the viewport is a no go if you even try to go to the rendered view using a volumetric material the result is crash and burn. works fine using CPU only on the viewport and using the GPU for rendering, but let's be honest. Sucks.
The only version that doesn't crash is 2.80RC1 but... the viewport takes A LOT to gather 32 samples using the GPU. so is basically the same.
I made tests with a rx590 8gb but I also have the same use with a wx. Does anybody care about AMD cards or the idea is "hey... go ahead and get an nvidia card. It will work" because testing with a 1050TI and a 960 I get less issues and more performance. And no, this is no AMD's failure because very other software using the video card (even blender itself with eevee) and OpenGL delivers A LOT more horsepower with the radeon cards.
Can you save the system info? Yes.
Can you get some error logs? No. The complete computer crash won't allow me to do that.
I'll attach what I have, but every single version since 2.80 has been a pain for me.
system-info.txt
error.blend
The .blend file is just the default cube with a volume scatter node. That is enough to crash the system using the GPU and turn to rendered viewport.
Added subscribers: @PANCHO7532, @BlenderMacUser, @RTamaasP, @EnderProtix, @iamcapmurica, @ramanamono
Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'
I can still reproduce this so changing to confirmed
I think noone will care about cheap AMD gpu-s they will tell us "this is suck, but what about buying an NVIDIA? this will solve all your problem" And I think this toughts very annoying
@RTamaasP
Either if you are being ironic or not this also happens with NON CHEAP AMD GPU's but you you can get a cheap a** GTX1050TI and get better results than with a RX 5700xt. It surely sucks.
for my laptop, my radeon gpu is a passthrough from the intel on chip GPU for example on fedora 32 i had to add to my Grub file
Edit /etc/default/grub to have the following lines and information.
GRUB_CMDLINE_LINUX="rhgb quiet splash amdgpu.dc=0 radeon.cik_support=0 amdgpu.cik_support=1"
"radeon.cik" is the volcanic islands hence the (.cik) not the (.cis), mine is iceland, and that coupled with making sure i ran blender with the correct adminsitration rights for myuserprofile but from the commandline using the command
DRI_PRIME=1 /home/myuserprofile/blender-2.92.0/blender
this means i can not only run blender any version, but blender also recognises the GPU when choosing GPU render despite not showing up in the hardware, and i can also use Luxcore which also shows the iceland GPU in its render settings too.
maybe this will help someone else.
Added subscriber: @Cosmocrat
I have this problem too. if I try to render any object with the volumetric shader applied (think fog), the entire desktop freezes. I have to shut off my PC by either holding the power button down or use SSH to reboot. My GPU is the RX580
system-info.txt cycles_debug_log.txt
doing
DRI_PRIME=1 /usr/bin/blendermade no differenceI am using
amdgpu-pro version 20.40for the OpenCL driver only.This is what the system load looks like during the freeze seen from my phone using Termux and SSH (top is
htopand bottom isradeontop -c)(the GPU load averages around 50% usage)
Output of
dmesghttps://pastebin.com/zALqUancOutput of
clinfohttps://pastebin.com/BvZz6B3bAdded subscriber: @eclay104
I thought that this issue rendering volumes, had a strict relation with AMD Polaris architecture only. But that's not the case. I've been testing on windows with other cards and also asked a few friends to check this out with the new AMD architecture and the result is exactly the same. Although one can notice that the OpenCL kernels may compile/load a bit faster it is not a huge step if this scenario still as it is.
On the other hand, and please, confirm and reproduce this the rendered GPU viewport takes ages to gather samples either with an AMD or Nvidia card if it's set to use GPU for that.
I also noticed that it is not possible to bake transparent textures anymore. -Tested from 2.82 to 2.9x- Well, this doesn't look like a bug, but is terrible if you need to bake textures for real time use (architecture for example) or for a game engine.
I give up with the viewport. But is pretty much a mess having to use CPU on large detailed heavy scenarios and even avoiding volumes, the viewport is still laggy with every GPU that I've tested.
Added subscriber: @gazzatav
Have this same issue with Radeon rx 5700 xt using Blender 2.91 with cycles on Ubuntu 18.04. With one scene, rendering stalls after compiling the kernels. At that stage Blender can still be killed using top or kill command in a terminal window. If I click a few buttons on Blender the machine becomes unresponsive to mouse and keyboard but I can ssh in and kill Blender and reboot. I thought for a while it was the file itself as it was started in 2.79, however I've also reproduced this with a fresh blend file with, say, 20 copies of the default cube rendering the preview with gpu.
I strongly suspect the issue is with AMD drivers rather than Blender. cycles_debug_log.txt
I strongly suspect the issue is with AMD drivers rather than Blender.
@gazzatav I doubt that this is a driver issue. I've tested this on several Linux distros. Debian, Ubuntu, Fedora, CentOS, and even RHEL with my developer account. Either with the full installation of the driver or with the openCL part only and leaving the open source amdgpu driver the result is crash and burn. The same happens on windows 10.
I haven't found issues to render with cycles using the GPU. But the viewport is another story. EEVEE performs amazingly well both with a polaris and a navy card. But eevee will do the job because it's using OPENGL not OPENGL. Basically, Cycles seems to be using OpenCL on the viewport render, and freezing the system if a volume is in use.
Yet again, and I've tested this with a 2070ti too a frined gig. Ok, yes, awesome. volumes work. But you still have an extemely low sample gathering with GPU in use, and GPU manages to do it faster.
Is not a minor issue, is not the AMD driver. Otherwise, your PC would crash using volumes with any software using openCL and corona or Lux can do it without any hassle.
Added subscriber: @ii3osshogg
This is happening on Nvidia Cards also - 1080ti can not do anything once the models load (actual work for viewport) hits the card. Usually in changing the viewport to show shadow (in my sequence) will put into freeze. Depending on registry TDR time setting is usually equal to the time of freeze before crashing & if you stack the calls times the TDR Delay you will come up with your length/severity of freeze. Even this beast of a card can not handle the 100% load due to TDR (even at over 90).
I know the reader will probably say 'wth is he talking about?' here --- > If any setting on comp calls for 'hardware acceleration' and a GPU gets a call for this, weather you are browsing web, using GIMP, or any other 3rd party program, this same error will occur. (this kicks on/reqs the OpenCL to handle the task in some manner is why it is mentioned) It will report to windows 'Hardware Error' 'Not Reported' and call its code 141, which is in reference to GPU driver issues. If anyone is having this same error, it may also come with some pixilation & 'rain' dots that are inverse pixel specs on the screen. This is even outside of blender. So when I have trouble shot this issue the past week, I notice Turing architecture will not fail, but the older architecture will fail. It is an issue with OpenCL file acting as terrible hinder vs. helper.
My post doesn't have any of your specs / stats and all that stuff, so It's OK to remove it & call it outrageous /ridiculous as nobody knows me, & I have no details due to the fact that it is kinda hard to screen-shot a frozen screen & system stats are kinda redundant when probably over 5K people (in NVidia forums) are complaining of same issue, except on a certain game, and i can tell you it is doing the same exact behavior, as another one did years ago with a different name.
And the issue is the OpenCL file will somehow work like 'hardware acceleration' works, but it only hurts things creating the TDR to timeout and windows calling it a hardware failure. But this comes from the command from the programs to hand all to OpenCL in some manner. I do not code python or blender, but i code other things, and as being semi-literate in how things work, but maybe you might wish to look outside of this tiny post and this tiny program for a bigger scale of this happening.
Sorry for not posting my system specs and a recorded emulation of a frozen screen that causes a crash.... But this is more of a generalized message to someone who has the brain-power and authority that could actually DISABLE the OpenCL 'acceleration' that freezes things, that might be a temp fix.
I have no idea if this is possible, but if so, and if you can, please send the code for temp disabling of OpenCL to NVidia as they have post after post after post of user complaining of this as well. All using the 10-series cards. If i were using my coding skills, I would probably set an argument to grab the time & send fake message to windows TDR that the delay is not exceeded while the GPU sorts out the load with OpenCL. And I really think if OpenCL could be stopped for a moment (without stopping entire progress of desired action), there would be no need to worry about TDR as that is what windows classifies the error to stem from on error logs.
I have spent 2 days on it and somewhere there is a glitch on the path mentioned. And it is not just AMD cards. It is all cards that will somehow send a 100% full load to the card, kicking in TDR and depending upon registry settings, Blender may Freeze, crash, or windows in its entirety will crash. And this issue has happened already in blender 2.81 a little less than 2 years ago. I do not know what fixed it, but i am sure some of the Guru's here can recall the issue.
**NOTE:: It takes time to type all this out. If you just call is shit and say it's not more blender hard-data 'proof' and remove the connection I have presented (which is partially presented above), then maybe one is not interested in finding solution, but still trying to prove weather it exists or not a year down the line....
@ii3osshogg Thanks for putting me straight. I had been happily using 2.79b but thought it was about time to get with the flow and try out 2.91. When it had so many issues with GPU rendering I tried using 2.83 and found the same behaviour. I saw the posts about 2.83 and thought that must have been fixed by now so assumed it was the amdgpu-pro driver, especially as the whole machine was hung not just Blender. I'm pretty sure I couldn't get Lux to work before I uninstalled amdgpu-pro in despair but I'll give that another go.
By the way, when you said
I take it you meant 'OPENGL not OPENCL' and in the phrase
did you mean 'GPU in use, and CPU manages to do it faster'? Otherwise I'm not sure what you meant.
At the moment, this issue can be considered "mild" compared with a force close using GPU rendering with 2.92 this leaves a huge amount of users without GPU support.
https://developer.blender.org/T86182
Using Radeon Software 20.10.1, with MSI rx580 8 gb OC ed. and doesn't work with ANY versions of blender, EXCEPT 2.92, but now it works extremely well. Like before this took literally minutes even to react anything after I applied the volume (and then crashed at 1 samples), now not even increasing the viewport render time.
Things may help you:
I applied this to my computer instantly after I reseted Windows nowadays: https://docs.substance3d.com/spdoc/gpu-drivers-crash-with-long-computations-128745489.html
And the Render: Agile Render addon: https://blendermarket.com/products/agile-render (you don't have to pay for that, but search the free download link on your own in that site)
and ofc USE 2.92, because thats probably the main reason of that volumes started to work in viewport too...
I made the viewport render with "agile cycles" preset, but I tried without using this addon too, and it worked. Viewport denoising is on with OpenImageDenoise, start sample 15, viewport samples at 16.
@RTamaasP This is not a place to talk about third party software. The OP (and so Am I) are on Linux. I'm aware about the eternal warning that substance painter gives you when you start it but it not applies to this issue. Furthermore, ATM I'm stuck with no GPU at all at 2.92. You can check that here. As I said, third party addons will not help to solve a bug.
#86780
It does count. But actually didn't solved the problem... This preset doesn't need to use openCL, it uses the CPU for render, but the GPU for denoise the viewport insanely well. So yeah, even in 2.92, the problem is still unsolved.
Added subscriber: @stealth86
Added subscriber: @newell19
Any updates on this? I am hitting the same exact issue as Armand is. I am using:
Ubuntu 20.04.3
Radeon VII Vega 20
blender 2.9.3 (snap not deb)
It appears that this bug has not even been assigned to anyone. :(
Cheers
@newell19 ATM, I already closed the issue related to a completely broken OpenCl rendering. You can see it here. #86782 This issue on the other hand, still persists in 2.93 LTS. Right now I'm on debian with the drivers working perfectly fine with everything else. I don't know if OpenCL is getting any attention from the developers. I used a dayly buils until 2.93 get OpenCl working. Yet..
Is still slower than a GTX 1050 TI 4Gb RAM and I'm using a RX 590 8GB that should work overwhelmingly better. Is really sad to see that using two old cards (1050TI 4GB and 9604GB) they can work at the same time and you get almost 2000 Cuda cores. But again, I can't afford a modern Nvidia card and the performance of AMD cards with blender right now is not very useful. Laggy and slow cyclñes GPU viewport, no GPU texture baking, broken volumes that cause a freeze until today...
Guys and girls: I'd really love to have a titan or a Quadro. But Nvidia is prohibitive to me right now. I see that you work flawlessly with Nvidia. AMD is not the case.
It seems that AMD cards are ignored by a lot of render engines (even maya is an Nvidia hungry soft) the thing is, that my card works out of the box on linux (as well as almost every AMD card) but you know very well that Nvidia is more than just an issue. I don't want a driver that blows MESA away and do unknown stuff right ahead with the HAL. Even Linus Torvalds has pointed out that Nvidia is not very friendly a lot of times.
Is a shame. I've been using blender since I can remember. I could install windows but it will not offer nothing fancy to me and this issue is on windows too. I just can't try to get a decent VFX.
I understand that out of my country getting a card that works with blender will not represent issues for most. But right now, blender has become a piece of soft that I can't afford. RTX 3070 = ARS 300.000 That equals four months of a "decent" wage down here. And I know that others can say the same. And that's why this is a shame. AMD rules the market in the third world. That should be a helluva motivation to get this working.
I don't think it's gonna get fixed for opencl. Just disable volume for viewport. In final render it does work though.
For blender 3.0, opencl cycles will be removed. And AMD and blender are working on a new way to make it work more inline with cuda cycles (called HIP C++ implementation or something).
That was unexpected. (more or less) They should completely drop it as the did with Apple if it doesn't works properly -or in a barely decent way- @ramanamono Thanks. I know that the final render does use the GPU but it is unusable. As I said, is below the performance of an old low profile Nvidia card.
People from blender: Please! Do not create another half working attempt to capture AMD users too. You don't need to! after all, you have the Adobe and Nvidia support. I believe that as said above, same as Apple users, you should say "nope" and write concise and straight to the point software requirements to look like a transparent project. Be clear:" YOU NEED THE NVIDIA DRIVER " As a GNU/Linux user, I've been with you since the begining. But I'm still a Linux user. And with windows 11 coming up with a lot things that "Enhance my digital pain" I will stick to Linux. Therefore, I think that blender is like a puppy that grew a lot. But in this case, I still find it with enough bugs to be working on another pieces of the whole to get away from Andew "donuts" and certain people that in spite of being a nice marketing strategy, are at the end, promoting it to ABC1 public using windows.
You should go ahead and drop it now. It's still incomplete and buggy. When I spoke about this on my blog I was in doubt about this getting solved. Regretfully I was wrong.
Added subscriber: @ThomasDinges
Changed status from 'Confirmed' to: 'Archived'
OpenCL rendering support was removed in Blender 3.0.
The combination of the limited Cycles kernel implementation, driver bugs, and stalled OpenCL standard
has made maintenance too difficult. Thanks for your report, but it's unlikely that there will be further fixes for OpenCL.
For AMD GPUs, there is a new backend based on the HIP platform.
In Blender 3.0, this is supported on Windows with RDNA and RDNA2 generation discrete graphics cards.
It includes Radeon RX 5000 and RX 6000 series GPUs. Driver version Radeon Pro 21.Q4 or newer is required.
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://code.blender.org/2021/11/next-level-support-for-amd-gpus/