PhotonGI cache

Discussion related to the LuxCore functionality, implementations and API.
User avatar
Posts: 2371
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Speed without Cache

Post by Sharlybg » Tue Sep 08, 2020 10:10 am

There is good reasons why i'm still talking about that thing.

1__ It is good
2__ There is good interest from many artists to switch to Luxcore from big rendering names ( Redshift , Vray , Corona , E_cycles ...)
3__ Competition level increase With Eeevee now closing the gap to Cycles (Eeeve SSGI )
Cycles being boosted with E_cycles.
4__ Animation is becoming a standard like 4k resolution requiring more computation power.
5__ raytracing is going in the realtime direction ( as opposed to offline)
6__ Cache-less solution are compatible with PGI wich mean exponential speed up
7__ there Should be a Strong performance difference for someone to completelly switch to a new renderer ( Reshading hundreds assets / shader library )
8__ We can't rely on the super power of PGi everywhere ( all animation with motion light/object).


Dade already explain why it isn't worth the effort to implement something that can't benefit GPU acceleration (GPU is the present/futur of rendering). And i believe that too. So after some research i found something we already talk about during PGI development phase.

Adjoint-driven Russian roulette sampling


There is a paper about that : ... /index.htm
A video here :
And it should be compatible with GPU requirement ( we are not forced to add the path guiding component wich is in reality a seperate method)

If there is an issue with this one correct me please.
Support LuxCoreRender project with salts and bounties

Portfolio :

User avatar
Posts: 2371
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: PhotonGI cache

Post by Sharlybg » Tue Sep 08, 2020 11:17 am

A bit confused after in deph reading :|
Look like Adjoint driven russian roulette splitting == photon Gi cahe :?
Is that true or i'm again in the clouds :| :arrow:
Support LuxCoreRender project with salts and bounties

Portfolio :

User avatar
Posts: 1003
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland

Re: PhotonGI cache

Post by FarbigeWelt » Thu Sep 10, 2020 4:04 pm

Dade wrote:
Thu Sep 03, 2020 10:55 am
FarbigeWelt wrote:
Thu Sep 03, 2020 8:17 am
On nvidia‘s graphic transfer rate from RAM to VRAM is 14 GB/s. This is 32 times less than VRAM to GPU cache.
The slide is about CPU/SSD/etc. (any device attached to the PCIe bus) to GPU ram transfer rate. It can have a huge impact on some application.

In our case, it could highly increase the speed of "out of core" rendering.
In this case new SSD types like e.g.
Sabrant Rocket-4 could accelerate data transfers from large storage carriers to nvidia card‘s VRAM. I wonder if transfer rate could be increased of linked SSD if two of them are combined with RAID 0. The latter lead to about 14 GB/s.
How amazing if Textures, Mega polygons objects and generated pseudo Random number data streams found their way within fractions of a second to GPU caches/registers from deca+ cores CPU systems getting processed massive parallel on GPU shaders‘ units.

A nicely rendered 3D scene baked on its objects should impressively be real time. If there were any tricks to ray trace render moving or changing objects in the scene separately dependent on depth z and virtual z (bounced) computations could be saved and whole scene might be displayed UHD @ 60+ Hz, 10 bit.

Pre-rendered scenes combined with realtime active objects could lead soon to UHD games on average hardware based on soon common direct data transfer from fast storages or ram to vram (UHD games are actually what Microsoft and Sony claim for their next Gen consoles. At least Sony‘s memory concept for the PS5 on AMD silicon seems to point exactly in this direction.).
Light and Word designing Creator - - aka quantenkristall || #luxcorerender
Windows 10 Pro 64 || 2x16 Cores, AMD Ryzen 3950X @3.5GHz, 64 GB RAM, DDR4 @3.2 GHz
2x openCL, AMD Radeon RX 5700 XT, 8 GB VRAM || Gfp = SFFT Gflops

Post Reply