I have two graphics cards, a RX580 for display and a Vega64 which was supposed to be just for rendering. Both cards were working with cycles in the beginning, though they were both called “Vega 64” in the rhino settings as render device.
Some time ago cycles aka raytraced viewport stopped working. It says “rendering” but the viewport stays in normal rendered mode, not cycles (doesn’t matter which of the GPUs I set as render device). After I had installed newer drivers like a month ago, the cards were called “Vega 64” and “Vega 36” under device settings and it still didn’t work. I just installed the latest drivers and now four devices are shown and still, raytraced does not work.
I tried the different devices in hope that one would work, but rhino crashes when I set the render device to one of the “Vega 36” devices. I did send in the bug report.
Hmm - since you installed new drivers Raytraced is going to build new kernels for your cards. That can take some time, so first time you switch you’ll have to be patient.
You can check inside the data folder for RhinoCycles under %APPDATA%\Mcneel\Rhinoceros\6.0 to see the kernels get created.
I suggest you pick only from the first two devices and wait for a good amount of time. I think you should see about 12 or so clbin files per card being generated.
I’m on the way back from https://events.mcneel.eu/rhino-helsinki/ but I’ll do a double-check tomorrow on my WX9100 to see everything still compiles as it should - I regularly use it still, so I’m pretty confident it does. But it doesn’t hurt to verify (:
Other than that I can’t readily see a reason why there are 4 entries instead of 2 - there are apparently two platforms found, but I don’t understand from the output why…
maybe the move from AMD driver package 18.xx to 19.xx had something to do with this?
indeed I was probably not patient enough. but now I’ve been waiting for like 20 minutes or so. taskmanager reports that rhino is actually doing stuff, quite high memory usage as well. but I know that when I used cycles the first time after I set up this system, building the kernels was way faster. I remember it did take some time but not anywhere as long as this now. something else seems to be wrong here.
I’ll try again tomorrow. maybe completely removing the driver with DDU (Display Driver Uninstaller) might help? should I delete the existing kernel files in the folder?
luckily the issue is not urgent atm. only some time next month I’ll actually need to use rendering again.
I would downgrade to the previous 18.xx driver yes. At least I am still on the 18.xx drivers. And possibly indeed a good idea to clean out the old kernels, just to be sure.
Let me know if rolling back works for you. @jeff do you know of any negative issues with the 19.xx drivers from AMD?
yesterday I deleted the kernel files, wiped the driver with DDU and then tried an even newer 19.xx driver. rhino settings was listing only two card then, like it should be. the crashes are gone. but the RX580 was still falsely called “Vega 36”. Also cycles would still not work.
Today I just downloaded an older 18.xx driver and installed it. no changes, still the RX580 is identified as “Vega 36” and still cycles does not work.
To me it does not look like it has anything to do with the driver. rhino won’t start actually building the kernels. iin the orange bottom bar of the viewport, the message “Loading render kernels…” appears for like three seconds and then it skipps directly to the message “Rendering…”. Somehow rhino just fails to actually start building the new and needed kernels. that’s what seems to be the problem here. at least that’s what it looks like.
I figured out why the Raytraced stopped working. I apparently missed two files when adding new bits and pieces required for Raytraced to compile with OpenCL. I’ll fix it ASAP in the installer as well, but for now you can copy the following two files in their correct locations. I have zipped them both, so extract them, then copy the files to their respective locations.
kernel_color.zip >> This contains the file kernel_color.h, which should be copied to the location C:\Program Files\Rhino 6\Plug-ins\RhinoCycles\source\kernel
util_types_ushort4.zip (>> This contains the file util_types_ushort4.h which should be copied to the location C:\Program Files\Rhino 6\Plug-ins\RhinoCycles\source\util
Let me know how this works for you. And yes, you need admin rights to copy to those locations…
I’m sorry for the inconvenience caused, I hope to have this in by the time the final SR12 goes out.
I hadn’t noticed this, since on my machine those files do exist
edit: and what comes to the naming of the devices - this is what Cycles gets from the AMD dnivers, so if it is the wrong name you probably have to complain to AMD about that.
edit2: I’ve created a PR that should go into the upcoming 6.12 release, follow the progress in the linked RH-50503 issue.
Great,
thanks for the quick solution! I’m glad it’s not some strange issue that only happens on my system.
Works with the two files now. Building the kernel for the Vega 64 takes about one minute, for the RX580 it takes nearly two minutes.
the wrong name is not an issue of course, just funny somehow. the RX580 is “polaris” not “vega”. but as long as I can tell them apart by the number it’s okay. I really hope amd sells more chips so they can put more resources into their driver departement.
something I noticed:
using both GPUs at the same time does not seem to speed up cycles like expected. here are some quick numbers from a simple scene, all at 100 samples:
vega 36: 00:00:50
vega 64: 00:00:25
both : 00:00:24
Since we are doing a progressive refine render in the viewport we cannot capitalize on the work-stealing mechanism that exists in Cycles. This means that with multi-device cases you’ll get speedups based on the slowest device. In your case the Vega 36 does 50s, and with the second device added the time is halfed. This is expected, although not wanted.
