Can confirm this, same is true for Color and Power.

Apologies for the inactivity. I've been dealing with classes. Once 2.80 releases I'll make sure to get the backwards compatibility finished and address any remaining issues so it can make it into 2.81.

Nice idea :), not sure how to proceed with this though, I guess it would be better to post this to BA or rightclickselect or https://devtalk.blender.org/ first?
(Or possibly do a diff here? https://developer.blender.org/differential/diff/create/).

EDIT: Just uninstalled all the drivers for the GPUs and did two rounds of clean-ups using Guru3Ds DisplayDriverUninstaller in Safemode and things work again. Seemed to be an issue on my end, works again right now.

I have the same issue in Blender 2.8, 0fd96b4128ff
I have 4 GPUs installed but blender shows 8 GPUS.

The GPU usage in the performance monitor does not count the kind of GPU compute usage that Cycles does.

Sorry but I think I should have done a better job; Blender is not fully using the GPU in both versions and that’s why the CPU and GPU times are so close.
The reason I said it was is because I looked at the Nvidia icon in the taskbar tray that says it is but when I look at the performance monitor it only indicates 3% GPU usage on both 2.79 and 2.8.
The reason I have not picked up on this before is because I do not use this machine for rendering, I use my tower which has a GTX card.

Those render times are better in 2.80, so I see no bug then.

I used a basic cube without any materials or lighting effects to simplify the test, I checked that Blender is using the GPU during the tests, should we not be seeing better GPU times?

I can not reproduce this in 2.80, so it's probably safe to close (unless 2.79 bugs are still considered valid?)

When comparing render times, please attach a .blend file created in 2.79b. Then render that same .blend file in 2.79b and 2.80, and tell us the render time for CPU and GPU.

Not completely, I’m still getting an 18 second longer cycles render time with 2.8 when tested side by side against 2.79b.
It has improved dramatically though.

So it is fixed?

I’ve just downloaded and done a fresh 2.8 install and the same test recorded these results.

Is this still an issue?

I don't think any of the core devs is runing JACK. So it might take a while until this is looked on.

I remember this working in 2.79.

In D4971#113927, @Brecht Van Lommel (brecht) wrote:

It's possible to initialize the strength to 1 only if the color is black. See versioning_cycles.c, there's other code there that does this kind of versioning patches for nodes.

It's possible to initialize the strength to 1 only if the color is black. See versioning_cycles.c, there's other code there that does this kind of versioning patches for nodes.

In D4971#113806, @Alex Strand (astrand130) wrote:

In D4971#113787, @Carlo Andreacchio (candreacchio) wrote:

Can i suggest that the default values follow what the SubSurface inputs are? the emission strength would be 0 and the default emission colour be white (instead of the inverse?)

That might have been the ideal way to do it, unfortunately I'm afraid that could break older files that only use the emission Color, when the emission strength would default to 0 the material would lack emission. And since this feature seems to be coming post 2.80 that would probably be a much bigger deal then if that change was made during the beta.

In D4971#113787, @Carlo Andreacchio (candreacchio) wrote:

Can i suggest that the default values follow what the SubSurface inputs are? the emission strength would be 0 and the default emission colour be white (instead of the inverse?)

Can i suggest that the default values follow what the SubSurface inputs are? the emission strength would be 0 and the default emission colour be white (instead of the inverse?)

After some troubleshooting I just did a fresh installation of the blender source and applied the patches.

oops accidentally replaced the entire diff. (I don't know how to use git, sorry let me figure this out.)

Fixed hard-coded socket indices.

No, we don't make exceptions, we were already supposed to freeze in mid May.

In D4971#113581, @Brecht Van Lommel (brecht) wrote:

This is a good improvement, we can add it to 2.81.

This is a good improvement, we can add it to 2.81.

Edit: cycles socket for emission_strength default value has been updated to 1.0. (doesn't actually seem to have an effect but doing it just to be safe)

This is indeed a known limitation, we should improve the UI here once but for now it is require to have the same level for both.

As far as I can tell this is the subdivision surface modifier just being very slow. In the viewport it's disabled due to simplify settings.

This appears to be working now, probably after Sergey's latest depsgraph and mesh API changes.

This is an artificial setup, we are going to drop 32 bit support soon, it's not worth spending time on this.

I can't reproduce the issue in the latest builds. Closing due to lack of information to reproduce the issue, we can reopen the report if more information is provided.

You are using a 2.8 build from March, we are in May and a loot of things have changed since. Please try with the latest 2.8 build from here https://builder.blender.org/download/

We did a lot of fixes and changes in OpenCL kernel compilation. Assuming this is fixed now, I can reopen if it's not the case.

Please use the bug reporting template, and attach a .blend file to reproduce the problem.
https://developer.blender.org/maniphest/task/edit/form/1/