Hardware HDR tonemapping still broken on 1.31.0.6654

Folks,

Battling flu. Here we are. N5105, on a QNAP (which is more constrained than Ubuntu)

This is using the Engineering development build 1.31.2.6715 I have linked above.

[/share/Public] # uname -a
Linux QNAP-TS264 5.10.60-qnap #1 SMP Thu Jan 12 01:03:21 CST 2023 x86_64 GNU/Linux
[/share/Public] # cat /proc/cpuinfo | grep 'modeldecoder information: 249
decoder information: 249

[/share/Public] # uname -a
Linux QNAP-TS264 5.10.60-qnap #1 SMP Thu Jan 12 01:03:21 CST 2023 x86_64 GNU/Linux
[/share/Public] # cat /proc/cpuinfo | grep 'model name' | uniq
model name	: Intel(R) Celeron(R) N5105 @ 2.00GHz
[/share/Public] # 

I’m waiting for some help to restart the J4005 machine (it failed to reboot for me)

Followup:

[/share/Public] # uname -a                    
Linux QNAP-TS262 5.10.60-qnap #1 SMP Thu Jan 12 01:03:21 CST 2023 x86_64 GNU/Linux
[/share/Public] # cat /proc/cpuinfo | grep -i 'model name' | head -1
model name	: Intel(R) Celeron(R) N4505 @ 2.00GHz
[/share/Public] # 

Thank you for your reply and for the swift testing! I hope that flu is outta there quickly, they are never fun.

I’m not quite sure what you are trying to show here. The two processors you’ve tested (N5105 and N4505) are a different generation GPU to the J5005. The J5005 has a gen 9 UHD Graphics GPU, from my understanding the ones you’ve used there are gen 11 GPUs.

They do however, have very similar hardware video decoding/encoding abilities. The only difference I could find was max L5.1 (gen 9) vs L5.2 (gen 11) support for AVC.

After @premikkoci mentioned their last working version, I swapped the Plex version I was testing with to version 1.29.0.6244, HW transcoding for tonemapping worked immediately (see screenshot below). To me it seems like something has changed in how Plex recognises the J5005’s capabilities since 1.29.0.6244.

From a detection standpoint, they aren’t different. AVC capability is, for sake of ā€œCan it transcode HEVCā€, immaterial. True?

I’m not sure, but something is different though. There are three cases here where PMS 1.31.2.6715 is not recognising the J4105/J5005* as being able to do tonemapping on HW, where it is correctly doing so on PMS 1.29 .

Note that 1.31.2.6715 does recognise the HW transcoding ability for non-HDR content so the hardware is being picked up, just not the tonemapping ability.

You mentioned here you have a J5005 in the lab, is it possible to test using that? Mine was a simple docker setup with the offical PMS images, it doesn’t seem like Unraid is the issue.

*UHD 600/605 GPU respectively, they share the same Quick Sync capabilities.

So I tried to replicate this on my box using PMS 1.29.0.6244. Specifically I used this image: ghcr.io/linuxserver/plex:version-1.29.0.6244-819d3678c. Hardware tonemapping is still broken for me using this image. Disabling HDR tonemapping allows hardware transcoding to proceed. Mind sharing which specific image you used? I want to try to confirm that HW transcoding with HDR tonemapping is possible on my system.

I am in error. Currently in the lab at my disposal are:

  • Intel(R) Celeron(R) N5105
  • Intel(R) Celeron(R) N4505

Separately,

I have UNRAID now (and stable) on an KabyLake (i3-7300U)

  • General bit-rate reduction transcodes appear fixed but I’ve not tested exhaustively

PMS on my Ubuntu / Xeon / P2200 – much more stable

I’m learning the transcoder as fast as I can.

It looks like it’s using the equiv of lspci -v to see what ā€œdisplayā€ hardware shows up

[chuck@lizum ~.2042]$ sudo lspci | grep -i display
00:02.0 Display controller: Intel Corporation HD Graphics 630 (rev 04)
[chuck@lizum ~.2043]$ 

From there, it goes into it and gets ID info.
At top of your PMS logs, you’ll see where it’s looking at PCIIDs and ā€œpreemptively loadingā€ when it finds what it recognizes.

Example:

Feb 22, 2023 20:59:06.230 [0x1514f1426b38] DEBUG - [GPU] Got device: HD Graphics 620, intel@builtin, default true, best true, ID /dev/dri/renderD128, DevID [8086:5916:8086:2068], flags 0x67
Feb 22, 2023 20:59:06.230 [0x1514f1426b38] INFO - Preemptively preparing driver icr for GPU HD Graphics 620

Would you all with the residual failures please check your logs (immediately after startup) for this message?

@matthe6038 I used the official Plex image in this case to keep things simple here.

I did see some people have issues with HW acceleration and the Linuxserver images in the past though.

Thanks again for getting on this @ChuckPa. This is what shows up in my logs on startup (both using official Plex docker images):

Plex 1.29.0.6244 — HW tonemapping does work :white_check_mark:

