h264 support for GM45 chipset

[leg7]

Hello, I am not sure if this is the place to ask but I have read that there used to h264 support for the GM45 chipset on a different branch of this repo but it has since been deleted.

https://forums.gentoo.org/viewtopic-t-925258.html
http://www.linuxsystems.it/2012/05/gentoo-g45-gm45-h264-vaapi-video-decoding/
https://aur.archlinux.org/packages/libva-intel-driver-g45-h264/
https://01.org/linuxmedia/vaapi

Could anyone help me find this branch or clear up what has happened since the time these threads have been made?
I'm trying to get support for this on Gentoo and currently it doesn't work with the latest libva and intel-vaapi-driver.

[lorn10]

Hi!

It looks that the GM45 is a Gen4 chipset and this one is now also supported by the new crocus Gallium driver. VA-API support for this driver was recently added which is confirmed here.

However the corresponding patch was merged after the current libva 2.13. So there is needed first a new libva version, - maybe @XinfengZhang can say when we will see this?

It should be noted that also some oibaf PPA Ubuntu users are awaiting this eagerly.:wink:

[Kappa971]

I'm using Xubuntu 22.04, which has the new Intel Crocus driver enabled by default (Mesa 22.0.1), with an Intel GMA 4500 MHD. The VA-API driver works but h264 decoding support is not indicated:

libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.14 (libva 2.12.0)
vainfo: Driver version: Intel i965 driver for Intel(R) GM45 Express Chipset - 2.4.1
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD

The Intel GMA 4500 MHD supports h264 video decoding, the VA-API driver is useless in this case. Are there any plans to add h264 video decoding?
On the internet I only found this (most recent): https://issues.guix.gnu.org/38403

[leg7]

I'm now using the crocus driver and vainfo still tells me that h264 decode is not supported. So it seems that it didn't fix anything.

However playing videos in mpv now seems to allow me to playback h264 content smoothly even though it is telling me that h264 is not supported. So maybe the crocus driver is doing it's job ? idk I just gave up honestly.

[Kappa971]

I'm now using the crocus driver and vainfo still tells me that h264 decode is not supported. So it seems that it didn't fix anything.

However playing videos in mpv now seems to allow me to playback h264 content smoothly even though it is telling me that h264 is not supported. So maybe the crocus driver is doing it's job ? idk I just gave up honestly.

As I understand it, libva is using the i965_drv_video.so driver which hasn't been modified in any way, so still no h264 decoding. The new crocus_dri.so driver appears to only concern OpenGL, and replaces the old i965_dri.so.

I returned to Debian 11 as it is lighter than Xubuntu, I hope h264 decoding will finally be implemented, in time for the release of Debian 12 (mid 2023).

Honestly I'm pretty skeptical as we're talking about an integrated graphics card from 2009, and if h264 decoding hasn't been implemented so far, I doubt it ever will. The solution would be to reinstall Windows 7, with the official drivers I could force the h264 codec to YouTube and take advantage of the hardware decoding (it would make the CPU less hot).

The h264 decoding also works on Windows 10 with modified drivers, but with Windows 10 the CPU is always at 100% usage so I'm not going to reinstall it. I even forced a Windows 11 installation with the same modified drivers, here too the h264 decoding works and the CPU usage is lower, setting maximum performance (turning off animations, shadows, transparencies, etc) also works decently but File Explorer has been slowed down a lot, it's super slow to do anything.
So the choice is between Linux (without h264) and Windows 7 (with h264).

[lorn10]

Okay, just be clear, the corresponding VAAPI support with crocus should be present since #547 and Libva 2.14.0.

However, I can confirm that the crocus VAAPI support seems to be still somehow flawed. This is the case also for my 6th generation Intel "Sandy Bridge" HD 2000 based system. It looks that the corresponding crocus_drv_video.so is still missing. Or maybe the i965_drv_video.so is not updated on some distros correctly. In my case I use Kubuntu 20.04 LTS with the oibaf PPA enabled. Current Mesa version is Mesa 22.1.0-devel (git-6d263ff 2022-04-11 focal-oibaf-ppa).

Regarding the even older Intel GMA 4500 MHD which is a 4th generation Intel iGPU it is possible that it is simply unsupported. Maybe we ask @XinfengZhang and @airlied what the exact status of VAAPI support with crocus is. And maybe there should be pushed a new intel-vaapi-driver package, version 2.4.1 seems to be effectively outdated.

@Kappa971, I don't think that Windows could be here a solution. Windows 7 is since quite some time EOL and Windows 10 is also nearing its end. Even if this sounds strange, I use Kubuntu 20.04 LTS even on quite old DX9 class hardware. I just have to set the compositing to OpenGL ES 2.0 with EGL via the "KWIN_COMPOSE=O2ES" environment variable. With that setting, KDE is almost as fast as LXQt or the former LXDE. And I think this will be also true for the upcoming Kubuntu 22.04 LTS. 😉

[Kappa971]

However, I can confirm that the crocus VAAPI support seems to be still somehow flawed. This is the case also for my 6th generation Intel "Sandy Bridge" HD 2000 based system. It looks that the corresponding crocus_drv_video.so is still missing. Or maybe the i965_drv_video.so is not updated on some distros correctly. In my case I use Kubuntu 20.04 LTS with the oibaf PPA enabled. Current Mesa version is Mesa 22.1.0-devel (git-6d263ff 2022-04-11 focal-oibaf-ppa).

I don't think crocus_drv_video.so currently exists. I think Intel HD2000 also uses i965_drv_video.so, probably this chip already had h264 codec support in i965_drv_video.so and probably others as well.

Regarding the even older Intel GMA 4500 MHD which is a 4th generation Intel iGPU it is possible that it is simply unsupported. Maybe we ask @XinfengZhang and @airlied what the exact status of VAAPI support with crocus is. And maybe there should be pushed a new intel-vaapi-driver package, version 2.4.1 seems to be effectively outdated.

The chip is very old, it would not surprise me if it wasn't supported, however I think that the h264 hardware decoding support is very important in this case, as it would drain the CPU from this task... it would be possible for example to see a video on YouTube in h264 1080p 30fps offloading much of the work on integrated graphics (1080p 60fps is too much for this chip).
Now, for example, you can only see videos at maximum 720p 30 fps with the CPU at 70-80% utilization...
I think Linux should aim where Windows can't, and this is the biggest example of that.

@Kappa971, I don't think that Windows could be here a solution. Windows 7 is since quite some time EOL and Windows 10 is also nearing its end.

