Hacker News Reader

Comment by hellking4u | Hacker News Reader

This is great, but I have to say, I'm a bit concerned about multiple Intel tools (Embree, OpenImageDenoise) that are now integrated into Blender. The tools seem to depend on Intel MKL, which has famously been crippled on non Intel CPUs.

The big concern, for me, is the wide usage of Blender in common CPU benchmarks, which potentially could give Intel an unfair advantage in those.

View on HN

Embree doesn't use MKL, and in fact, the code runs very well on AMD machines, as can be seen by any recent Cinebench version benchmark (of which AMD themselves often show the result) which utilises Embree for intersection.

What will be interesting is other architecture support entirely (ARM) possibly being added to it by contributors. I doubt it will happen, but Intel did accept patches for TBB for ARM and POWERPC, so it's technically possibly...

AMD can contribute their own tooling if they feel it's worth it. They aren't broke.

AMD helped pay for the development of the OpenCL backend for cycles. Before that cycles gpu support was limited to CUDA. They actually hired a developer to work on it full time.

As a user of blender on AMD GPUs, they should probably put a little more effort in. Many of the shaders used to render scenes in cycles from 2.82 onward crash, and therefore make it impossible to use an AMD GPU to run cycles.

I'm surprised they don't push their ProRender renderer into the main release. I can't tell if I like it or not

I tried to play with ProRender a while ago, because we had a few people working in Blender who had to suffer with lousy performance on Cycles on our iMacs, but because ProRender requires a bunch of different settings, our artists would have had to migrate existing projects, as well as (potentially) their workflow, to what ProRender supports.

I couldn't tell if that was "everything, but differently" or "most things, occasionally", or some other venn diagram of confusion, and they didn't have time to figure it out because they were busy doing actual work, so we just ended up paying some company that apparently has massive render cluster that you can rent out for basically pennies.

The most common reasons for crashes are outdated graphics drivers with bugs and/or hardware below the minimum requirements [1]. If you think you've found a bug in Blender please report your issue on the bug tracker [2] (Help > Report a Bug in Blender).

[1] https://www.blender.org/download/requirements/ [2] https://developer.blender.org/

Indeed I have actually tracked and posted a few bug reports on the blender forums. I'm running an AMD 5700XT and an R5 3600 so I sure hope my configuration is supported! My only concession is that I had to download the "optional" driver for august in order to get Microsoft Flight Simulator 2020 support.

Thank you for reporting bugs and helping improve Blender! Every AMD graphics card that is GCN first generation or later can be used for running Blender [1]. GCN second generation or later is required for GPU rendering [2]. Unfortunately the AMD Radeon RX 5700 XT does seems to be affected by some technical issues, that are still under investigation. Might be a bug in Blender or an issue with particular OS, hardware and driver combinations. See ticket T75319 for updates on this problem.

[1] https://www.blender.org/download/requirements/ [2] https://docs.blender.org/manual/en/latest/render/cycles/gpu_... [3] https://developer.blender.org/T75319

I fail to understand what your point is.

Or, rather, I sincerely hope you are not suggesting that the deliberate crippling of compiled code on competitor cpu is solvable by "just make your own compiler"

That would suggest a fundamental lack of understanding regarding the whole issue to begin with.

Perhaps instead you are suggesting that if AMD doesn't wish for its users to suffer poor performance due to said issue, they should provide an alternative implementation of any library compiled with ICC?

Surely that cannot be what you mean? That would be absolutely ridiculous.

Neither Embree nor OpenImageDenoise use MKL. OpenImageDenoise does use a fork of mkl-dnn, now called one-dnn, but it has nothing to do with MKL.

From the oneDNN documentation[1]: > The library is optimized for Intel Architecture Processors, Intel Processor Graphics and Xe architecture-based Graphics.

Now, whether "optimized" means tuned for Intel architecture, or crippled for other architecture, is something to be figured out. Given the precedent set by MKL, I wouldn't trust it to be the 'tuned' option. Someone who speaks C++ may be able to better discern if such concerns exist with one-dnn.

[1] https://github.com/oneapi-src/oneDNN

Full disclosure, I work with the team behind Embree and OIDN. I've never personally worked with oneDNN. I'll just say that we test our code on Intel CPUs (obviously) and therefore optimize performance based on those tests. We don't have AMD CPUs readily available to test with (as you might imagine).

However, since all the code is open source, third parties often do benchmarks across platforms. Michael Larabel from Phoronix does a really good job of this.

https://openbenchmarking.org/test/pts/onednn

> We don't have AMD CPUs readily available to test with (as you might imagine).

I mean, it makes perfect sense to me that Intel would only care about optimizing (or even supporting) their software on Intel chips, but I'm sort of surprised that you don't have AMD systems to test on just to compare performance.

Wouldn't it be something that you (or management, or whoever) would want to know if you were about to release a version that had much worse performance on AMD systems because of a regression ("Intel is intentionally crippling AMD CPUs!") or much better performance ("Intel released a new update but it runs better on AMD at half the price lol")?

If it's a small team then you may not have the budget (or want to spend it on that), but surely it would be nice to know either way?

Thank you for replying. This assuages my concerns behind Embree and OIDN.

I guess I just get suspicious whenever I see MKL mentioned.

But you're the one that first mentioned MKL. You made yourself suspicious.

Reply on news.ycombinator.com