This fix does work. See attached bug report for detail.

In T57752#662773, @Lawrence Teng (Lteng) wrote:

blender-2.80.10-26.zip118 MBDownload

It is a big file. Hope I"m allowed to attach it here...

It is a big file. Hope I"m allowed to attach it here...

In T57752#662365, @Lawrence Teng (Lteng) wrote:

Yeah it is sort of an attempt to "tame" the specularity. It's a little bit different from turning spec off completely. I had it set to zero to just show the effect, but it does need to be set close to it. Anyway this is not really a "fix", just me trying to cheat and attempt some workarounds until the issue really gets addressed. I did find in the end that this cheat only works for certain lighting situations....oh well.

Yeah it is sort of an attempt to "tame" the specularity. It's a little bit different from turning spec off completely. I had it set to zero to just show the effect, but it does need to be set close to it. Anyway this is not really a "fix", just me trying to cheat and attempt some workarounds until the issue really gets addressed. I did find in the end that this cheat only works for certain lighting situations....oh well.

In T57752#649626, @Lawrence Teng (Lteng) wrote:

I tried a few things as a makeshift workaround and found that plugging the layerweight node in the specular of the principled shader provides a bit of a "relief" even if not too perfect. It sort of temporarily "covers" up the blown out bleed through, at least until the bug gets sorted out eventually. Have not tried this on more complex geometry / scenes and I don't know if this will drastically affect specular highlights in general,, but I suppose Eevee is not really for super-realistic renders so may be able to get away with this for now.

I"m attaching a screen cap of it here:

Maybe I did something really stupid, but I couldn't apply the patch to the recent master, and neither could I figure out what was the last commit this patch would work on, so I manually (and a bit painfully) introduced the changes and managed to make it build after fixing a few implicit conversions which appear to be disallowed by the compiler options (taking warnings as errors, I think).

Can confirm, asserts not getting the DRW_UNIFORM_TEXTURE_REF

This seems to be on purpose [dont know the reason for this though...]

Excuse my noobishness, did I get right that this diff didn't get committed as of yet? When can we expect it if so?
Thanks

Can confirm, will have a quick look...

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

Confirmed, will have a look...

yes, I have checked on my side. That workaround is working in 009dbc2bc9fb . Thanks for pointing out.

i edited OP a day or two ago with a workaround. check if PV works when you remove the word "density" on 4th input "Density Attribute". @Ahmad Bilal (SomeAB)

Just so it is helpful to track the cause, I'm reposting the version details I posted in the other thread (T63468).

In T63424#657577, @Sebastian Parborg (zeddb) wrote:

The issue here is not with curve objects, you can convert the curve object to mesh and the issue is still present.

I'm getting a lot of depsgraph asserts when going into the material tab. (But I'm unsure if they are related or not)

BLI_assert failed: /home/zed/prog/blender/source/blender/depsgraph/intern/depsgraph.cc:124, add_id_node(), at '(id->tag & LIB_TAG_COPIED_ON_WRITE) == 0'

I'm guessing this is a depsgraph issue.

Oh this is just a temporary workaround (at least for me in some situations) to address the bleeding back light. Right now some lighting scenarios in Eevee with backlight and SSS shader will leak in backlight and fail to cast shadows. It seems to be a complicated kind of bug and may take a bit longer to fix.

After another testing with various settings I found another interesting thing. Somehow, when I set Render > Display Mode > Keep User Interface and using minimum layout (3D viewport, shader editor, and Outliner) EEVEE rendering perfectly fine (in ordinary setting it keeps crashing before 50 frames). I haven't tried this method with Cycles though.

Closing due to lack of information to investigate the issue, we can reopen the report if all the required information is provided.

Your GPU is sadly EOL (end of life) and will not receive any more updates. So this driver bug you are experiencing will never be solved.
I don't know if there is much we can do on our side.

In T63377#656906, @why is this required (Tysa) wrote:

sorry @LazyDodo (LazyDodo) , first time posting. i updated the main post aswell with everything we figured out so far, hope thats okay.