You have the limit method set to none which means every edge will be beveled. Turn on wire frame mode to see it.

Is there a way for a non-coder to diagnose this under Linux? I would like to help in any way I can.

I see it now, I was trying it on a mesh which has 90 degree intersections. Thank you for the clarification! In my mind I was thinking of another patch: D6386

Hi Howard, this might not be the right place to ask, but is there any difference between "Offset" and "Absolute"? Based on my initial test, (which maybe wrong) I don't see any visual difference between the two. Is there any specific case where one should use Offset over Absolute or vice-versa?

Should we make a separate bug report for this?

I can't seem to get this to work on Ubuntu 20.04, with a dual monitor setup and two Main windows of the same blender instance.

I have to disagree. I'm not requesting for modified/improved behavior. Just swap the sockets. This is clearly an aesthetic/layout issue. An "error"

With the D7574 fix, I no longer have this issue.

Successful renders with both F12 and viewport! Simply genius! Thank you!

@Aaron (amarshall) are you still experiencing this? If so, can you post your screen recording to T74262?

Can we also test on Ubuntu 20.04 LTS? I understand it's not currently supported by the driver, it's just so we have an apple-to-apple comparison.

Installing with dkms breaks my whole display stack, (Unable to login to desktop; black screen with blinking white underscore) which is understandable because neither Ubuntu 20.04 nor 19.10 is supported by the current driver, hence the --no-dkms

@Richard Antalik (ISS) I think the issue is exclusive to this particular setup, at least the GPU.

With the 2.90 builds (rB5cc7e2ae16d4) and an upgraded driver (amdgpu-pro-20.10-1048554-ubuntu-18.04) the render does not hang anymore for me, instead this happens now: T75895

Are you using the same GPU?

I've managed to recreate a scene that produces the crash on my system. Note that it's not specific to this material; any material I append or link from my external material library will produce a crash on render.

I'm using amdgpu-pro-19.50-967956-ubuntu-18.04

Tried out latest master, issue still persists when building with USD.

@Evan Wilson (EAW) @Brecht Van Lommel (brecht) I did try to build without USD (WITH_USD:BOOL=OFF) and GPU render works without issues. I'm convinced that USD is indeed the culprit.

Hi Brecht, is there anything else I could do to help at this point?

I agree it's a bit weird since there are no cycles-specific files edited in that commit, but I don't get the error when building with the commit before that. Or earlier. I'm only having problems after that specific commit. So maybe git bisect was on to something and this is something that could be looked at.

According to git bisect: ec62413f803ee506633f0e52d1e52b0980c0ed0d is the first bad commit.

should I mark commits that fail with Split kernel error: failed to load kernel_path_init bad or just the ones that hangs? The last time I tried to bisect, I marked those as good, git wasn't able to find the right commit.

Is there anything I could do to help?

It's working with 2.81, so there must be a problem with 2.83.

This fixed the error. Thanks for the quick fix Brecht! However now the render hangs indefinitely, without the black info bar at the top (the one that says how many samples are done, etc.) The render simply does not start, I don't know what to give you because there's no error out of the terminal or anything.

Fixed for me.

https://developer.blender.org/T74217 might be related. Recent build crashes when changing viewport shading to Material Preview or When render engine is set to Eevee, set viewport to Rendered View and under viewport shading properties, unchecking scene world crashes blender.

Happened to me with recent builds. Quite the headache.

I wish UI changes like this could be decided via a public poll, or at the very least, like everything else in blender - a customizable option. I liked the clear distinction between edit and object modes.

Added more info; the collection to be linked also has linked materials.

You should attach a log file instead of dumping the whole output here.

Update:
It seems the problem only occurs on a Wayland session. The continuous grab works flawlessly on a regular X session.

I've had a more stable experience passing AMD_DEBUG=nongg,nodma as environment variables and having iommu=pt pcie_aspm=off amdgpu.dc=1 amdgpu.gpu_recovery=1 as GRUB boot parameters. Some of the arguments might not be needed and I'm not sure which exactly does the job making it more stable, it might be any combination of these... Just updating in case someone else comes across this.

Yes, currently I'm using the latest version in your link (19.30) with slight modifications to the deb files for it work with Ubuntu 19.10.

@Philipp Oeser (lichtwerk) Yes, this is with Factory Settings.
@Jeroen Bakker (jbakker) I believe 19.0.8 is the latest for Ubuntu 19.04... Trying 19.3 using a PPA caused my Desktop to fall into a login loop.
No crash with --debug-gpu-force-workarounds too.

Issue is fixed for me with latest master. Perhaps it's something to do with all the recent bump-mapping related commits. Feel free to close this.

Thank you! That was fast!

This is weird. Could this be a driver problem then? I'm still having the same result on the release build and master. Let me know if I could provide more info to help identify the problem.
Thank you!

That maybe from a developer point of view, but for end users with no knowledge of the inner workings of Eevee nor OpenGL this seems counter-intuitive and confusing especially when one configuration works and the other doesn't despite it having a simpler configuration. With that said, of course any optimisation would be welcomed and greatly appreciated.

Hi guys, just want to know if this is still being worked on? I would really like to jump on the 2.80 wagon, but the lack of unit display makes modelling really hard at the moment.

Z scale is set to -1. Apply or clear scale, the modifier will work as expected.

I have the same issue with build 19-04-25 (905f2d84af4d). N or T does not work even after loading factory settings or changing keymaps (default, 2.79 or industry compatible).

Thank you for the clarification regarding unit scale, I come from an architectural background where specifying everything in mm is quite normal. Typing in 25 instead of 0.025 is faster and significantly less confusing. I mainly use 0.001 unit scale in 2.79, where that's the only option you have if one wants to use mm. I never imagined it would have an effect on precision.

Forgive me if this sounds ignorant, but it just seems weird having to have separate settings on the same scene with a different unit scale. Am I right in thinking that the underlying problem here is that lights don't use the unit system yet as mentioned by Brecht? And this goes away once it does?

This is a duplicate of T61286

Thank you! Hopefully this will get accepted soon.

Must enable units.