It appears that AMD is consistent with their contributions to open things. Couple that with typically lower prices for comparable GPUs it makes me sad to see that 30/70 percentage (of red to green) on e.g. Steam.
Green yet seems to employ every semi- or outright unfair strategy (gameworks, extra tesselation) to stump them while still being typically 'closed' in its ways.
It's the same for both Nvidia and Intel: I dislike the companies for the reasons you mentioned, but they do make superior products compared to AMD.
In Nvidia's case, they're a step ahead with the technology and they also put more effort into efficient cooling, which is nice if you value your ears, and evergy saving. They also seem to be constantly first with new software features (automatic game settings, recording, streaming, ...).
AMD, with both CPUs and GPUs, offer comparable speed at lower prices, but not a comparable product. If they did, I'd drop Intel/Nvidia in a heartbeat.
Hopefully, Polaris and Zen are going to be massive improvements.
But even current cards like the Fury look fine, especially if you consider DX12 and Vulkan performance. nVidia just spent a lot of money on optimizing the drivers for DX11.
About recording & streaming — that's not just a software feature, that's dedicated video encoding hardware on the cards. nVidia heavily pushed their own software that uses the hardware, but AMD were the first with the hardware itself, according to Wikipedia:
> Video Coding Engine was introduced with the Radeon HD 7900 on 22 December 2011
> [NVENC] was introduced with the Kepler-based GeForce 600 series in March 2012
In general Nvidia makes a superior product, but it really depends what you are talking about [1]. The new Nvidia 980Ti has the best power/price at the moment. However, AMD is increasing power efficiency and being competitive, competitive enough that I buy their GPUs because they work (or did) better with Linux.
With the new GPUs I anticipate them being even more competitive if not outright better for the power/price and power useage.
I see in the docs that it supports Embree as a back end. Embree is intels library for doing the exact same thing (as far as I understand). So it feels odd to use embree as a back end for this, I'd use this instead of Embree, not both. Can anyone explain?
A guess would be so that you can compare the current best open ray tracing library on the CPU with their GPU implementation as well as switching to CPU ray tracing under the same API.
Because they're open-sourcing an existing library?
To answer the larger question of "why create a new library instead of contributing to open-source project X instead", the answer is that working on other peoples' open-source projects (if you're actually going to improve them rather than just throw more me-too mud at the wall) usually consists of cleaning up other peoples' messes. You're at the mercy of a third party maintainer, you're stuck with someone else's (probably terrible) design decisions, and you're dealing with a list of existing bugs and defects.
I can't speak for everyone but just personally, if I'm doing a job like that, it's because I'm being paid for it.
Because Cycles is a rendering engine, while FireRays is a ray intersection acceleration library. Cycles could opt to use FireRays for ray intersection if they wanted to, but most uses of FireRays probably could never use Cycles since need a rendering engine with entirely different capabilities (real-time &c.)
I mostly work on closed-source software. If they contributed to Blender, I would never be able to use that FireRays because GPL.
Instead, AMD released FireRays under permissive license, so I can pick the technology for a next project if I see fit.
BTW I have good experience using libraries by AMD, such as SSEPlus (Apache license).
Depending on what you want to render, and what kind of look you are after. Blender cylces can be the worst of raytracers. I'd be more interested in a general ray-hitting lib, less then a raytracer.
Green yet seems to employ every semi- or outright unfair strategy (gameworks, extra tesselation) to stump them while still being typically 'closed' in its ways.