I agree with this, but unfortunately the Intel GMA 4500 MHD h264 hardware decoding currently only works on Windows (and if you want to have a usable PC, the choice falls on Windows 7).

[leg7]

Using proprietary software is definitely not a solution.

Anyways my solution was just to compile my entire system with O3, LTO, PGO and other optimizations, use dwm and make a script that turns off my compositor when mpv opens (Yup this is what it takes to get smooth video playback, I know it sounds ridiculous).
Even with no decode support watching a 1080p30 youtube video in mpv takes up 15% cpu and a 1080p60 video on odysee with mpv takes up about 40-50% I'd say.
All the content is played back smoothly but the issue is that it uses valuable cpu resources for no good when it could simply make use of my igpu.

The most annoying thing about all of this is that the support is there, there is fork or branch of this repo with h264 support for these chips and the only thing left to do is merge it into the main branch. All the work has already been done and implemented aghhh.

[Kappa971]

Using proprietary software is definitely not a solution.

Anyways my solution was just to compile my entire system with O3, LTO, PGO and other optimizations, use dwm and make a script that turns off my compositor when mpv opens (Yup this is what it takes to get smooth video playback, I know it sounds ridiculous). Even with no decode support watching a 1080p30 youtube video in mpv takes up 15% cpu and a 1080p60 video on odysee with mpv takes up about 40-50% I'd say. All the content is played back smoothly but the issue is that it uses valuable cpu resources for no good when it could simply make use of my igpu.

