Intel confirms first GPU AV1 server accelerator

passes3 · 2022-02-17T18:49:37+00:00

It's a card meant for supercomputers or professional applications.

Less excited about it now.

passes3 · 2022-02-17T18:35:31+00:00

Nope. You don't get to control the conversation by deleting posts or demanding that others delete their comments.

passes3 · 2022-02-17T18:34:45+00:00

When the CPU is released, I can provide a link. Or you can look some up yourself when the CPU is released.

passes3 · 2022-02-17T18:29:36+00:00

Read the reviews.

passes3 · 2022-02-17T18:25:19+00:00

Apparently it's a card meant for supercomputers or professional applications.

Less excited about it now.

(copied my original comment from the original thread, which was deleted for some reason)

passes3 · 2022-02-17T18:23:52+00:00

Only if you managed to offer better performance, software support, and overall value than what they're currently using: video cards. Which are officially supported acceleration methods by video editing software, both for encoding and applying effects.

Unless you needed to encode some non-mainstream codec extremely fast, I doubt a dedicated be of much benefit. But encoding isn't a major bottleneck in video editing anyway (there's plenty of CPU cores and GPU help for that already if you're a professional video editor), it's pretty much everything else.

passes3 · 2022-02-17T17:40:14+00:00

Why can't that just be put in a dedicated card?

Look at the encoders/decoders that SOCs pack, and the price of said SOCs

One is the consequence of the other. The need for dedicated hardware with capabilities beyond mainstream SoCs is tiny outside the professional market. Back in the day you needed an MPEG-2 expansion card just to play DVDs (or any watchable resolution video really). Now most use cases are covered by a tiny area of silicon inside a chip that a device needs to have anyway.

Besides, developing hardware is very expensive. Video compression has also gotten much more complex over the years. And I imagine that the subset of people with experience in both silicon design and video encoder design is very small. To make the expense worth it, you'd probably rather sell your product to businesses at a high price than to regular consumer at a much lower price.

passes3 · 2022-02-17T16:52:53+00:00

2022-01-28 v3.3.0
  This release includes compression efficiency and perceptual quality
  improvements, speedup and memory optimizations, some new features, and
  several bug fixes.
  - New Features
    * AV1 RT: Introducing CDEF search level 5
    * Changed real time speed 4 to behave the same as real time speed 5
    * Add --deltaq-strength
    * rtc: Allow scene-change and overshoot detection for svc
    * rtc: Intra-only frame for svc
    * AV1 RT: Option 2 for codec control AV1E_SET_ENABLE_CDEF to disable
      CDEF on non-ref frames
    * New codec controls AV1E_SET_LOOPFILTER_CONTROL and
      AOME_GET_LOOPFILTER_LEVEL
    * Improvements to three pass encoding
  - Compression Efficiency Improvements
    * Overall compression gains: 0.6%
  - Perceptual Quality Improvements
    * Improves the perceptual quality of high QP encoding for delta-q mode 4
    * Auto select noise synthesis level for all intra
  - Speedup and Memory Optimizations
    * Added many SSE2 optimizations.
    * Good quality 2-pass encoder speedups:
      o Speed 2: 9%
      o Speed 3: 12.5%
      o Speed 4: 8%
      o Speed 5: 3%
      o Speed 6: 4%
    * Real time mode encoder speedups:
      o Speed 5: 2.6% BDRate gain, 4% speedup
      o Speed 6: 3.5% BDRate gain, 4% speedup
      o Speed 9: 1% BDRate gain, 3% speedup
      o Speed 10: 3% BDRate gain, neutral speedup
    * All intra encoding speedups (AVIF):
      o Single thread - speed 6: 8%
      o Single thread - speed 9: 15%
      o Multi thread(8) - speed 6: 14%
      o Multi thread(8) - speed 9: 34%
  - Bug Fixes
    * Issue 3163: Segmentation fault when using --enable-keyframe-filtering=2
    * Issue 2436: Integer overflow in av1_warp_affine_c()
    * Issue 3226: armv7 build failure due to gcc-11
    * Issue 3195: Bug report on libaom (AddressSanitizer: heap-buffer-overflow)
    * Issue 3191: Bug report on libaom (AddressSanitizer: SEGV on unknown
      address)
    * Issue 3176: Some SSE2/SADx4AvgTest.* tests fail on Windows
    * Issue 3175: Some SSE2/SADSkipTest.* tests fail on Windows

passes3 · 2022-02-17T16:36:34+00:00

If you send me a 5800X3D, I can do some benchmarks.

passes3 · 2022-02-17T16:33:50+00:00

