Hi, I have build yesterday by myself and have no Optix card in settings, RTX 2060 on board, but Cuda is working.
The buildbot for CyclesX branch is set to daily build now so it should build tonight again.
I guess we have to wait a bit for the next working builds, it is still experimental.
Cheers, mib
EDIT: @SteffenD, ah, will check again.
This might be fixed as of https://developer.blender.org/rB54e91c8df8cfc0157b4eb7b66ff612608880b132
1080 cuda and here no problem with this build.
Edit: Sorry, only now I notice its using my Ryzen 
@rafael_design @SteffenD @mib2berlin @vangel @JohnDow and others, the issue with the GPU not being recognized from Blender builds downloaded from the build bot is currently being investigated and will probably be fixed soon.
As I can see there is a new build available (May 19, 02:54:24), but the problem is still there. Judging by reports that I’ve seen, all new builds that have ‘amd64-release’ at the end have this problem.
Tried also 2.93b (aa06be9148a) and 3.0a (019ab774d4c4) with ‘amd64-release’ postfix and they both have the same problem.
UPDATE: Tried yet another build (May 19, 05:38:07) with '‘amd64-release’ at the end. The issue still there.
For last build x.e54 for blender report that it is not find compartible GPU
Win 10
Nvidia latest drivers
gtx 1070
Latest Blender-X builds 18.05.2021 and 19.05.2021 don’t recognize my GPU – no CUDA and no Optix. The builds before worked flawlessly.
Windows 10
Latest Nvidia Game Ready or Studio Drivers (both tested), Cuda 10.2 and 11.3 tested and Optix 7.3
Ryzen 3900X + GTX 1060
Hello! The lastest cycles-x version from experimental downloads (May 19) is working for me, I don’t know if it’s the same case, but in my case it looked like blender was failing to compile the cubin at render time. I fixed it adding the cl.exe compiler from MS VisualStudio to the the system PATH env variable. I have both CUDA 11.1 and 10.2 installed, so I made sure they are both in the CUDA PATH env variables. After that it worked.
I had a similar issue and it seems that the most recent version now works for me as expected.
May 19 Cycles X release works fine on me.Its 2-3 seconds even faster. I didnt notice any issues for the time being
Looks like the just released OIDN 1.4 will already gives much better detail preservation without any tweaking: https://twitter.com/attila_afra/status/1395167038465773571/photo/1
Edit: better detail when using pre-filtering
Rendering slower is probably caused by this patch https://developer.blender.org/rB17774afed1a3f17f32eddef48155c6ed65e03099
It is noted that the change can lead to a small performance increase or decrease depending on scene.
As for the viewport being faster, that’s caused primarily by this patch https://developer.blender.org/rB3336bc6af66a1b9f0e15d6816aa59f3880d4ae44
If anyone has example .blend files where OpenImageDenoise is poor at maintaining detail compared to NLM, it would be useful to post them for testing OpenImageDenoise 1.4 and the new parameters it provides.
The comparison image looks promising, but results at low samples are not necessarily indicative of what happens at high samples.
This is amazing. Implement 1.4 as fast as possible into the Cycles-X branch please. Let us test it in the field. The prefiltering can also be computed by GPU?
And how can we know what OIDN version is currently in use by blender branches?
1.4 pre filter looks amazing!
Current version of ODN for blender is 1.3.0, you can keep an any on this ticket for any movement in library updates for 3.0
It is impressive that with so little render samples it preserves so much detail in the texture.
What does that pre-filtering mean? Will we have new GUI options for OIDN 1.4? Or is it transparent to the end user?
Afaik it takes the albedo tex and normal buffer for pre filtering,to keep the albedo texture details.
(read on BA post)
OpenImageDenoise 1.3 assumes that the albedo and normal passes might contain noise (for example from motion blur or depth of field). That means it can misidentify texture detail as noise and blur it out.
With 1.4 you can denoise the albedo and normal passes through prefiltering, and then denoise the final image assuming those passes are noise free. Of course prefiltering could also misidentify texture detail as noise, so you could still lose texture detail. But I guess they found the prefiltering to be better at this. We’ll have to see how well it works.
Potentially we can also use the variance of the albedo and normal to influence the prefiltering. In areas without motion blur and depth of field where we are confident there is no noise, we could disable or reduce the influence of prefiltering.