All this, in addition to being complex, is impractical. What I want to do is watch YouTube videos with the internet browser, without external programs like mpv or VLC. Obviously, with these programs the CPU usage is lower and allows you to see these videos in a decent way, but it is not the definitive solution to this problem. The simplest solution (which even a mere mortal can do) is currently installing Windows 7 with official drivers, as it has h264 decoding support. I know that Windows 7 is no longer updated and it is a security risk, but this also affects Android phones, but no one cares there if you don't have the latest security patch (on my phone for example it dates back to February 2019, so it's as vulnerable as Windows 7, and millions of other smartphones as well). I would like to clarify that I use Tampermonkey to load a script to force YouTube to use the h264 codec (this limits the videos to 1080p60, but on the other hand this GPU can't handle beyond that).

The most annoying thing about all of this is that the support is there, there is fork or branch of this repo with h264 support for these chips and the only thing left to do is merge it into the main branch. All the work has already been done and implemented aghhh.

According to this site https://issues.guix.gnu.org/38403, there appear to have been problems since the introduction of the kernel 5.x

[leg7]

Using proprietary software is definitely not a solution.
Anyways my solution was just to compile my entire system with O3, LTO, PGO and other optimizations, use dwm and make a script that turns off my compositor when mpv opens (Yup this is what it takes to get smooth video playback, I know it sounds ridiculous). Even with no decode support watching a 1080p30 youtube video in mpv takes up 15% cpu and a 1080p60 video on odysee with mpv takes up about 40-50% I'd say. All the content is played back smoothly but the issue is that it uses valuable cpu resources for no good when it could simply make use of my igpu.

All this, in addition to being complex, is impractical. What I want to do is watch YouTube videos with the internet browser, without external programs like mpv or VLC. Obviously, with these programs the CPU usage is lower and allows you to see these videos in a decent way, but it is not the definitive solution to this problem. The simplest solution (which even a mere mortal can do) is currently installing Windows 7 with official drivers, as it has h264 decoding support. I know that Windows 7 is no longer updated and it is a security risk, but this also affects Android phones, but no one cares there if you don't have the latest security patch (on my phone for example it dates back to February 2019, so it's as vulnerable as Windows 7, and millions of other smartphones as well). I would like to clarify that I use Tampermonkey to load a script to force YouTube to use the h264 codec (this limits the videos to 1080p60, but on the other hand this GPU can't handle beyond that).

The most annoying thing about all of this is that the support is there, there is fork or branch of this repo with h264 support for these chips and the only thing left to do is merge it into the main branch. All the work has already been done and implemented aghhh.

According to this site https://issues.guix.gnu.org/38403, there appear to have been problems since the introduction of the 5.x kernel.

well in my case it's much more convenient to use mpv. I don't have a youtube account. I just subscribe to rss feeds in newsboat and when I press "w" it opens the video.

For me not using windows isn't even that much about the security updates. It's just a garbage operating system where you can't get any work done. On top of that it's bloated proprietary spyware that would render my machine absolutely useless since the idle cpu usage will be 80% and just sitting on the desktop uses 4gb of ram.

iirc there was a script to open youtube videos in mpv from your browser if you really want to use your browser.

[Kappa971]

well in my case it's much more convenient to use mpv. I don't have a youtube account. I just subscribe to rss feeds in newsboat and when I press "w" it opens the video.

For me not using windows isn't even that much about the security updates. It's just a garbage operating system where you can't get any work done. On top of that it's bloated proprietary spyware that would render my machine absolutely useless since the idle cpu usage will be 80% and just sitting on the desktop uses 4gb of ram.

iirc there was a script to open youtube videos in mpv from your browser if you really want to use your browser.

I used to be a fan of Windows, but I'm not anymore due to the ridiculous requirements of Windows 11 (Microsoft only wants to create e-waste, even if they consider themselves environmentally friendly), but having said that I don't agree on what you wrote.
It can't be denied that Personal Computer is equivalent to Windows, and this not from today but for more than 20 years (not counting Windows 3.11 and below and DOS), and that most software and devices run on Windows (so the fact you say that on Windows you can't work doesn't make sense).
Windows 10/11 requires more resources than Windows 7 and they are not suitable for these old laptops, they run many background processes including Windows Defender scans, Windows Update, Microsoft Store app updates, Microsoft Office Click-to-Run (to update Office builds) and more.
With 4GB of RAM, Windows 10 uses around 2GB of RAM. With 16gb of RAM, it uses around 4gb, so ram usage doesn't mean much, it probably has different RAM management than Linux, and it isn't the main problem in these old laptops (the problem is the general slowness due to poor CPU and GPU). With a desktop PC running Windows 10, a 15-year-old 64-bit CPU, dedicated GPU (such as a GT 710), SSD, and 6-8GB of RAM, you have a perfectly functional system. The problem is that these old laptops were using CPUs and GPUs which were already poor when they came out.
However I have gone far enough beyond the original intent of this issue, anyone can use what they want. 🙂

Going back to the issue, I hope someone will find a solution to take advantage of h264 hardware decoding on this chip, considering the power of these CPU and GPU, take advantage of hardware decoding in Linux would be very useful.

[Type-Here]

Hi, I also have a laptop with GM45 GPU. I'm using Linux Mint 20 and I can confirm that vainfo gives the same output (only MPEG-2 Dec) also here.
I know that being the card so old I have few hopes, but are there any news for h264 support?

h264 decoding also works on Windows 10 with modified drivers

@Kappa971
I'm running a dual-boot with windows, would you give me more info about the modified drivers to be installed, please?

[Kappa971]

Hi, I also have a laptop with GM45 GPU. I'm using Linux Mint 20 and I can confirm that vainfo gives the same output (only MPEG-2 Dec) also here. I know that being the card so old I have few hopes, but are there any news for h264 support?

No developers replied here after 4 months, so I'm pretty pessimistic. It's a shame because h264 decoding is the only useful thing this useless GPU can do 😅.

@Kappa971 I'm running a dual-boot with windows, would you give me more info about the modified drivers to be installed, please?

Here you will find everything: https://www.tenforums.com/graphic-cards/167898-custom-driver-intel-gma-4500-m-mhd-extreme-plus-2-nighmayor.html.
If your CPU is slow like mine (Intel Pentium SU4100), avoid Windows 10/11, they consume too many resources. Windows 7 would probably be much more usable (and in this case the official drivers from the manufacturer's website are enough).

[lorn10]

It should be noted that the GM45 iGPU is for a long long time EOL and as of 2022 no Intel developer will care about this. 😉

However, because this matter is open source a technically skilled person can independently add GM45 VAAPI support. This was already done once by Gentoo developer @ConiKost (see first link in the first post of @leg7). But that work never got merged back into the official intel-vaapi-driver for whatever reasons.

Most likely this was because of some fundamental changes in the VA-API framework on later 5.x Linux kernels which made the GM45 VAAPI modifications again incompatible. So in the end, even more adjustments would have been necessary to get this working again.

[Kappa971]

It should be noted that the GM45 iGPU is for a long long time EOL and as of 2022 no Intel developer will care about this. 😉

I absolutely don't expect an Intel developer to add h264 decoding support in the GM45 chipset (on the other hand they want to sell the new hardware), the hope falls on an independent/enthusiast developer. Also the Intel gen4 GPU graphics driver has been updated lately (although i don't know if from intel), I don't expect the VA-API driver to be updated too but I hope so 🙂.

However, because this matter is open source a technically skilled person can independently add GM45 VAAPI support. This was already done once by Gentoo developer @ConiKost (see first link in the first post of @leg7). But that work never got merged back into the official intel-vaapi-driver for whatever reasons.

Most likely this was because of some fundamental changes in the VA-API framework on later 5.x Linux kernels which made the GM45 VAAPI modifications again incompatible. So in the end, even more adjustments would have been necessary to get this working again.

I also read on this site (https://issues.guix.gnu.org/38403) about problems with the 5.x kernel. The last message is from January 2022, then nothing more.

[Type-Here]

Thanks Kappa for your answer. I'll soon try the drivers on Windows. Actually, I have a Core 2 Duo as CPU and for my use case (pretty much studying, pdf, word...) is more than enough even though Win7 was much better. If this driver thing works I should be able to use this pc for 99% of my work.

It's a shame because h264 decoding is the only useful thing this useless GPU can do

Indeed 😭

Hi, @lorn10 thanks for your reply. I know, GM45 GPUs are outdated and for years I simply lost any hope, but recently I accidentally found several posts like this one, that were recent, like, this is from january of this year, and I saw a sparkle of hope again.

[ConiKost]

However, because this matter is open source a technically skilled person can independently add GM45 VAAPI support. This was already done once by Gentoo developer @ConiKost (see first link in the first post of @leg7). But that work never got merged back into the official intel-vaapi-driver for whatever reasons.

No, not really ;-) I only created the ebuild for the unofficial https://bitbucket.org/alium/g45-h264 repo, which contained the patched g45 driver with h264 support. I never patched the source code. But repo seems pretty dead and unmaintained.

[mirh]

freedesktop-unofficial-mirror/vaapi__intel-driver@63b2c54...ce369fc
freedesktop-unofficial-mirror/vaapi__intel-driver@master...g45-h264 plus this
There isn't really rocket science to patch. You basically just add the i965_weight128_workaround function, and you are done.

It's too bad that some unfortunate default memory allocation setting stalemated this.

[Kappa971]

freedesktop-unofficial-mirror/[email protected] There isn't really rocket science to patch. You basically just add the i965_weight128_workaround function, and you are done.

It's too bad that some unfortunate default memory allocation setting stalemated this.

If you know what you're talking about why don't you do a PR? Because otherwise I believe that unfortunately no one is interested in solving this problem ☹️

[mirh]

People on the AUR reported that to work just fine 3 months ago.
And I'm skeptical intel wouldn't have meaningfully touched this repo in years, if coffee lake didn't work.

So eventually, I feel like this is the usual *buntu inter-dependencies clusterfuck.

[Kappa971]

1. We have an outdated vaapi driver that does not support h264 decoding on gm45 chipset, so the driver is useless, at this point Intel may remove support from this driver to gm45 chipset, as it would not change anything.
2. We have an old development branch of the vaapi driver for g45 with h264 no longer in development. I didn't understand why this was never merged with the main branch.

[mirh]

I already addressed both above.
libva-intel-driver-g45-h264 2.4.1 isn't any older than the latest version here (and I don't know what intel could remove that isn't there to begin with).
There's no concrete difference between that and the commits I linked then (even though there might have been some round of rebasing since).
And as you can read from the very mouth that wrote the code, they could never resolve to merge it back because "1080p wasn't smooth".

I don't remember where I read that DVMT/pre-allocation helped with decoding, but I know at least some people fixed issues this way. Or perhaps it was people exceeding the Dual Engine capabilities (presumably 1080p at 30fps) to cause problems..idk.

[Kappa971]

I already addressed both above. libva-intel-driver-g45-h264 2.4.1 isn't any older than the latest version here (and I don't know what intel could remove that isn't there to begin with). There's no concrete difference between that and the commits I linked then (even though there might have been some round of rebasing since).

That driver doesn't exist of Debian / Ubuntu distributions (I didn't find it) so it doesn't matter to me, unless they make it officially available.

And as you can read from the very mouth that wrote the code, they could never resolve to merge it back because "1080p wasn't smooth".

Always better than just having the h262 decode. The Intel GMA4500MHD is perfectly capable of handling h264 1080p 30fps videos.

[mirh]

That driver doesn't exist of Debian / Ubuntu distributions (I didn't find it)

Then that's your problem, duh? It's not anything here to be "old" (hell, it's not even about patches being required, it's just a matter of rebuilding).

