I have another workaround, which actually makes sddm-greeter work again. I had my doubts so I went to confirm my assumptions. You can skip my detective work and rambling by going under the asterisk line.

And it is true that both programs which JohnDoe_71Rus (johndoe99) mentions have similar issues. I haven't looked at glxinfo till now and just now found that pages at unix.stackexchange.com cause tabs crashes with the RIP CODE message in dmesg. But only if I reach to the end of the web page. Strange behavior. Disabling hardware acceleration does not solve the problem.

I mentioned previously that viewing video files was no problem and I tried 'mpv' from the terminal and it uses the gpu driver and works fine, except that it crashes when the video ends with a seg fault. Which is probably why I did not notice the problem when using SMPlayer as the GUI.
Using the vo=xv driver causes no error when finishing the 

I suppose that I was just lucky that most webs I visits don't require the magic 3d that makes certain pages crash firefox tabs.

Still sddm-greeter should not fail so catastrophically when it does nothing so complex that requires the gpu's shadow magic. Without terminal-fu level skills most users wont be able to maneuver through the issue. And blindly will blame it on Linux being "unusable".

Some level of fault tolerance is needed but hardware issues are difficult to plan around.

But again: Why sddm-greeter uses gpu's magic?

Dependencies perhaps? Is it Qt5 indirect fault?

Running gdb on sddm on runlevel 2 with no X and the segfault appeared in  :
QMessageLogger::fatal(char const*, ...) const () from /lib/x86_64-linux-gnu/libQt5Core.so.5

There is no RIP Code message in dmesg. So I was not convinced.

strace was not helpfull either.

So I gave up on finding the exact culprit. Short of recompiling sddm, qt5 and mesa and debugging them in tandem. Unfortunately I don't have the time.

*********************************************

First: I'm using Lubuntu 20.04, newer *buntu versions I have no idea of their status/compatibility/versioning/etc. This only applies to 20.04.

So I tracked down the main mesa libraries and downgraded them all to the previous version.

#apt install libglapi-mesa=20.0.4-2ubuntu1 libglx-mesa0=20.0.4-2ubuntu1 libgl1-mesa-dri=20.0.4-2ubuntu1 libegl-mesa0=20.0.4-2ubuntu1 libgbm1=20.0.4-2ubuntu1

So then with dpkg-reconfigure sddm-greeter I selected it again as the display manager.

Went to runlevel 5 and presto IT WORKS. Firefox tabs do not crash anymore on unix.stackexchange.com and mpv on the command line using the gpu driver does not segfaults anymore on exit.

So I can confirm without doubt that the main culprit as JohnDoe_71Rus said, is in the mesa libraries upgrade. But I can't confirm the exact code/library where the problem is located.

Surprisingly i did not have any dependencies issues when downgrading this libraries. Other people experience might differ due to the uniqueness of their systems.

To prevent apt from upgrading this packages again;

#apt-mark hold libglapi-mesa=20.0.4-2ubuntu1 libglx-mesa0=20.0.4-2ubuntu1 libgl1-mesa-dri=20.0.4-2ubuntu1 libegl-mesa0=20.0.4-2ubuntu1 libgbm1=20.0.4-2ubuntu1

When the patched update to the mesa bug comes just use "apt-mark unhold" with the same list.

This workaround/solution by downgrading might break some stuff and might not be future proof.
So far on my own testing everything works.

The changelog for mesa: https://launchpad.net/ubuntu/focal/+source/mesa/+changelog
does not seem that impressive, so unless there is a change in your hardware there should be no impact on your system. But I can't give any guaranties. 


Most of the changelog is ppc64 fixes and the big upgrade: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1908699


I hope this helps others.