May Cycles use SPIR-V for OpenCL rendering? If I understand correctly, it should speed-up the initialization of the render. It should also make it easier to make it work on a variety of different GPU’s.
Forgive me if I misunderstand, as I’m not a programmer.
Of course, this wouldn’t be much advantage until OpenCL 2.1 is more widely supported. Only newer Intel iGPU’s support it currently, AFAIK (on Linux, at-least). But Radeon support for OpenCL 2.1 should be in development now
I totally agree! Cycles/Blender unable to interpret certain vertex/point attributes is almost useless for studios. I´m running into those issues trying to render some dynamic topology coming from Houdini. trying to replace XSI and Redshift her. But this makes it impossible for now…
Also requested on rightclickselect, but this forum does not seem to be well administrated or reviewed properly.
Hey Brecht! What can be done to make this happen? Would be really crucial to get this working. Thanks 
Agree, support for reading custom point attributes in a shader should be considered an important point to increase interoperability between applications and wider Blender / Cycles adoption.
2 Likes
At the moment your options are to just ask here and right click select in the hope it gets prioritized, or contract a developer to implement it for you. For me personally there are other things higher on my priority list.
1 Like
Thanks Brecht! Sure, there things more urgent like bugs to fix and stuff. Keep up the great work.
The proposal is already on right click select and already far back in the list so nobody sees it…like many good ideas…
So, anybody here that would like to implement this?
How much work would it be?
cheers,
oliver
2 Likes
Is this maybe what you’re looking for?
1 Like
Might we please have antialiasing for baking, as well as displacement baking?
The lack of the first feature sticks out like a sore thumb for any kind of low poly asset production, while the lack of the second means there’s now no way to bake displacement in 2.8 since BI was removed.
3 Likes
I think cycles should move beyond OpenCL 1.2, and take advantage of newer OpenCL features. This includes shared virtual memory (in 2.0) & SPIR-V (in 2.1).
May these things please be added to the Cycles roadmap?
If the devs are willing to write a new code-path for newer OpenCL, they may consider using the OpenCL C++ kernel language if it would make it easier to write.
We don’t have an immediate use for shared virtual memory and SPIR-V, and none of the graphics cards we support have drivers with OpenCL C++ support. So no reason to add them to the roadmap at this point.
1 Like
@Platypus_with_boots I think you wanted to publish this in the “papercuts” thread, this is not related to cycles 
When you say “graphics cards we support” you must mean Nvidia and AMD. But why don’t you just add support for Intel iGPUs, at-least the ones that support newer OpenCL? I’m hoping that Intel iGPU’s would make hybrid rendering faster, especially with shared virtual memory.
If Blender starts to support OpenCL 2.1, then we can use it on Intel in the meantime, but then we’ll have progress by the time AMD supports it.
I’m not a programmer, so tell me if I’m wrong. But isn’t OpenCL 2.0+ more portable across hardware than 1.2, especially with SPIR-V?
I’d love this as well! Deep compositing solves so much!
It’s more of a general rendering request, since Eevee would also benefit from this.
OpenCL C++ and shared virtual memory are mostly convenience features that make code simpler to write, not to make it run faster. SPIR-V is mostly useful for people writing compilers.
If we have to maintain double code, any convenience is lost. None of these new features solve the reason why we don’t support Intel GPU’s currently, which is that it’s a lot of work for us to support another platform which will only give minor speedups over CPU rendering.
2 Likes
when can we expect Intel Open Image Denoicer for cycles 
2 Likes
One thing that every denoiser is prone to do is slaughter the subtleties of reflections with varying roughness and color. I’d personally love for a roughness pass, and denoiser algorithms that take that roughness pass into account
I woudl like to request a render-time Boolean shader much like the VRay Clipper as demonstrated here: https://www.youtube.com/watch?v=DLRzW6ixopI
This can also be animated for cross-cut reveals that can cap geometry and shade the caps in the object material / texture.
7 Likes
Progressive rendering with F12 is really slow compared to bucket.
But it would be nice to see the whole rendering shortly after pressing F12.
I’m not sure, but maybe it’s not easy to fix at all.
Implementing cycles viewport IPR into F12 is probably not easy because of denoising.
In this case, one could render the image with maybe 32 samples and then rerender it again and again to merge the samples from the buckets until a certain amount of loops/passes is rendered.
For example: 32(Samples) x 16(passes) = 512 samples in total
Arnold render and Renderman do it like that i think.
1 Like
I posted a proposal some times ago on rightclickselect asking exactly for this! (If I find it I’ll link it here)
1 Like