The Intel GMA4500MHD is perfectly capable of handling h264 1080p 30fps videos.

Yes, I know. And some people even reported youtube videos (which I assume are 30fps) were playing just smooth in mpv/vlc.
So that's why my assumption was that it may not be the driver to be even missing anything, but just people using the wrong programs or bios settings.

[Kappa971]

Then that's your problem, duh? It's not anything here to be "old"

This driver isn't in the official package, and it isn't present in Debian/Ubuntu and therefore is a big problem. What are the most popular Linux distributions? 😅
Why, if as you say the driver is ready, does it not merged the main branch after 13 years?
Also I knew that this is an old branch that is no longer in development (and I think others consider it that way too). If it is being developed "secretly", this is also a problem because no one else knows anything about it.

(hell, it's not even about patches being required, it's just a matter of rebuilding).

As I said before, if you know what you are talking about, why don't you contribute? I don't go into certain topics because I don't know enough.

Yes, I know. And some people even reported youtube videos (which I assume are 30fps) were playing just smooth in mpv/vlc. So that's why my assumption was that it may not be the driver to be even missing anything, but just people using the wrong programs or bios settings.

I have owned this laptop since 2010 (with Windows), I remember that until 2013 I could easily watch videos on YouTube in 1080p (there were only those at 30 fps). Then they changed the codec, and now a script is needed to force YouTube to use the h264 codec (with, for example, Tampermonkey).
I think people who were having performance issues with 1080p 30fps videos, they were using lower spec integrated graphics than the Intel GMA 4500MHD (there are several Intel GMA models).

In any case it is useless to continue talking about it, I personally don't have the knowledge to be able to deal with this problem, I only reported it as others here.

[mirh]

Why, if as you say the driver is ready, does it not merged the main branch after 13 years?

Because, even when the code first dropped 11 years ago, it was more of a "last stretch" of support for older hardware. And once they pushed it out of the door, despite actually maintaining the thing on life support more or less through the end of 2014, nobody was ever really paid enough to investigate further problems. Which at the same time were allegedly serious enough not to warrant merging.
But as I previously said, it could have been something as stupid as just too low "dedicated" memory for the igp (your own links mentioned this too).

Also I knew that this is an old branch that is no longer in development (and I think others consider it that way too). If it is being developed "secretly", this is also a problem because no one else knows anything about it.

.... as you can see from the second link in this thread, and the last one before my first post, people have been forward porting this patch until last year (and with activity waning here, further care shouldn't even be needed anymore)

As I said before, if you know what you are talking about, why don't you contribute?

Because 1) I'm not linuxing as of lately. 2) there's nothing to even contribute to begin with, if these are really the premises
3) if even intel could be bothered to still care about this, at least a bunch of people saying "I tried this in such and such way and it's flawless" would be needed

Then they changed the codec, and now a script is needed to force YouTube to use the h264 codec (with, for example, Tampermonkey).

