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.

[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