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.
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
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).
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).
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).
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.
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.
