Intel has been developing a new graphics driver stack for Xe, which will officially support SR-IOV from Xe2 onward, https://www.phoronix.com/news/Intel-New-Xe-Linux-Driver. It makes sense to focus Intel resources on the new hardware and driver architecture, but thanks to OSS, the existing stable driver can also be improved by community contributions.

Impact appears to be limited, https://www.phoronix.com/news/Intel-Maintainers-Linux-Depart

The issue that phoronix is facing might be due to a power management bug that is not related to the driver at all.

Not sure if we need to support SRIOV on the HW. VirtIO GPU native contexts should be good enough for most consumers.

I imagine SRIOV would be useful for more advanced usecases

I remember being somewhat excited for Intel dGPUs since I had a real interest in a card that could do GVT-g and also might have super low idle power consumption like their iGPUs that would fit well with my VM server. We ended up with GVT-g canceled and promising of SR-IOV coming eventually and dGPUs with atrocious idle power consumption!

True. The display controller is also a different block, separated from the GPU and from the video codecs.

While on Lunar Lake the GPU and the video codec block are on the same tile, they are still in different locations on the compute tile.

In the new Arrow Lake S desktop CPU, to be announced tomorrow, the GPU is extracted on a separate tile, like in Meteor Lake, while the other two blocks related to video output, i.e. the video codec block and the display controller block, are located on a tile that contains the memory controller and a part of the peripheral interfaces and which is made using a lower-resolution TSMC process than the CPU and GPU tiles.

Benchmarking hardware encode is also a pretty specialized rabbit hole since it's not just the performance that varies, but also the quality of the results.

> the video encode and decode blocks were on an entirely different piece of silicon from the GPU.

As far as I understand this is not true. It's a different engine within the graphics device, and it shares the execution units.

> Most of the video you encode on a computer is actually all in software/CPU because the quality and efficiency is better.

I don't think that's true. I bought a Thinkpad laptop, installed Linux and one of my issues was that watching youtube video put CPU onto 60%+ load. The same with Macbook barely scratched CPU at all. I finally managed to solve this issue by installing Arch. When everything worked as necessary, CPU load was around 10%+ for the same video. I didn't try Windows but I'd expect that things on Windows would work well.

So most of the video for average user probably is hardware decoded.

>>> It can generally handle most decode operations with CPU help and a very narrow encoding spec.

This is so much spot on. Video coding specs are like a "huge bunch of tools" and encoders get to choose whatever subset-of-tools suits them. And than hardware gets frozen for a generation.

> Most of the video you encode on a computer is actually all in software/CPU because the quality and efficiency is better.

It depends on what you care about more, you don't always need the best possible encoding, even when you're not trying to record/stream something real time.

For comparison's sake, I played around with some software/hardware encoding options through Handbrake with a Ryzen 5 4500 and Intel Arc A580. I took a 2 GB MKV file of about 30 minutes of footage I have laying around and re-encoded it with a bunch of different codecs:

  codec   method   time     speed     file size   of original
  H264    GPU      04:47    200 fps   1583 MB     77 %
  H264    CPU      13:43    80 fps    1237 MB     60 %
  H265    GPU      05:20    206 fps   1280 MB     62 %
  H265    CPU      ~30:00   ~35 fps   would take too long
  AV1     GPU      05:35    198 fps   1541 MB     75 %
  AV1     CPU      ~45:00   ~24 fps   would take too long

So, if I had a few hundred of GB of movies/anime locally that I wanted to re-encode to make it take up less space for long term storage, I'd probably go with hardware H265 or AV1 and that'd be perfectly good for my needs (I actually did, it went well).

Of course, that's a dedicated GPU and Intel Arc is pretty niche in of itself, but I have to say that their AV1 encoder for recording/streaming is also really pleasant and therefore I definitely think that benchmarking this stuff is pretty interesting and useful!

For professional work, the concerns are probably quite different.

>Most of the video you encode on a computer is actually all in software/CPU because the quality and efficiency is better.

That was the case up to like 5 to 10 years ago.

These days it's all hardware encoded and hardware decoded, not the least because Joe Twitchtube Streamer can't and doesn't give a flying fuck about pulling 12 dozen levers to encode a bitstream thrice for the perfect encode that'll get shat on anyway by Joe Twitchtok Viewer who doesn't give a flying fuck about pulling 12 dozen levers and applying a dozen filters to get the perfect decode.

QuickSync passthrough should get you everything you need on i3+ chips. It's basically intel's only selling point in the homelab/home server space, and it's a big one.

[Edit: I think I initially misread you - but I agree, it's a huge differentiator]

x265 is a cpu based H.265 encoder and is not accelerated.

what actually uses x265? I thought pretty much everyone used AV1 for their next gen codec.

Weird. I've seen far better results elsewhere.

Did the first claw even sell well? That said, the Steam Deck competitors aren't interesting to me without the touchpads and four back buttons.