Brecht's easter egg surprise: Modernizing shading and rendering

GPU rendering for Fermi generation cards and 32bit systems will be disabled for 2.8.

While it may upset those who have held out on cards like the GTX 580, the reason for this move is the move of CUDA rendering to version 9. Nvidia made the decision that version 9 will not support some of the older cards, and even then there’s parts that will not work on 32bit machines.

To conclude, people might just need to take it as part of the reality of GPU rendering, the API updates likely make for easier GPGPU programming, but the ever shifting architectures mean full support does not last near as long as with CPU models.

As most people with sense have been saying, if you’re not doing research, don’t put your eggs into the GPU basket just yet.

Can’t they keep CUDA 8 and 9 side-by-side ?

Potentially… but there are also hacks that are specifically for sm2x devices. They want to also clean up the code base to get rid of these hacks.

The GTX 580 was released in 2010… 8 years of support isnt too shabby for a device. The other thing is, it was somewhat expected to happen with CUDA 9… as CUDA 8.5 specifically mentioned the devices were EoL

Should also mention that whilst it wont be supported… Cycles should still work via OpenCL

This stepping stone is now in Master

The log states that just with these commits, it is already possible to make some use of vector displacement maps with a bit of node work (even though we technically don’t yet have a node that you can just plug them into).

sure we have


That looks like an OSL script node (that green socket), that’s not going to fly with scenes making use of complex shading because you’ll get a huge speed penalty (when compared to SVM).

its not an OSL node the green socket just makes it easier to switch the orientation (integer input)

just tested the file, but it doesn’t work. 8(

Oh, guys… why don’t you wanna live and experience life? :wink:
Because it does, it works really well :yes:

Here’s a quickie, after 64 samples with motion blur & denoiser on…

Does anyone know if the devs mentioned anything to have tile sizes 16x16 on AMD cards going as fast as nVidias cards?

Brecht will soon move the adaptive displacement out of the experimental feature set (ie. it will be officially supported).

One of the remaining todo items here has already been done, the other is getting realtime updates in the rendered view and it looks like that will be in soon.

Remaining todo items include proper UV smoothing and issues with cracks, but those will take longer to resolve (even though Mai is already at work).

Please note that I plan to make only displacement fully supported now, for adaptive subdivision there is still a lot of work to be done.

We have ideas to make that work, but it’s not actively being worked on.

Thanks for the reply. You are doing an awesome job. I wish you all the best.

Cant we just use opensubdiv? I remember playing with adaptive subdiv even in their opengl example years back & we already support opensubdiv too a small extent.

We are using OpenSubdiv in Cycles.

Yeah I mean use open subdiv for the adaptive tessellation, If the adpative subdiv is already using open subdiv I had no idea.

This Video shows the feature adaptive tessellation and displacement, goto 12.00 in the video. You can change camera positions and still get great non poping adaptive subdiv, What would really make this worth adding especially for 2.8 is the fact it can run in opengl directly on the gpu too, For Eevee that would be a massive advantage.

I don’t really want to go into much detail on this, but generally:

  • Cycles tessellation probably has about the same amount of popping artifacts as that OpenSubdiv demo for a similar model, shader and dicing rate.
  • OpenSubdiv tesselation uses fixed function rasterization hardware on the GPU for adaptive tessellation in OpenGL/DirectX, which can’t be used for raytracing by Cycles.
  • Confusingly named, feature-adaptive subdivision is a method to handle irregular topology for Catmull-Clark subdivision, and we do use that in Cycles. But that’s not the same as camera adaptive tessellation.
  • Camera adaptive tessellation in Cycles works quite well, but as usual with this sort of thing it’s the integration with lots of other features that is the challenge. Instancing, motion blur, attributes, etc.

OK cool, yeah I didnt think about Instancing etc I can see how that would become a nightmare. Yeah I looked into tracing rays issues because the raterization pipe and remembered when looked through the code there was no way to pull a face ID or vertex ID to trace against because only existed on the GPU but also thought that had been worked on, Guess not then.

Would be cool if the great work you guys are doing could also be used to take advantage of the shader pipe in GL for Eevee to do this realtime in viewport like in that demo.

Ive been using your changes already from master on some terrain work , The tangent space support for normal maps was very cool, made my life alot easier.

Can be in future adaptive displacement on mesh work as single modificator? Or another way by which user can apply adaptive displacement on mesh