Almost the same exept 2 million polys. Render time roughly the same as before. Still don’t understand what does memory bandwith have to do with how fast the path tracing is.
If you were right then the render times using Redshift with the same scene without the statues would be similar. But here is my times with Redshift 2.6.32 demo:
GTX 1060 - 3:36
RTX 2060 - 2:23
Almost the same? The peak memory usage in that render is 461.69mb
Your original demo from the first post shows 38.03mb…
I meant to be a joke, just my english 
. As you can see there’s something bad here.
So I report the bug tomorrow. But if someone can better explain in english, then go for it, because I know my english is fuzzy.
I was about to buy an ngreedia rtx 2070 but fortunately i change my mind since amd hire a programmer to get opencl correctly implemented. Now i am just waiting for a good amd card that will probably be only available in fall.
I’m just not seeing it. 
You rendered an image with a peak memory of 38.03mb in 7 minutes. You then rendered a scene with a peak memory of 461.69mb in the same amount of time using the same card. That shows the original demo scene was not enough of a stress test to get a proper read, and that the 2060 can handle a much larger bandwidth.
But it’s all good. You do what you want.
I just tried to prove you were wrong. By the way the peak memory usage of the BMW scene is 144MB.
If you were right, I would get similar results with the same scene in Redshift. But that was not the case, see my previous reply above with the render times.
Then why is that if you were right? Does Redshift handle something that wrong that the render times will be better?
I’m not going to talk about Redshift because I’ve never used it and am unfamiliar with it. However, none of that changes the original point I tried to make at the beginning of this thread; That your original demo scene is NOT a good test subject.
It’s the only scene in which you are getting inconsistent results. All of the (proper) benchmark scenes are consistently showing faster times with the 2060 vs the 1060. I even said previously that you could be right about a potential issue with the card, so it’s not like I’m just trying to prove you wrong. I’m just saying that you need to base your finding on a proper benchmark and ditch your demo scene.
@robertbrian I gave your scene a try on RTX 2080.
Blender 2.80 (fresh build): 5:37
Blender 2.79b: 2:14
Blender 2.79b (LuxCoreRender 2.2 alpha): 0:57
There is something fishy going on with 2.80, report this, maybe we will get some answers.
I agree that memory bandwidth impact should be accounted for in the expected speedup. Looking at FLOPS (pure floating-point computation), the 2060 is only about 35% faster than the 1060.
Also, Cycles often initially performs worse with new major CUDA SDK releases (required for new GPUs) and then gets better over time.
No.
Path tracing uses memory to store geometry, obviously. If your scene has very little geometry, a lot of that will end up in fast on-chip caches, so memory bandwidth becomes less relevant.
You’re comparing apples and oranges. Unlike Cycles, Redshift uses light caches which also occupy memory. Memory bandwidth becomes more important.
Also unlike Cycles, most renderers these days don’t use unikernels anymore, which also leads to higher bandwidth usage.
Nightly ( buildbot), right? Not 2.79b.
You know what? It’s 2.79b straight from the website (Linux version).
What’s going on here? It shouldn’t work 
Edit: Could it be that mighty Arch is resolving dependencies in such manner that it can work? It’s “portable” version of Blender, not from AUR repo.
That’s what I was wondering about 
Strange things are happening…
Edit: Will have to try, going to setup Arch tomorrow.
First of all, try Antergos. Amazing distro after some fiddling, but if you are gonna try Arch it’s not something you wouldn’t do anyway 
Secondly, I tought that I’ve broke the rendering laws with this test, but BMW scene is 1:47 in 2.79b and 1:05 in 2.80 
Still…
No, no Antergos for me. It’s not my first time on Arch. I just switched during my time on VEGA 64. That’s history now
I didn’t say very well. I meant there is not so much going on, therefore all render engines with unbiased mode can handle things similar.
I used Redshift in unbiased way. The difference that Redshift can’t produce reflective caustics in progressive mode.
Tonight I make a test a much bigger scene and I’ll try some more things. I’ll keep you posted.
I made a new scene from scratch based on the previous one. I’m still confused what might be the problem with a such simple scene. I didn’t use anything from earlier. All properties are the same: samples, max bounces…etc.
And look at those crazy render time: 16:08. And maybe it’s not just RTX related.
Scene download: https://ufile.io/vvw6b
Edit: the scene was fixed and reuploaded again according zanzio’s remark.
I gave your scene a try on my GTX1050:
GPU only 14:32
GPU&CPU 9:57
System: Linux Mint 19.1 and newest 2.8
Progressive refine is horribly slow and pointless for 99% of situations lol
Sadly it’s not related, but I fixed it and reupload again.
blulog: Thank you.
LordOdin: For final render it is not as good, but for preview it’s very useful.