IIRC it was only in 2015 that they switched everything to VP9. 2013 was only the date they started with testing (and you don't need special scripts.. just disabling av1 and vp9 support in the browser should be enough, if a bit rough)
On top of that, there's speculation chromium might not like the fact that g45-h264 (just like some other drivers) doesn't include VAProfileNone in the list of supported entrypoints.

I think people who were having performance issues with 1080p 30fps videos, they were using lower spec integrated graphics than the Intel GMA 4500MHD (there are several Intel GMA models).

It doesn't help that there's a ton of confusion about the extent of "full acceleration" even inside intel's own docs and claims.
EDIT: maybe the only thing missing is VLD

In any case it is useless to continue talking about it, I personally don't have the knowledge to be able to deal with this problem, I only reported it as others here.

Switch to anything that supports the AUR (if you cannot be bothered to learn the existential nightmare that apt is, which I cannot blame you) and start to churn out field feedback.

[Kappa971]

Because, even when the code first dropped 11 years ago, it was more of a "last stretch" of support for older hardware. And once they pushed it out of the door, despite actually maintaining the thing on life support more or less through the end of 2014, nobody was ever really paid enough to investigate further problems. Which at the same time were allegedly serious enough not to warrant merging. But as I previously said, it could have been something as stupid as just too low "dedicated" memory for the igp (your own links mentioned this too).

In the last link I shared, the last comment dates back to January 2022 but development may have stopped for years, I don't know. Also they talked about compatibility issues with the kernel 5.x so I don't know how this works on Arch.

Switch to anything that supports the AUR (if you cannot be bothered to learn the existential nightmare that apt is, which I cannot blame you) and start to churn out field feedback.

As mentioned before, they talked about problems with the kernel 5.x, how is it possible that on Arch Linux it works?

In any case, I don't use this PC very much, I tried Linux to make it still usable but the lack of h264 decoding is quite serious, the CPU is not fast enough to make up for this. The choice fell on Debian (with Xfce) because it is very light (more than Xubuntu) and because it requires practically no maintenance (unlike Arch).

[mirh]

In the last link I shared, the last comment dates back to January 2022 but development may have stopped for years

For the love of god, there's nothing left to develop. At least to get the barest acceleration, at least assuming my VRAM assumption holds.
And even them still refers back to @alium's repository.

Also they talked about compatibility issues with the 5.x kernel so I don't know how this works on Arch.

They also reported some nuisance there, but putting aside latest posters seemed to do just fine, nobody forces you on any kernel.

As mentioned before, they talked about problems with the kernel 5.x, how is it possible that on Arch Linux it works?

Either by 5.16 everything was nice and dandy again, or @ViNi-Arco forget to mention they were using some LTS kernel.
Regardless the path to testing (even without the slightest coding knowledge) seems pretty clear.

The choice fell on Debian (with Xfce) because it is very light (more than Xubuntu) and because it requires practically no maintenance (unlike Arch).

The only problem with arch is the elitist first install experience that takes you an afternoon to do the same things that windows 95 could already handle by itself. It doesn't really take any particular "maintenance" after that.
Anyhow, sane people that don't like masochism just use endeavour or manjaro in its place (you may even want to try the lxqt flavours, which legend says should be even lighter than xfce).

[alium]

hi all, i am not Intel's developer, i am just a maintainer for AUR, so i am not able develop this old driver. I was in contact with Intel's developer, the support of 264 on G45 was never perfect, they held it outside master in extra branch, but later (in year 2018?) they deleted this branch too. Intel's developer send me patches, so i was able with help keep it. But i have no G45 anymore, and i don't know, if it works or not.
there is no point in asking for support or further development, Intel will not develop it. They have definitely stopped developing of Gen4 (and vaapi-intel-driver is in maintenance mode too).

[mirh]

I also had the same impression, but was anything mentioned about VRAM/DVMT?
Because (despite the scarceness of reports available) people seemed to mention that as a key factor.
If not any I have yet to hear negative feedback about that.

[Kappa971]

Hi @alium, I have an old laptop with gm45 (Intel GMA 4500MHD) with Debian 11 (kernel 5.10), if you want I can try your driver (but you should tell me what to do).

Maybe you could upload it to GitHub so maybe someone more experienced can help solve the issues?

[alium]

that's true, H264 hardware acceleration works much better in Windows as on Linux. You can just download the package from me repo, compile it and install it. after you can test it on your Linux (best for testing is probably mpv)
#mpv.conf --hwdec=vaapi --vo=vaapi --hwdec-codecs=auto

Sorry, could you give me the link of your repo?
https://bitbucket.org/alium/g45-h264/downloads/intel-driver-g45-h264-2.4.1.tar.gz

[Type-Here]

Hi all again, just a couple of points.

1. I want to reassure you all that no one would ask or worse pretend for driver development of 10+ years GPU from anyone let alone intel devs but I personally just hoped someone techie enough from this very little group of people still using a gm45 would come up with a solution since I noted a bit of activity (meaning posts and requests) online recently. I think @Kappa971 thinks the same too, so, please, let's just keep it chill and work together for a possible solution.
2. So, to sum up (let me know if I understood correct):

• The modifications from original source should be minimal in order to work.
• There's a driver that works quite well (with some tweaks maybe and with some kernels better than others(?)) for Arch-based systems that's this one from @alium:

Sorry, could you give me the link of your repo?
https://bitbucket.org/alium/g45-h264/downloads/intel-driver-g45-h264-2.4.1.tar.gz

• Could work on Debian/Ubuntu based too but no one seems to have tested it before (?):
• In order to test this we have to compile it and install it and that's it basically, right?
  @Kappa971 if you try, please, let me know if it works; I can't personally try it now but I'll give it a shot as soon as I can.

[Kappa971]

I compiled the driver on Debian 11 i965_drv_video.so.zip. I have never compiled a Linux driver in my life, I copied it where the original driver was (making a backup) in /usr/lib/x86_64-linux-gnu/dri and restarted the PC.
vainfo looked promising:

libva info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.10 (libva 2.10.0)
vainfo: Driver version: Intel i965 driver for Intel(R) GM45 Express Chipset - 2.4.1
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD

Unfortunately the h264 decoding doesn't work in any way (am I doing something wrong?).
It doesn't work on YouTube (Firefox + tampermonkey + script for h264).
It doesn't work in VLC:

[00007fdcd8006690] gl gl: Initialized libplacebo v2.72.0 (API v72)
libva info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
[00007fdcb4c0b450] avcodec decoder: Using Intel i965 driver for Intel(R) GM45 Express Chipset - 2.4.1 for hardware decoding
[h264 @ 0x7fdcb4ca0d80] co located POCs unavailable
[h264 @ 0x7fdcb4c3bb00] reference picture missing during reorder
[h264 @ 0x7fdcb4c3bb00] Missing reference picture, default is 65774
[h264 @ 0x7fdcb4c58500] mmco: unref short failure
[h264 @ 0x7fdcb4c3bb00] reference picture missing during reorder
[h264 @ 0x7fdcb4c3bb00] Missing reference picture, default is 65792
[h264 @ 0x7fdcb4c58500] mmco: unref short failure
[h264 @ 0x7fdcb4ca0d80] reference picture missing during reorder
[h264 @ 0x7fdcb4ca0d80] Missing reference picture, default is 65810
[h264 @ 0x7fdcb4ca0d80] co located POCs unavailable
[h264 @ 0x7fdcb4c3bb00] mmco: unref short failure
[h264 @ 0x7fdcb4ca0d80] co located POCs unavailable
[h264 @ 0x7fdcb4c58500] co located POCs unavailable
[h264 @ 0x7fdcb4ca0d80] reference picture missing during reorder
[h264 @ 0x7fdcb4ca0d80] Missing reference picture, default is 66018
[h264 @ 0x7fdcb4c3bb00] mmco: unref short failure
[h264 @ 0x7fdcb4ca0d80] co located POCs unavailable
[00007fdcb4c0b450] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[00007fdcb4c0b450] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[00007fdcb4c0b450] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[00007fdcb4c0b450] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[00007fdcb4c0b450] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[00007fdcb4c0b450] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[00007fdcb4c0b450] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[00007fdcb4c0b450] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[00007fdcb4c0b450] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[00007fdcb4c0b450] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[00007fdcb4c0b450] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[00007fdcb4c0b450] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[h264 @ 0x7fdcb4c3bb00] co located POCs unavailable
[h264 @ 0x7fdcb4ca0d80] reference picture missing during reorder
[h264 @ 0x7fdcb4ca0d80] Missing reference picture, default is 65610
[h264 @ 0x7fdcb4c3bb00] mmco: unref short failure

It doesn't work in MPV:

*****@******:~/Scaricati$ mpv --hwdec=vaapi --vo=vaapi --hwdec-codecs=auto Big_Buck_Bunny_1080_10s_30MB.mp4
 (+) Video --vid=1 (*) (h264 1920x1080 30.000fps)
File tags:
 Artist: Blender Foundation 2008, Janus Bager Kristensen 2013
 Comment: Creative Commons Attribution 3.0 - http://bbb3d.renderfarming.net
 Composer: Sacha Goedegebure
 Genre: Animation
 Title: Big Buck Bunny, Sunflower version
[vaapi] libva: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
[vo/vaapi] Warning: this compatibility VO is low quality and may have issues with OSD, scaling, screenshots and more.
[vo/vaapi] vo=gpu is the preferred choice in any case and includes VA-API support via hwdec=vaapi or vaapi-copy.
VO: [vaapi] 1920x1080 yuv420p
V: 00:00:09 / 00:00:10 (99%) Dropped: 201


Exiting... (End of file)

EDIT
MPV is not choosing the right driver. I added LIBVA_DRIVER_NAME = "i965" before the mpv command but it still doesn't work.
I just copied the i965_drv_video.so file to /usr/lib/x86_64-linux-gnu/dri/, if what I did is correct then this driver no longer works.

[mirh]

Big_Buck_Bunny_1080_10s_30MB.mp4 is encoded with the H264 high profile at 5.1 level.
Also, for all my talking about memory, did you assigned the proper big amount in the bios?
Check the suggested variables and settings for VLC too.

[Kappa971]

Big_Buck_Bunny_1080_10s_30MB.mp4 is encoded with the H264 high profile at 5.1 level.

Anyway if this video doesn't work, I don't think others will work (2022 videos).

Also, for all my talking about memory, did you assigned the proper big amount in the bios?

1. I don't think I can change any amount of memory in the BIOS (the bios in this laptop has stripped down options)
2. on Windows it works without any BIOS changes.

Check the suggested variables and settings for VLC too.

In VLC I selected vaapi as video decoding and the log shows it, the driver is simply not working (it doesn't work for me).

[mirh]

Anyway if this video doesn't work, I don't think others will work (2022 videos).

Big buck bunny is an open-source film, most of times explicitly designed and shipped as a benchmark?
It's nowhere representative of your average video (my phone records 1080p at 20mbps with L4 for instance), let alone of potato youtube videos (even 60fps videos are a fifth of that).
Not saying it has higher than blu-ray quality, but the encoding preset they used in this specific case required higher resources.

on Windows it works without any BIOS changes.

I'm just spitballing really. For as much as I know, it could be DVMT isn't as (duh) dynamic in linux.
EDIT: just like here for instance

In VLC I selected vaapi as video decoding and the log shows it, the driver is simply not working (it doesn't work for me).

They suggested LIBVA_DRIVER_NAME=i965 VAAPI_MPEG4_ENABLED=true VDPAU_DRIVER=va_gl MESA_LOADER_DRIVER_OVERRIDE=i965 and "VA-API decoder via DRM".

[Kappa971]

Big buck bunny is an open-source film, most of times explicitly designed and shipped as a benchmark? It's nowhere representative of your average video (my phone records 1080p at 20mbps with L4 for instance), let alone of potato youtube videos (even 60fps videos are a fifth of that). Not saying it has higher than blu-ray quality, but the encoding preset they used in this specific case required higher resources.

The problem isn't high resources, it's not using the gpu for decoding at all.

They suggested LIBVA_DRIVER_NAME=i965 VAAPI_MPEG4_ENABLED=true VDPAU_DRIVER=va_gl MESA_LOADER_DRIVER_OVERRIDE=i965 and "VA-API decoder via DRM".

LIBVA_DRIVER_NAME=i965 I don't think it's necessary, as you can see from the log, the driver is automatically selected (on the second attempt, it first checks iHD_drv_video.so and obviously fails).
VAAPI_MPEG4_ENABLED=true Without this MPEG4 is disabled? it doesn't make sense 🤔
VDPAU_DRIVER=va_gl This I don't know what it does. Also I have read that VDPAU only works with Nvidia and AMD gpu 🤔
MESA_LOADER_DRIVER_OVERRIDE=i965 This is also not necessary as i965 is the default driver in Debian 11. Also this driver has been replaced by crocus (yes, they have updated the video drivers of Intel gen4-gen7 gpu, GMA 4500 is gen4)

[Kappa971]

With VLC, this is the only H264 video test is trying to use hardware decoding (without success): https://drive.google.com/file/d/0BwxFVkl63-lEbFBzak1sbmU1N0E/view?usp=sharing&resourcekey=0-GOK3gZYAmP-ywn6T9zCDoQ (Taken from here: https://kodi.wiki/view/Samples).

Intel_gpu_top shows the use of hardware (Video/0).
In the terminal window from which I launched VLC, the Vaapi driver is loaded and shows only errors.
VLC shows a black screen.
I've also tried other videos taken from the same site, they cause VLC to crash and hardware decoding doesn't work at all.
Hardware decoding doesn't work in Firefox.

So I think this driver is broken, the only solution would be to switch back to Windows (as mentioned above).

[lorn10]

Here follows the *.mov version of Big Buck Bunny: big_buck_bunny_1080p_h264_AAC.mov.

I think that one should be compressed with "normal h264 settings". 😉

PS It runs great at all my Radeon HD GPUs, even at the very first UVD1 based one from 2007. 👍

[Kappa971]

Here follows the *.mov version of Big Buck Bunny: big_buck_bunny_1080p_h264_AAC.mov.

I think that one should be compressed with "normal h264 settings". 😉

Thanks @lorn10 but by now I have removed the driver and I don't think I'll try it again, it's not able to do what I need. Even if this video worked, most of the other videos don't work and it doesn't work with YouTube either. I'm convinced that with Windows h264 decoding would have worked with all tested videos, but I don't want to reinstall Windows. 😅

PS It runs great at all my Radeon HD GPUs, even at the very first UVD1 based one from 2007. 👍

Your GPU probably has a vaapi driver with h264 decoding support.

[lorn10]

Okay, however I don't think this is the end in this topic. Maybe someone techie enough "will come along the road" and will get this working also with newer kernels. If this works on Windows it can and should also work on Linux. 😉

Alternatively someone could also launch a little $/€ awarded "Get VAAPI working on Gen4 GM45 project". So I mean somewhat in the sense of Patreon but the other way around, "Idea/Project is searching devs". 😃

[leg7]

I never expected this issue to blow up so much, I expected at most 2 replies.

I think a bounty could be a good idea. I have no experience writing drivers so sadly I cannot be of any help at the moment, though I am sure this wouldn't be that hard of a job for someone knowledgeable. Maybe since this issue has caught so much traction intel will do something about it, although I doubt that they will do anything.

[m1kemex]

I'm writing this on my Thinkpad X301. I know this is old, but I'm very fond of it and I'm sure lots of machines of this vintage are still floating around, so fixing the drivers is still a worthy project. Fully upgraded (mine has 8GB of RAM and a 400GB SSD) it's still quite useful if you understand its limitations. There is nothing I'd like more than having a fully functional Linux setup. That'd allow me to keep using in when Windows goes EOL.

I'm unfamiliar with Linux development, specially drivers, but I did a fair amount of programming back when I was younger. I understand how interrupts work, how to modify registers at special memory address and the like. I know both C/C++ and x86 assembly. If someone is kind enough to guide me through it, I'm sure I could fix what is broken. It shouldn't be too complicated as the driver is already complete.

I already complied the driver and gives me this input:

libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.14 (libva 2.12.0)
vainfo: Driver version: Intel i965 driver for Intel(R) GM45 Express Chipset - 2.4.1
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD

Bit it doesn't seem to work.

[lorn10]

I would really really like to contribute to this if I could. But I have zero understanding of programming...

However, perhaps this topic will now get some attention from the Intel devs. And maybe @mirh can make some noise, it looks that he has clearly a higher "dev-ping reputation" then me. 😉

[m1kemex]

Although not related to video decoding, it'll also be a good opportunity to try to improve the driver support level.

I'd like to raise awareness over the fact that GM45 (et al) is a Shader Model 4.0 ship and, according to this page, it should support OpenGL 3.3 instead of 2.1. It's just that intel got lazy and decided not to expose certain functionalities via OpenGL in a classic example of planned obsolescence.

OpenGL 2.1 is considered obsolete but not OpenGL 3.3. Fully supporting the chip capabilities via OpenGL / ES should allow people to run contemporary software such as Mozilla Firefox or Blender with full hardware acceleration, to the level of performance the hardware allows, of course. This is essential to keep this machines alive, since they are limited in their capabilities and specially sensitive to performance issues that arise from CPU based emulation.

[airlied]

@m1kemex you might think that, but it really isn't capable of GL 3.3. GL 3.0 requires minimum MSAA 4x support, the GPU doesn't have that, neither does Ironlake. Sandybridge is the first Intel GPU with 4xMSAA.

[m1kemex]

Yes, it's a weird chip, and slow, but nevertheless overall "modern". As far as I know, Mesa emulates missing capabilities, so making a fully conforming driver isn't an issue. Most people do not need strict conformance, though, so a driver parameter could be used to disable MSAA (and other workarounds) and get full performance for general usage.

Performance in Windows is quite acceptable for such an old hardware. This is strictly a software issue.

[airlied]

it's not possible to "emulate" MSAA. Mesa doesn't emulate missing capabilities.

[m1kemex]

Back in the day I did a bit of programming with OpenGL 1.x and, as far as I can remember, Mesa was a software implementation of OpenGL. DRI was developed as an interface to offload some parts of the pipeline to actual hardware via "hooks" and enhance performance. This is an hybrid model, with some parts of the pipeline running in the CPU and some in the GPU (I do remember Mesa explicitly reporting the GPU model and the CPU features it was using, like SSE). Therefore, Mesa was capable of compensating for some missing features, by emulating them in software.

I don't think any of this has changed; what changed is that every modern computer comes with a GPU now and thus software rendering is rarely used. I just checked and Mesa implements OpenGL 3.1, so newer DRI drivers probably don't contain any software emulation code by now. They just report what they support, like on Windows. But they are still built using Mesa framework, so, in theory, it is always possible to make it work as it used to be. Or, if it becomes problematic to mix both things, then MSAA can be silently disabled (report capability and all, but do nothing). I also checked on OpenGL anti-aliasing and I don't think having MSAA enabled is critical for an application. It'd be just a matter of losing some rendering quality.

I could be wrong. Like I said, all my knowledge is from like 15-20 years ago and before shaders were even invented. But the fact remains that the GPU works reasonably good on Windows via DirectX (Firefox on WIndows 10 uses hardware acceleration for everything). So there must be a way to get the same level of performance in Linux.

[airlied]

actually gm45 doesn't have geometry shader hardware either. so it's very far out as those are needed for 3.2

Mesa doesn't work like you think it does anymore. It doesn't work to mix sw and non-sw rendering paths in modern GPUs. In old GPUs the mix was only around whether vertex shading was on the CPU or could be done on the GPU.

[mirh]

I'd like to raise awareness over the fact that GM45 (et al) is a Shader Model 4.0 ship and it should support OpenGL 3.3 instead of 2.1. It's just that intel got lazy and decided not to expose certain functionalities via OpenGL in a classic example of planned obsolescence.

You shouldn't assume that dx10=ogl3.3.
And this hardware has still been getting love as of lately.

it's not possible to "emulate" MSAA. Mesa doesn't emulate missing capabilities.

Sure, but wasn't it you to to add https://github.com/mesa3d/mesa/commit/76ba50a25a8bbc1e5fbcdb24da7e09f8996cf2c5?

I also checked on OpenGL anti-aliasing and I don't think having MSAA enabled is critical for an application.

It's not, but the opengl spec had kind of an idiot ball there, and it's required for opengl 3.

actually gm45 doesn't have geometry shader hardware either. so it's very far out as those are needed for 3.2

Are you like sure?
People seemed hopeful in the past.

[ikt32]

About a year later, I think this issue is dead/in limbo, especially on kernel 5.x?

[mirh]

I don't think kernel has anything to do with it (I mean, video acceleration that is).
Crocus if any might have more chances of being intertwined?

Anyhow, I just gave this a try.. and it failed spectacularly (so much so that I'm even wondering if I had in fact tested it once upon a time?). Everything hangs the moment the first frame should appear, until the session crashes.
Even in 720p, even with low bitrate videos, and even with the main profile (though, admittedly, I didn't have a file with all of them)

i915 0000:00:02.0: [drm] GPU HANG: ecode 4:1:f3ffffff, in vlc [1214]
i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
i915 0000:00:02.0: [drm] vlc[1214] context reset due to GPU hang
i915 0000:00:02.0: [drm] GPU HANG: ecode 4:1:f3ffffff, in Xorg [606]
i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
i915 0000:00:02.0: [drm] *ERROR* failed to set rcs0 head to zero ctl 00000400 head 00002e14 tail 00000000 start 00506000
i915 0000:00:02.0: [drm] Xorg[606] context reset due to GPU hang
Fence expiration time out i915-0000:00:02.0:Xorg<606>:50d!
Fence expiration time out i915-0000:00:02.0:vlc[1214]:50e!
i915 0000:00:02.0: [drm] Resetting chip for request cancellation by kworker/1:1
(repeat more or less mixed a few times)
systemd-coredump[1235]: [🡕] Process 606 (Xorg) of user 0 dumped core.
                                                               
                                                               Stack trace of thread 606:
                                                               #0  0x00007f9399a5226c n/a (libc.so.6 + 0x8926c)
                                                               #1  0x00007f9399a02a08 raise (libc.so.6 + 0x39a08)
                                                               #2  0x00007f93999eb538 abort (libc.so.6 + 0x22538)
                                                               #3  0x0000561d2d2905e0 OsAbort (Xorg + 0x1535e0)
                                                               #4  0x0000561d2d291a4b FatalError (Xorg + 0x154a4b)
                                                               #5  0x0000561d2d298556 n/a (Xorg + 0x15b556)
                                                               #6  0x00007f9399a02ab0 n/a (libc.so.6 + 0x39ab0)
                                                               #7  0x00007f9399a5226c n/a (libc.so.6 + 0x8926c)
                                                               #8  0x00007f9399a02a08 raise (libc.so.6 + 0x39a08)
                                                               #9  0x00007f93999eb538 abort (libc.so.6 + 0x22538)
                                                               #10 0x00007f9396a9acec n/a (crocus_dri.so + 0x9acec)
                                                               #11 0x00007f9397ac54ec n/a (crocus_dri.so + 0x10c54ec)
                                                               #12 0x00007f9396ca9f26 n/a (crocus_dri.so + 0x2a9f26)
                                                               #13 0x00007f9398c88dc0 n/a (libglamoregl.so + 0xcdc0)
                                                               #14 0x00007f9399fda117 n/a (modesetting_drv.so + 0xa117)
                                                               #15 0x0000561d2d1b93f4 BlockHandler (Xorg + 0x7c3f4)
                                                               #16 0x0000561d2d28b747 WaitForSomething (Xorg + 0x14e747)
                                                               #17 0x0000561d2d17b38f n/a (Xorg + 0x3e38f)
                                                               #18 0x00007f93999ec850 n/a (libc.so.6 + 0x23850)
                                                               #19 0x00007f93999ec90a __libc_start_main (libc.so.6 + 0x2390a)
                                                               #20 0x0000561d2d17c4a5 _start (Xorg + 0x3f4a5)

By all means, it shouldn't land with these quirks. Unless somebody can reliably track them down.

For example, graphics mode select only goes up to [Enabled, 128MB] on my motherboard bios. But from the registers doc I know 256MB should also be a thing (which seems indeed exactly what one of the comments in my links above mentioned too).
It doesn't seem like a big deal once I can also select [Maximum DVMT] anyway, yet nobody here seems to have checked this.
(I could probably try to hack my bios to force GMS on 0x9, but frankly it seems too much for too little)

[denisandroid]

I came across your topic by accident.

I have an old LG R510 on GM45 with a hacked (essentially) BIOS (from which you can switch the graphics size, but I haven’t heard about the 256MB mode), kernel 6.6.2, Intel P9700, 8GB of RAM, with Archlinux and the libva-intel-driver-g45-h264(AUR).

I have never really tested the actual operation of h264 decoding, so I decided to check (since I found your topic) through vlc and a 1080p video test.

The video plays, there are errors in the terminal, the processor is not heavily loaded, sometimes there may be an artifact when rewinding the video, but in general everything is fine (I also know that h264 encoding will definitely not work adequately with this driver).

If additional tests are required, I can provide more.

[mirh]

To be super duper fair, my P5QPL-AM is powered by a G41 (which has a X4500, not a full-ass 4500MHD).
So maybe that's my biggest hurdle, if (I seem to understand) you didn't set the 256MB mode and still everything was good.

p.s. hw-accelerated encoding was only added in sandy bridge

[denisandroid]

"p.s. hw-accelerated encoding added only to Sandy Bridge":
Yes, I know that, it was meant that if you use any video rendering program for Linux and use h264 as the encoding (with vaapi under gm45), the video will definitely come out broken.

As for the BIOS, initially there was nothing in it, and then I started hacking it and it turned out that there was nothing there except engineering things. And I tried all possible settings in it, and it was so long ago that I don’t even remember about video graphics, but I left the DVMT item blocked (it seemed to be faulty).

And as far as I know, DVMT was installed automatically (in this BIOS) depending on the RAM, you will have to try to somehow remove the RAM and check again. (And the “pre-allocated memory (32/64/128 MB)” item worked fine and I left it.)

[mirh]

Yes, I know that, it was meant that if you use any video rendering program for Linux and use h264 as the encoding (with vaapi under gm45), the video will definitely come out broken.

I only see VAEntrypointVLD entries in your vainfo output. That def shouldn't be happening?
(putting aside that the datasheet flexes about some kind of "video encode acceleration")

(And the “pre-allocated memory (32/64/128 MB)” item worked fine and I left it.)

I see.. So maybe the big crux isn't even allocated memory (save perhaps for very stupidly low quantities?) but just me having Eaglelake instead of the full Cantiga. a X4500 instead of X4500HD? Assuming no weird stepping voodoo.

G45 is what allowed them to handwave in the docs that there isn't any significant decoding difference between the two gen 4.5 generations, meanwhile the marketing material was always tiptoeing around the fact that H264 acceleration is just "partial" for the lower-end skus (either by claiming that only 1080p isn't feasible, by winking that blu-ray playback depends on "system configuration", by neglecting to mention what codec was effectively possible to fully accelerate, or by calling it a day already with just motion compensation like they had done with G35 and VC-1).
And perhaps @xhaihao was too much in a hurry to remember them? I don't see any check besides simple "g4x" mentions.

Otherwise I don't really have any other theory to explain these differences.

[BigCojones]

I absolutely love this thread and you guys. :D

I recently got my hands on a laptop with this chipset, well to be precise the GL40. But I think it is the Cantiga 4500MHD (or 4500M, there is some conflicting info on the web...) But this ticket would most likely affect this chipset.

I upgraded the cpu to a t8300 and ram to 6gb and started testing how usable this hw is ar rhis time.

I can get youtube 720p30 processor @about 40%, 720p60 processor @about 60-70%, 1080p30 and cpu is jumping between 70-90% and it only gets a little choppy @1080p60 (Cpu full load), but IT'S SO CLOSE. Intel gpu top shows much 3d rendering, but no video... I guess you guys get the same thing... And undoubtedly proper video decoding would push it over the edge. Now obviously i don't want to blast the cpu @100% for some video and the fans blazing. So any improvement would be greatly appreciated and would make this laptop all that anyone (at least myself would ever need)...

I was thinking about switching to arch to get that patched driver, but i might as well try to build it with this to test if that helps anyone. Running kernel 5.15 zorin lite 16.3.

All in all I wanted to add myself to this thread, to see where it goes in the future. This hardware is completely usable, still...

[BigCojones]

EDIT: There was no build instructions and was trying to build it through the typical ./configure, make way which ended in errors, but finally realized I need to be using Meson... So will report back soon...

Ok, so after using Meson, I got it to build. I had to build the older 2.4.0. package, because there was some incompatibility with the VAdriverinit function version or something, so vainfo was throwing errors... I copied the driver to my dri folder and with the 2.4.0. package i get:

But I'm not seeing any difference. I'm not able to get any movement in the intel_gpu_top video/0 indicator, no matter what i do. All i get is 3d rendering...

[mirh]

Docs say you may need --vo=gpu or --vo=vaapi too.
Also, you might want to try --hwdec=vaapi-copy.

EDIT: and you could try some other (progressive?) video, even my nvidia card on windows somehow didn't felt like wanting to accelerate 1080i-25-H264.mkv