Blender version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: f6cb5f54494e, type: Release build date: 2019-07-29, 17:17:04
platform: 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
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.txt generated from blender (Help -> Save System Info). An example file so we can reproduce the issue.
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
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
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 .
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.cmd bundled with Blender, trigger the bug, and attach the resulting files here.
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.
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:
./amdgpu-pro-install --opencl=legacy,pal
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:
> [Inline Frame] blender.exe!std::thread::join() Line 113 C++ blender.exe!ccl::thread::join() Line 63 C++ blender.exe!ccl::TaskScheduler::exit() Line 357 C++ blender.exe!ccl::Session::~Session() Line 135 C++ blender.exe!ccl::BlenderSession::free_session() Line 253 C++ blender.exe!ccl::BlenderSession::~BlenderSession() Line 115 C++ blender.exe!ccl::free_func(_object * __formal, _object * value) Line 270 C++ [External Code] blender.exe!BPY_DECREF_RNA_INVALIDATE(void * pyob_ptr) Line 610 C blender.exe!RE_engine_free(RenderEngine * engine) Line 161 C blender.exe!ED_view3d_stop_render_preview(wmWindowManager * wm, ARegion * region) Line 239 C blender.exe!ED_region_exit(bContext * C, ARegion * region) Line 544 C blender.exe!ED_area_exit(bContext * C, ScrArea * area) Line 579 C blender.exe!ED_screen_exit(bContext * C, wmWindow * window, bScreen * screen) Line 612 C blender.exe!WM_exit_ex(bContext * C, const bool do_python) Line 520 C blender.exe!WM_exit(bContext * C) Line 683 C blender.exe!wm_exit_handler(bContext * C, const wmEvent * event, void * userdata) Line 455 C blender.exe!wm_handler_ui_call(bContext * C, wmEventHandler_UI * handler, const wmEvent * event, int always_pass) Line 619 C blender.exe!wm_handlers_do_intern(bContext * C, wmEvent * event, ListBase * handlers) Line 2725 C blender.exe!wm_handlers_do(bContext * C, wmEvent * event, ListBase * handlers) Line 2837 C blender.exe!wm_event_do_handlers(bContext * C) Line 3250 C blender.exe!WM_main(bContext * C) Line 453 C blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 530 C [External Code]
I can not see any other thread running.
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.
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.
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.
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
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 stocker (gary) 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 stocker (gary) 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 stocker (gary) 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(
@gary stocker (gary) 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.
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.
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.
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
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
@Tamás Péter Radványi (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.
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
doing DRI_PRIME=1 /usr/bin/blender made no difference
I am using amdgpu-pro version 20.40 for 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 htop and bottom is radeontop -c)
(the GPU load averages around 50% usage)
Output of dmesg https://pastebin.com/zALqUanc
Output of clinfo https://pastebin.com/BvZz6B3b
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.
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.
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.
@Gary Taverner (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.
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.
Delete my post if you want, as I'm sure it's all gibberish, ill-formatted, no-recorded freeze to reference, & non-sense to the one who rarely step outside of Blender, or the web for that matter - but maybe someone know what I am saying, and know more of the inner workings better than I do - & maybe secretly it can be used to figure this out by an insider. And please do not pick apart my attempt to help and quote me on shit. I'm just trying to help and have been working on this for a couple of days myself. And as i re-read the data above, it looks like little has been done in the last year to to closer to fixing.... just the endless needing the prove and re-prove and re-prove the that the problem exists. Well, why doesn't someone with a bigger Blender/GPU brain than myself work on a fix. It has been over a year it looks like. Maybe we could work on fixing it instead of just the endless back and forth on weather or not it exists... I would like to use Blender again someday.
**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....
@DLP (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
because it's using OPENGL not OPENGL
I take it you meant 'OPENGL not OPENCL' and in the phrase
extemely low sample gathering with GPU in use, and GPU manages to do it faster
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.
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.
@Tamás Péter Radványi (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.
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.
