Sorry, I should have been more specific. I can only confirm that this update does not fix the issue with the J5005 cpu specifically, which has the UHD605 iGPU. Since it’s so similar to the others, I assumed that they would not work either. So far no one has responded to this thread to report on the J4105, N5105, or N5095 with the update you just posted.
I assume the UHD605 is very similar to the UHD600, but maybe the slight difference is why it’s not being recognized?
It’s recognized fine.
The moment it attempts to HDR tone map – OpenCL fails.
PMS immediately falls back to Software everything
Excuse me? I’ve reported on this multiple times.
Where the H did that come from?
NOW - go look at GitHub - intel/media-driver: Intel Graphics Media Driver to support hardware decode, encode and video processing.
LOOK AT “Video Processing Features”
HDR10 TM (Tone Mapping)
Does it list the JasperLake / Elkhart Lake?
Now do you see the ambiguity and confusion?
@pshanew I don’t see any posts from you after @ChuckPa posted the developer build in this post: Hardware HDR tonemapping still broken on 1.31.0.6654 - #131 by ChuckPa
Have you tested?
Where did what come from?
It tells me which codecs are expected to be supported for hardware acceleration. It also tells me that we shouldn’t expect hardware accelerated tone mapping (per the second table).
However, as I mentioned, this does not, at least in my environment, preclude hardware accelerated transcoding from working.
I’m not sure what you’re trying to point out with your subsequent statements, but nothing I stated above suggests anything other than what I just said. You specifically mentioned that the UHD Graphics moniker didn’t tell you anything, I was trying to help clear that up for you.
I’d be happy to have a sidebar in a PM if you’d like to discuss this further, but understand that I’m trying to help by sharing my positive experience with this hardware. There’s no need to pick apart my statements to try to find faults. I know exactly what works at this point.
My apologies. In my haste I mixed up this thread and another.
Extensively.
Haha no worries. I guess you’re suggesting that we shouldn’t expect HW tone mapping to work? I guess my counter is - it used to work on plex version 1.29, and now it doesn’t. At least with the J5005.
Edit: wait now I get it. How it should work: HDR tonemapping will happen in software while transcoding will happen in hardware. Except for some reason that’s not happening, and everything is being done in software. That’s the bug. Do I have that right?
Will it work again? YES.
PMS 1.30.0 was a full, hard , FFMPEG bump.
Intel Media Driver was a full update with this release.
we finished the the one, which preceded these CPUs for years, earlier today.
The last item on the list are these CPUs. JSL / EHL CPUs
Take the victory before shooting the messenger ?
@ChuckPa and GeminiLake! Just want make sure that wasn’t missed haha. Thx for your hard work!
The J5005 is a Gemini Lake-based processor. The second table in the Intel/media-driver link I posted above suggests that there is no support for hardware accelerated HDR tone mapping with that processor. It doesn’t however mean that hardware accelerated decoding and encoding won’t work for such media.
I can’t test with a J5005, only an N5105. And that’s exactly what I see; when tone mapping is enabled, it is performed by the CPU while decoding and encoding is performed by hardware.
@ChuckPa Just so there’s no confusion, I was responding to @pshanew with my post about 1.29, not you. Not trying to shoot any messengers!
Right, so when I enable tone mapping on the J5005, everything is done in software. The iGPU sits totally idle. So not even the encoding and decoding are done in hardware, unless disable tonemapping. Sounds like yours behaves differently.
Let me play Village Idiot here (not hard to do right now) 
Indeed.
I’ve not dug through all the previous comments in this thread, but did you ever provide debug logs showing that specific scenario? I’d be happy to take a look to compare it to what I saw before working out my issues. In my specific case, I had to manually enable GuC/HuC (HuC low-power encoding disabled by default on kernel > 5.8) loading. I also had to manually download the GuC firmware since the linux-firmware package was not up-to-date at the time.
The short version is that there are some kernel/firmware/driver interactions which aren’t well (understood?) documented at this time which can affect how Plex performs.
Yes I provided them here: Hardware HDR tonemapping still broken on 1.31.0.6654 - #132 by matthe6038
That scenario makes sense, given how much of a pain in the ass it’s been to nail down this bug lol. Some sort of weird interaction.
I have not tried H264 → H264, but the above scenario works for H265 → H264. Just doesn’t work when tone mapping is enabled.
Let’s piece this together?
If so, Per the documentation which implies these chips have no OpenCL Tone map capability ?
IFF and Therefore — I know what needs to happen (which i’ll confirm with the developer)
it probes for HEVC HDR for the decode and gets it
Probes for the H264 for the encode and gets it
Starts the job.
Chip blows out because there is no OpenCL capability.
HYPOTHESIS – PMS reverts to FULL SOFTWARE instead of dropping the tone mapping .
Yes?
@ChuckPa YES. Yes to all of that. I think you’re onto the answer.
Thank you.
See, even the old guy can come up with the right answer every now and then 
I’ll talk to the dev.
If you can grab me DEBUG logs which demonstrate this, that would be ideal.
(She likes seeing proof of behavior in logs)