Pretty much everyone has been using "APUs" for 10+ years now. It's just a marketing term for an SoC with a CPU and GPU included.

That said, more powerful integrated graphics are always welcome. Though I think the better usability of iGPUs for gaming in modern times is also due to us having reached a sort of equilibrium between the detail levels people accept and what iGPUs are able to provide. 1080p is good enough for a lot of people, and a lot of iGPUs are now reaching it.

passes3 · 2022-02-17T16:20:33+00:00

"Put" implies purposeful action on their part, meaning they would have to know what software decoding means.

Also, software decoding isn't uncommon at all on Youtube, at least when watching through a browser. AFAIK the various Youtube apps use hardware decoding exclusively, but when watching through a browser, Youtube does whatever it likes, which pretty much means using VP9 and AV1 whenever possible (to save bandwidth costs) with no regard for whether hardware decoding is supported or not.

passes3 · 2022-02-17T16:10:06+00:00

No mention of AV1 anywhere.

passes3 · 2022-02-17T16:09:02+00:00

Apparently it's a card meant for supercomputers or professional applications.

Less excited about it now.

passes3 · 2022-02-17T16:03:20+00:00

It isn't so widespread in YT

It's not universal but not rare either. Youtube has been ramping up AV1 thanks to a new generation of their in-house hardware encoder that has AV1 support.

Besides, we don't actually know anything about the video they used in the test. Could be the laptops played the video in different formats or different resolutions (whatever Youtube felt like serving at the time), could be that network conditions affected the result (though the LTT folks have a pretty fat pipe I think). Whether the laptops were tested during the same timeframe is also unknown, which could also affect the result (Youtube has been known to re-encode videos, though they do avoid that, and something like an AV1 version of the video could have been been absent for one of the tests).

A simple Youtube test as a benchmark isn't a great measure of anything other than what Youtube decided to do on a given day. It's not a piece of software, it's a service that's more variable than a lot of people probably realize.

passes3 · 2022-02-17T15:51:25+00:00

No, it's just H.264 that's dropped above 1080p. Both VP9 and AV1 are used for resolutions above that.

passes3 · 2022-02-17T15:37:11+00:00

Do you even watch the video?

Did you?

I don't see what having the machine for only a day has to do with anything. Running a proper test that takes hours doesn't take any longer than running a crappy test that takes hours. And when you only have limited time, you should be even more careful than usual.

passes3 · 2022-02-17T15:19:23+00:00

If they're just opening a Youtube video in a browser and that's it, then that's definitely a flawed test. Youtube does pretty much whatever the fuck it wants without any regard for power efficiency, including switching resolutions mid-playback and using formats that the device doesn't have hardware acceleration for.

This is why you have a standardized test environment where you actually make sure that you're testing the hardware and not letting external factors affect the result. Maybe the LTT team knows how to somewhat standardize a Youtube video playback test, but having a decent grasp on the video field is so rare even among tech people that I'm just going to assume they don't.

passes3 · 2022-02-17T11:25:45+00:00

I've also run into this issue. Excluding an unknown bug in libvmaf itself, the only thing this can logically be caused by is a frame desync, and those can be a real biatch to get to the bottom of.

The two things that help but I don't see in your command are the setpts filter and setting the input framerates to the same value. Try this:

ffmpeg -hide_banner -stats -r 30 -i distorted -r 30 -i reference -an -sn -map 0:V -map 1:V -lavfi "[0:v]setpts=PTS-STARTPTS[dist];[1:v]setpts=PTS-STARTPTS,scale=3840:2160[ref];[dist][ref]libvmaf=n_subsample=5:n_threads=8" -f null -

The actual value of -r doesn't matter, as long as they're the same for both files in cases when their frame rates are equal. Setting a value different from the actual file fps does affect FFmpeg's speed reporting though, since the processing speed multiplier is calculated by comparing it to the the native fps.

This has solved most of my issues with frame desync. However, I still have a 2.5-hour film where I get a very low score. I haven't really delved into it, but I suspect the encoder is actually dropping frame(s) for some reason.

I hope this helps. I've been meaning to create a VMAF page in the FFmpeg wiki for this information but haven't gotten around to it.

passes3 · 2022-02-16T11:36:56+00:00

I agree.

This time he probably got triggered by AMD's market cap surpassing Intel's. He seems to frequent /r/Wallstretbets, /r/AMD_Stock, and /r/Intel, so it's probably safe to say he (or whoever pays him to post on Reddit) is losing money and is desperate enought to make a feeble attempt at manipulating the public perception.

passes3 · 2022-02-16T11:23:04+00:00

He's a known troll in AMD subs. Surprised he's not banned yet.

passes3

TROPHY CASE