Tech companies rarely draw the line between competitor and collaborator. Intel demonstrated that duality on September 4 when it updated the open source SVT-VP9 encoder with optimizations for AMD's EPYC processors, along with other AVX2 CPUs, which debuted in 2011.
Those optimizations were made in an update pushed by an Intel engineer, Jing Li, who titled it "Fix the perf gap for Epyc CPU." But that didn't tell the whole story: Phoronix reported on Sunday that the update was "easily the largest speed-up we've seen to SVT-VP9 in its history, at least as far as AVX2 CPUs are concerned," which means some Intel processors will benefit from the change as well.
VP9 debuted in 2013 as a successor to the HEVC and h.265 video coding formats. It's set to be replaced by the AV1 codec, for which Intel also released an encoder in February. But for now it's popular because of its use by YouTube. Phoronix said in February that Intel released SVT-VP9 with the goal of "supporting real-time encoding of up to two 4Kp60 streams on an Intel Xeon Gold 6140 processor."
SVT-VP9 historically performed best on AVX-512 processors. The update pushed last week improves performance on the older AVX2 processors, which could be a welcome update for anyone who publishes on YouTube but doesn't have a top-of-the-line system. Intel's joke about fixing the performance gap on EPYC undersold the update--it should make SVT-VP9 more viable for people on both platforms.
Like we said: tech companies often work with their competitors. That doesn't mean they can't have a little fun at each other's expense, though, and it's even better if that fun is related to performance improvements for older processors that both companies benefit from.
The patch is less than 20 lines long and almost all of them replace an AVX512 check with an AVX2 one - meaning the original programmer simply didn't care about what CPU the instruction was available on, he simply minded the CPU he was running currently. As far as I know, it's still bad practice to detect the platform instead of the feature - the only case where it's acceptable is when the feature is present but buggy and you have no efficient way to circumvent the bug.
Agree, simply replacement of an AVX with another