I'm not really sure about this. Last time I tested my gemini lake hardware enabled 12bit output.
I was talking about 50/60Hz 4K modes. 12-bit works with 2160p/24/30Hz.
I'm not really sure about this. Last time I tested my gemini lake hardware enabled 12bit output.
I was talking about 50/60Hz 4K modes. 12-bit works with 2160p/24/30Hz.
Sorry for the confusion. The first part of post was yes off topic but was mentioned earlier on here so thats why I asked it. Plus there are alot of HDR experts here, case in point read noggin's response.
The 2nd part of the post IS on topic as its related to the NUC's having issues with audio as I and others have mentioned multiple times in the past. I haven't had a chance to test the image so was curious if the intel driver bug has been ironed out.
Sorry for the confusion. The first part of post was yes off topic but was mentioned earlier on here so thats why I asked it. Plus there are alot of HDR experts here, case in point read noggin's response.
The 2nd part of the post IS on topic as its related to the NUC's having issues with audio as I and others have mentioned multiple times in the past. I haven't had a chance to test the image so was curious if the intel driver bug has been ironed out.
Concerning HBR audio passthrough I can only report my own experiences with my NUC8i5BEH.
It works perfectly as far as I can hear without any flaws. No audio dropouts or stuttering. Only clean sound.
That‘s true for the testbuild from post #502 and the nightlies (up to 20210327) I tried. My Yamaha AVR reports every sound format (e.g. DTS HD MA or Dolby TrueHD) correctly. YMMV with other NUCs.
I was talking about 50/60Hz 4K modes. 12-bit works with 2160p/24/30Hz.
That's good progress - ISTR that in the earlier days it was 8-bit + dither for <50Hz 2160p modes too. I guess this is with RGB or YCbCr 4:4:4? (And not 4:2:2 ?)
For 2160p50 and above, if 4:2:2 isn't supported, then 4:2:0 will be the only HDMI 2.0 option for >8 bit output I guess (as 4:4:4/YCbCr is 8-bit only at 2160p50 and above in the specs - you have to use 4:2:0 or 4:2:2 for >8-bit output at 2160p50 and above)
Concerning HBR audio passthrough I can only report my own experiences with my NUC8i5BEH.
It works perfectly as far as I can hear without any flaws. No audio dropouts or stuttering. Only clean sound.
That‘s true for the testbuild from post #502 and the nightlies (up to 20210327) I tried. My Yamaha AVR reports every sound format (e.g. DTS HD MA or Dolby TrueHD) correctly. YMMV with other NUCs.
I'll try it out. Maybe I'll have sometime this weekend.
My ODROID-H2+ (Gemini lake) continues to have audio glitch in it.
There is a NUC8i3BEK at my parents house, will be there tomorrow so will test the build on that next.
There is a NUC8i3BEK at my parents house, will be there tomorrow so will test the build on that next.
Should work like mine.
The only difference I know between the NUC of your parents and my NUC is the CPU and the height of the case. Mainboard and graphics are AFAIK the same.
Did anyone try retro gaming on my builds?
I remember there were no issues when I tried some Sega/SNES roms about a year ago.
With current Kodi master I get some serious texture glitches/stuttering. This is something specific to GBM/GLES as official nightlies don't have this issue. Tried to revert some GBM/GLES related commits but can't figure out when the issue started.
Im still building off matrix/9b4db0e hasn't got the stutter issue if that helps
Interesting. I just built matrix/9b4db0e and glitches are still there. Can you upload your build?
I am still using the patch you supplied in January
Dropbox - LibreELEC-Generic.x86_64-9.80.img.gz - Simplify your life
Same issue with your build too. Side-scrolling games look jerky:
I see what you mean. Do you see this in movies as well ?
No, it's only in games. Video and GUI is fine.
I found what's causing graphic glitches in retroplayer. It's something in kernel config options.
No more glitches after I built kernel 5.10 using an older linux.x86_64.conf file from kernel 5.6 (~May 2020).
Will try to figure out what option is causing it.
Do you have enough CMA? We specify to allocate 256MB.
Otherwise you can try disabling the DMAHEAPS registration by removing this line
xbmc/WinSystemGbmGLESContext.cpp at master · xbmc/xbmc · GitHub
Do you have enough CMA? We specify to allocate 256MB.
I did not change CMA: