Why not just restart the viewport render? 
yes
or restart viewport render it helps)
but still it’s a bug)
bla bla bla bla bla
Now yes, but (sm_50) I had to rename and not copy. “kernel_sm_30.cubin”, “kernel_sm_35.cubin”, “kernel_sm_52.cubin” .It removed from the list sm_50
Blender 2.73a vs Blender_2.73_Win64_MSVC12_AS6_TM3_P1_CUDA
Edit: lighting (23.3% aprox faster).
I placed the new performance test into a closed box with to light portal openings, one circular opening on top, and a vertical wall cut out.
( i also changed the car paint shader a bit ), and had set AS to about 40%, i like the final end result. I noticed for the dark areas AS required more time then in other cases (i think). But i can imagine some noise here, as the cars are now in a ‘dark’ box with some openings, so eventually some ‘photons’ do hit the walls and those get rendered as a small pixel there.
But i wondered, light portals are “windows” from external light right ? ( i used some cloud picture as envirmont texture here)…
Because setting the emission strength seams to have no effect on them.
How does this influence other lights by theory ?,
should we avoid to use extra external lights with this ?
and how about internal lights ?
I just like to know better when to use it or when not to use it.
Are you having a discussion with your self about things already discussed on this thread? lol
Lord Odin at no time is said to remove sm_50, otherwise copy and paste rename sm_52. But if something interesting that is not disputed is the memory.
monkey
Blender 2.73a: 1004 mb
Blender_2.73_Win64_MSVC12_AS6_TM3_P1_CUDA : 412 mb
There is a 58% improvement in memory performance.
I want to know because the memory usage is so dramatic with other scenes, more amount of light equals the change can range from 60% to 10% of the use of ram.
These type of scenes are like night and day, best case scenarios.
INFO:
*Sponza 64 spp - CPU. Sun disabled, still buggy IMHO when there are other lamps other than portals. Hope Lukas might take a look.
Portal OFF
EDIT: using GPU and more samples (256), with portal is MUCH quicker to render while mantaining the big improvement in noise. It’s a huge boost on both side (noise and time), probably given by the very big single aperture covered by a single portal…(?)
*Sponza 256 spp - GPU
This looks really promising! I really hope that this goes further than “just” experimental 
uuuh, very, very nice, I hope soon this will be in trunk!
Interesting. What is the result if you just turn the portal into a bluish area lamp?
Wow, wow, wow. Thank you, Lukas!
Cool tests so far, thanks to everybody!
I just wanted to post a short update here: The next version is already nearly done, now with working non-background lights, portal objects, no issues when the portal touches a surface, MIS weighting for multiple portals etc.
Remaining is a problem in the MIS combination of background and portal sampling for the background pdf calculation, but that should be fixed quite soon.
Lucas i’m curious will this be part of metropolis too ?
As both of those projects seam to be focused on indoor lightning, and about speeding up blender.
No, there’s nothing common between them on the code level. Metro is about choosing random numbers more intelligently, while Portals are helping to map these numbers to ray directions more efficiently.
That’s the awesome thing about physically based renderers: You can have the best stuff in every area of the renderer and it all fits together 
I’d like to know when AS and Lightportals will get into main, even if both will be experimental
They’re the best blender improvements (having the most impact on my work) i’ve seen recenltly.
A sugestion maybe to create a diffferent lamp name for this, “window” or so, so it be more clear to users that his is not a ligh, but a portal/coridor for light.
Hi PGTART, AS is still under review so to late for 2.74.
The portal patch is not even in patch tracker so experimental atm…
@lukasstockner97, is it may a good idea to put portal patch in tracker? Or is it to early for it.
Cheers, mib
Hi Lukas,
Nice Patch, speed up is really impressive but Comparing your builds to the Buildbot or official ones on some scenes, your version is about 15% slower (same parameters). In My test cases, to get equivalent noise levels, I get a 20% speedup with your patch. So in the end, compared to official builds it’s only 5% better… I tried compiling myself on windows to see where it could come from and I had the exact same problem. It’s strange. COmpiling on Linux, it’s the opposite, self-compiled builds are 20% faster. Could a dev from the bf or someone who knows tell us how to get the same speed as the official builds? I post it here because it’s a shame a speed-up patch is given a slow build.
I’m not a developer but to me doesn’t makes sense and brings unneeded complexity. Exteriors should get sampled easily in any case since direct lit by the external environment, even if the portal is covering the windows.