Hi, Does anybody have a Macbook pro 13” w/ Intel Iris 640 and is experiencing problems? Every time I use any 3d object node, screen gets full of lines and glitches. This has been reported as a bug like a month and half ago and I was hoping that the next (1.2.7) update would fix this. It didn’t so I’d like to know if in the meantime anybody else purchased the same computer and is having the same issues just to isolate the problem and be 100% sure it is the graphic driver related problem? I’m on 10.13 with the latest updates. Thanks for any help!
@kokot, one other thing you could check beyond what we already discussed — does the problem happen in earlier versions before Vuo 1.2.6? I don’t know if going back to an earlier version would be a viable solution for you, but if one works it might point us to a better fix.
Hi @jstrecker, thanks for the answer. I’ve tried on 1.2.5, 1.2.4, 1.2.3 and its the same thing, crashes right away. Did you guys get the chance to try it in this gpu already? In november I was Vjing on my friend’s laptop and it was the previous line Intel Iris 540. There was no problem on that one, so maybe it’s something specific about the 6XX line?
The closest we have available to test on is an Intel Iris Pro 5200, and that does not exhibit the problem in macOS 10.13.
Anyone else have an Intel Iris Plus 640? Do 3D object nodes such as Spike 3D Object, Divide 3D Object, and Add Noise to 3D Object work correctly for you on macOS 10.13? What about other macOS versions?
@kokot, you asked if this would be fixed in Vuo 2.0. Sorry, no, the fix will require extensive changes and we’re not able to fit this into 2.0. We still plan to fix it in a later release.
Here is the status of the bug and our understanding of it:
Symptoms: 3D object filter nodes (including Add Noise, Explode, Trim) give incorrect output on certain GPU-macOS combinations, including your Intel Iris 640 on macOS 10.13.
Cause: Some GPU drivers don’t support the GPU-based technique that Vuo uses for 3D object filters (OpenGL transform feedback).
Solution: Provide an alternative (slower) CPU-based implementation. Or there’s a chance it will be fixed when we upgrade Vuo from OpenGL to Metal.
Have you (or anyone) tested the Intel Iris 640 on macOS 10.12 or earlier? There’s a chance that the bug might not occur on older macOS versions, so that might be a workaround. Vuo 2.0 will support back to macOS 10.10.
@jstrecker, thanks for your reply. I didnt test it on 10.12. We talked about it last year, I was trying to downgrade but was not able to. From what I found on apple site the new ssd drives come APFS formatted or something and it just didn’t let me downgrade if I remember correctly.
Anyway, I have seen that similar bug was reported for Iris Plus Graphics 650. Does it mean all the Intel Iris line gpus (640-upward) would be affected by this?
Just have seen that 15 inch laptops use Radeon Pro 555X. Would these work fine? I mean is it a specific gpu problem or something in the code of apple drivers? (I am no expert on this topic, so just asking)
Maybe,getting an 15 inch I would be ok?
Thanks!
The problems that we’ve seen generally occur for certain combinations of GPU hardware and macOS version. That probably means they’re bugs in Apple’s driver code.
When two closely related GPUs use the same driver, such as the Intel Iris 640 and 650, it’s likely that a problem seen for one GPU will also show up for the other.
However, sometimes more distantly related GPUs share the same driver, and not all manifest the same problems. For example, we think that the AMD Radeon Pro 555X uses a driver called AMDRadeonX4000GLDriver — which is also used by the AMD Radeon R9 M370X, the AMD FirePro D500, and the AMD Radeon 7970. The FirePro D500 and Radeon 7970 both have known issues. Yet my coworker is using a Radeon R9 M370X on macOS 10.14 and Vuo’s graphics all work fine for him.
So that’s why we always say, if you’re thinking of buying some hardware, it’s best if you can test Vuo on the system configuration before buying.
@jstrecker, thanks for clearing it up. yes, to try the hardware before getting it would be probably the best option.
Anyway, I think i will just wait for the future fix. Hopefully implementing Metal will fix. Thanks!
Had a MPB 13" 2018 Intel 650 macOS 10.14.3 in the hands and ran some tests too.
• Basic load 3D models works. The Tile Starfield example composition for example is fine.
• Sample comps that produced glitches : Dent Room (displace 3D object with image node I guess), Pinch Rectangles, Pinch Sphere, Rewind Checkerboard Explosion.
• Comps that outputted black compositions screen : Divide 3D sphere, Facet Sphere
Quite astonished to read that the only fixes for openGL would be to run in on the CPU instead ! Really ? No other methods ? Amazing. I guess the team also has to keep in mind all the other maybe-related sub-bugs they fixed in the past like for the Add Noise to 3D objects etc. A bug fix for this should not break the already fixed bugs. However I remember some of the bugs were fixed to work on older GPU’s like the Intel HD 3000? if a choice had to be made I guess recent GPU support would be better than older ones though ?
Anyway, one question, before moving Vuo completely to Molten / Vulkan / Metal which I assume will be some work, would it not be possible to test it out for small fixes like these first ? I mean to still have OpenGL but start using Vulkan in parallel only for some nodes like these ? Just a non-coder question.
(For some of the Intel HDxxxx fixes, I think the solution was to disable the feature with those cards, and just make it default to whatever worked without crashing)
Quite astonished to read that the only fixes for openGL would be to run in on the CPU instead ! Really ? No other methods ?
Since Apple’s OpenGL drivers are deprecated (so they’re not going to fix them) and closed-source (so we can’t fix them) — no, not really. At least, nothing that would be less work than updating to Metal.
Anyway, one question, before moving Vuo completely to Molten / Vulkan / Metal which I assume will be some work, would it not be possible to test it out for small fixes like these first ?
Not in this case. Meshes are one of those things that you have to do either entirely in OpenGL or entirely in Metal. You can’t do a little bit in Metal to work around the problem and keep the rest of the code OpenGL.