Rust-Written Stateless Codec Drivers Make A Lot Of Sense

[phoronix]

Phoronix: Rust-Written Stateless Codec Drivers Make A Lot Of Sense

When it comes to making use of the Rust programming language within the Linux kernel, one of the areas where it makes a lot of sense is for the video codec drivers given the amount of unknown/untrusted data submitted by user-space for video processing and it being a wide attack surface for bad actors. With the memory safety features of Rust this can be a big benefit to such drivers and Collabora is currently experimenting with a virtual codec driver Rust implementation to prove the concept...

https://www.phoronix.com/news/Rust-Codec-Drivers-Proposal

[Kjell]

Allowing Dolby Vision + HDR10+ to run in mainline Linux kernel would make a lot of sense too.. Considering you've already paid for the license by using a certified/playback capable device in the first place.

Now that's a codecs driver worth investing time into.. oh it's proprietary

[Vorpal]

The recorded video doesn't seem to be up yet unfortunately.

[fallingcats]

Seems like kpedersen hasn't woken up yet to explain that this couldn't possibly lead to anything so why even try to improve things.
Also nobody even knows anybody who ever used rust. Surely Microsoft is pushing this to kill linux.

There is literally no other explanation. Hurr durr.

[kpedersen]

Seems like @kdpeterson hasn't woken up yet to explain that this couldn't possibly lead to anything so why even try to improve things.

Heh, well the enforced bounds checking certainly won't help performance for the kinds of workloads that a codec encounters will it? Same reason why codecs are not written in Java or use std::vector<T>::at(idx) when they are written using C++. And then if you do use Rust's i.e slice::get_unchecked_mut, then whats the point?

Collabora is currently experimenting with a virtual codec driver Rust implementation to prove the concept

After a decade and the Rust ecosystem is still at this stage... And in another decade, it will be the same.

unsafe
{
  // TODO: Waste more time stagnating the industry by talking about Rust
}

[bug77]

Heh, well the enforced bounds checking certainly won't help performance for the kinds of workloads that a codec encounters will it? Same reason why codecs are not written in Java or use std::vector<T>::at(idx) when they are written using C++.



After a decade and the Rust ecosystem is still at this stage...

unsafe
{
// TODO: Waste more time talking about Rust stagnating the industry
}

You, sir, are so smart...
https://nnethercote.github.io/perf-b...might%20expect.

[mmstick]

Heh, well the enforced bounds checking certainly won't help performance for the kinds of workloads that a codec encounters will it? Same reason why codecs are not written in Java or use std::vector<T>::at(idx) when they are written using C++.

It would seem that you don't actually know that much about Rust or bound checks. The compiler inserts bound checks in the same places where it would be required to pass a code review in C. It is able to automatically eliminate most bound checks when you use iterators, slices, or static indexes. Java isn't even comparable because it has a runtime garbage collector. And Rust is soundly beating C++ in benchmarks and code legibility.

[kpedersen]

It would seem that you don't actually know that much about Rust or bound checks. The compiler inserts bound checks in the same places where it would be required to pass a code review in C.

Because you can assume bounds sizes for a codec stream at compile time? No, you can't. None of your mentioned solutions can avoid unsafe access if you want performance.

You, sir, are so smart...

I covered the unsafe (get_unchecked_mut) aspect in my post. Unsafe means you are achieving nothing but wasting time writing support code just to use Rust. In short, you are just writing janky C++ using a Rust compiler.

But hey, if that's what you want to do (or rather talk about), I will leave you to it. I'm gonna limit my Rust posts to once a week because verbosity and noise is one area where Rust developers have anyone beaten and I don't personally have the time to reciprocate.

[Quackdoc]

Allowing Dolby Vision + HDR10+ to run in mainline Linux kernel would make a lot of sense too.. Considering you've already paid for the license by using a certified/playback capable device in the first place.

Now that's a codecs driver worth investing time into.. oh it's proprietary

none of that is relevant to this, DV/HDR10+ is metadata which can already be forwarded. They aren't codecs, Codecs are (a bit of play loose with the term) things like hevc av1 avc etc. Dolbyvision and HDR10+ are metadata which can be contained within said bitstreams. The decoder takes this metadata and forwards it to the display. I'm not sure how desktop linux drivers like amdgpu and i915/xe handles this, perhaps agd5f could comment here? Won't tag though since it doesn't matter that much. But at the very least, basic HDR and I believe even "static" HDR metadata like HDR10 works on amdgpu + amdvlk when using vulkan HDR extensions. When using arm SBCs HDR10+ metadata is supported fine at the very least I never had access to a dolby vision device to test that, but as far as I know it should work too.

now doing it in a "zero copy" manor might be a different story

[dlq84]

Oh man, if only kpedersen could've told them in time that it's a toy language, now they are trying to use it for real things