Bug #2076361 “Lenovo X12 Detachable Gen 2 unresponsive under lig...” : Bugs : linux package : Ubuntu

Revision history for this message

Gustavo Niemeyer (niemeyer) wrote on 2024-08-08:

#1

uname-a.log Edit (123 bytes, text/plain)
Dependencies.txt Edit (4.0 KiB, text/plain; charset="utf-8")
ProcCpuinfoMinimal.txt Edit (1.7 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (109 bytes, text/plain; charset="utf-8")

Revision history for this message

Gustavo Niemeyer (niemeyer) wrote on 2024-08-08:

#2

version.log Edit (38 bytes, text/plain)

Revision history for this message

Gustavo Niemeyer (niemeyer) wrote on 2024-08-08:

#3

dmesg.log Edit (120.6 KiB, text/plain)

Revision history for this message

Gustavo Niemeyer (niemeyer) wrote on 2024-08-08:

#4

lspci-vvnn.log Edit (42.8 KiB, text/plain)

Gustavo Niemeyer (niemeyer) on 2024-08-08

Changed in linux-signed (Ubuntu):
assignee:	nobody → Andy Whitcroft (apw)

Gustavo Niemeyer (niemeyer) on 2024-08-09

description:

updated

Revision history for this message

AaronMa (mapengyu) wrote on 2024-08-15 (last edit on 2024-08-15):

#5

Hi niemeyer,

I tested ffmpeg for encoding hevc_vaapi and h264_vaapi, but not reproduced the issue on ThinkPad X1 with Intel(R) Core(TM) Ultra 7 165U.
My environment:
Ubuntu 24.04 LTS
ffmpeg version 6.1.1-3ubuntu5
6.8.0-40-generic

$ ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i INPUT -vf 'scale_vaapi=format=p010' -c:v hevc_vaapi -profile 2 -b:v 15M output.mp4

From the attached log, there is no obviously error in dmesg,
was it recorded after the issue is duplicated?

Could you check the status as following while encoding?
And attach the dmesg after the issue is duplicated?

$ sudo apt install intel-gpu-tools lm-sensors

Now we need 3 windows to show the status of system:
1, $ sudo watch -n1 sensors
2, $ watch -n 1 "grep \"^[c]pu MHz\" /proc/cpuinfo"
3, $ sudo intel_gpu_top

Then start encoding as the command above.
My result is like following:
intel_gpu_top will show the video engines usage is high like 40%.
The cpu temperature is around 60 and cpu usage around 30%.

Revision history for this message

Gustavo Niemeyer (niemeyer) wrote on 2024-08-15:

#6

Thanks for the reply, Aaron.

The dmesg.log file is already attached above.

Your ffmpeg example is on the simple side compared to the pipeline that creates the issue for me, where ffmpeg has multiple inputs and a pipeline that touches both the GPU and the CPU. For simple things it works okay here as well.

intel_gpu_top spikes to 100% on both Render/3D and Compute with very brief interruptions, probably while it moves the frame for processing by the CPU. Blitter, Video, and VideoEnhance remains at 0%.

/proc/cpuinfo shows CPU comfortably alternating between 400MHz and 4GHz, apparently with plenty to spare and confirming the previous output provided by iostat and top in the original report above.

sensors output shows the temperature for all CPUs comfortably under 70 degrees at all times, with almost all of them under 60.

Revision history for this message

AaronMa (mapengyu) wrote on 2024-08-16:

#7

Hi niemeyer,

The issue should be caused by usage 100% of Render/3D.
Ideally, encoder should use Video/VideoEnhance only.

Could you share your script of ffmpeg?
I'd like to find a way to duplicate this issue.

Revision history for this message

AaronMa (mapengyu) wrote on 2024-08-16:

#8

100% usage of Render/3D means copy, vpp or display are stuck,
since multiple inputs are set, could it work when encoding a single input each time?

Maybe there is an unsupported video format input by Intel GPU decoder/encoder.

Otherwise, the ffmpeg parameter requests specific filter or scaling to render engine.

Revision history for this message

AaronMa (mapengyu) wrote on 2024-08-16:

#9

Or try to install non-free to support more video formats:

$sudo apt install intel-media-va-driver-non-free

Revision history for this message

Gustavo Niemeyer (niemeyer) wrote on 2024-08-16:

#10

> 100% usage of Render/3D means copy, vpp or display are stuck,

The issue is certainly related to the 100% render/compute, but this looks like a symptom and a consequence rather than a cause.

> since multiple inputs are set, could it work when encoding a single input each time?

Yeah, there are several ways to workaround it. But to be clear, the concern here is not that ffmpeg is slow, but rather that whatever is happening is taking the entire system down instead of gracefully degrading. Even keyboard input stops working.

> Maybe there is an unsupported video format input by Intel GPU decoder/encoder.

No, the input/output encoding/decoding is fine. It's using H265/HEVC, well supported by the chip.

I've done some more testing and bisected the problem to the following, with left.mp4 and right.mp4 being 4K videos.

This works fine, with Video fluctuating beteween 20 and 30%, Render close to zero:

```
ffmpeg -y \
        -vaapi_device /dev/dri/renderD128 \
        -hwaccel vaapi -hwaccel_output_format vaapi -i left.mp4 \
        -hwaccel vaapi -hwaccel_output_format vaapi -i right.mp4 \
        -filter_complex "
                [0:v]hwdownload,format=nv12,copy[v0];
                [1:v]hwdownload,format=nv12,copy[v1];
                [v0][v1]hstack=shortest=true,format=nv12,hwupload[out];
                " \
        -c:v hevc_vaapi -map "[out]" slowtest.mp4
```

This causes the issue, with Render at 100%, Video at 0%, system unresponsive:

```
fmpeg -y \
        -vaapi_device /dev/dri/renderD128 \
        -hwaccel vaapi -hwaccel_output_format vaapi -i left.mp4 \
        -hwaccel vaapi -hwaccel_output_format vaapi -i right.mp4 \
        -filter_complex "
                [0:v]hwdownload,format=nv12,copy,format=nv12,hwupload[v0];
                [1:v]hwdownload,format=nv12,copy,format=nv12,hwupload[v1];
                [v0][v1]hstack_vaapi=shortest=true[out];
                " \
        -c:v hevc_vaapi -map "[out]" out.mp4

```

The key difference between these two pipelines is whether hstack happens in the GPU or the CPU. When it works, two frames are downloaded from the GPU, stacked together, and the merged frame is then re-uploaded for encoding. When it breaks, the two frames are uploaded individually and stacked in the GPU instead.

The problem may be related to the amount of memory used in the GPU, since when the stacking happens in the GPU there is twice as much data. Even then, instead of degrading, the system came down to a halt with the GPU misbehaving, keyboard interrupts going wild, etc.

Anything else I can do to help diagnose why that's the case or whether we can address it?