Feb 23, 2023 16:43:13.185 [0x7ff42bdffb38] WARN - [GPU] Failed to load PCIID map: Failed to locate a readable PCIID database
Feb 23, 2023 16:43:13.185 [0x7ff42bdffb38] DEBUG - [GPU] Got device: , intel@builtin, default true, best true, ID /dev/dri/renderD128, DevID [8086:3184:1028:080c], flags 0xce
Feb 23, 2023 16:43:13.185 [0x7ff42bdffb38] INFO - Preemptively preparing driver icr for GPU 

(I’m not sure why the colors in the formatting below are different)

Plex 1.31.2.6715 (updated inside the container) — HW tonemapping doesn’t work :x:

Feb 23, 2023 16:48:05.889 [0x7facb73ffb38] DEBUG - [GPU] Got device: GeminiLake [UHD Graphics 605], intel@builtin, default true, best true, ID /dev/dri/renderD128, DevID [8086:3184:1028:080c], flags 0x67
Feb 23, 2023 16:48:05.889 [0x7facb73ffb38] INFO - Preemptively preparing driver icr for GPU GeminiLake [UHD Graphics 605]

Interestingly, the earlier working version doesn’t appear to actually detect the specific GPU model. But there is a difference, which is something I hope.

Let me know if there is anything else I can look at or test.

Adding:
My system reports the GPU as

VGA compatible controller: Intel Corporation GeminiLake [UHD Graphics 605] (rev 03) (prog-if 00 [VGA controller])

The KabyLake (i3-7300U) system you mentioned appears to have the same Quick Sync features according to this.

On 1.31.0.6654:

Feb 23, 2023 10:50:26.185 [0x14c147a64b38] WARN - [GPU] Failed to load PCIID map: Failed to locate a readable PCIID database
Feb 23, 2023 10:50:26.185 [0x14c147a64b38] DEBUG - [GPU] Got device: , intel@builtin, default true, best true, ID /dev/dri/renderD128, DevID [8086:3184:1028:080c], flags 0xce
Feb 23, 2023 10:50:26.185 [0x14c147a64b38] INFO - Preemptively preparing driver icr for GPU

On 1.31.2.6715:

Feb 23, 2023 10:59:52.980 [0x151e02b91b38] DEBUG - [GPU] Got device: GeminiLake [UHD Graphics 605], intel@builtin, default true, best true, ID /dev/dri/renderD128, DevID [8086:3184:1028:080c], flags 0x67
Feb 23, 2023 10:59:52.980 [0x151e02b91b38] INFO - Preemptively preparing driver icr for GPU GeminiLake [UHD Graphics 605]

Is it correct to say we are down to:

J50xx and J40xx CPUs not working correctly ?

@ChuckPa From what I’ve seen in this thread and elsewhere online, I believe it’s specifically the J5005 and J4105 CPUs. These are both very similar processors sharing the Gemini Lake architecture.

@matthe6038 both the J5005 and J4105 are very similar chips. The GPU and Quick Sync features appear to be identical.

I think so yes. Well, more specifically:

  • Recent versions of Plex (after 1.29.0.6244) don’t seem to recognise some of the capabilities of the UHD 600* and UHD 605 GPU**, where it did in the past
  • Most of HW Quick Sync features are picked up and function in Plex (H264/HEVC decoding/encoding), but HW tonemapping doesn’t

*Intel J4005 CPU
**Intel J5005 CPU

Let me try one more assertion (hoping that holds true)

  1. GeminiLake CPUs can hardware transcode.
  2. GeminiLake CPUs cannot hardware tone map.

If this is indeed true, we’ll turn on Transcoder VERBOSE logging and grab all that data for engineering (We’ll need to prep for it as the normal log buffer size won’t hold it)

Regarding ā€œrecent versionsā€,

  1. 1.29.2 was ā€˜everything working, pre update’
  2. 1.30.x was ā€˜where it broke. post update’
  3. builds we have now – testing as engineering works through it.

Yes I think this is all true - the only thing I would add is that it looks like @trollop_earthly_hassock had everything working with 1.29.0 rather than 1.29.2.

If I tell engineering that ā€œ1.29.0ā€ works – I’ll get told to prove it and then be ā€˜volunteered’ to identify and vet all the changes between 1.29.0 and now. If the transcoder were my specialty … I’d be working directly on this. (… and I’m glad I’m not because inheriting someone else’s code is not fun. :rofl: )

I think the best approach here is to say:

  1. With this CURRENT build,
    – This is still not working
    – That is still not working
    – etc

  2. Let Engineering figure out what they did or didn’t

I totally agree! Just wanted to clarify on your last post that listed 1.29.2. But yeah just tell engineering it’s not working on current version. Please let us know if there’s anything you need us to test. I’m happy to do whatever.

HW transcoding works just fine but hw hdr tone mapping does not. In my case the last version with working hw hdr tonemapping is 1.29.0

Unraid 6.11.5 (kernel 5.19.17).

@matthe6038

FYI:

No promises yet but looking promising.

The engineer found where it’s having issues.

I was told what initial thoughts are about how to resolve.

I will update as I learn more

3 Likes

@ChuckPa Great news! Thanks for taking the time to troubleshoot this for us, looking forward to the next update.

1 Like