Nvidia GT 1030, Will it Work?

  • Hey all,


    I guess I'm a little bit behind the times, as I am still running OpenELEC on my HTPC's and hadn't heard of LibreELEC until about 5 minutes ago.


    I thought the OpenELEC releases had slowed down, and now I know why. :p


    So, I used to roll my own Kodi installs ontop of barebones desktop-less Ubuntu distributions directly starting into Kodi ontop of Openbox. This wasnt always the most stable solution, and since Kodi serves both as our media library, PVR anfd LiveTV viewer (via MythTV plugin) my significant other was getting awfully tired of her TV Shows crashing to console.


    That's when I started using OpenELEC as it got more testing and was more stable. I ran it with a GT 720 for some time and this worked great until recently, when I needed to play 4k HEVC content. The GT 720 is stuck on VDPAU Feature Set D, and thus cannot decode HEVC content. 1080p 24hz HEVC content can be handled by the CPU (a Haswell based i5-4570T), but anything above that and the box starts to struggle.


    So, I just ordered a used GT 1030 on ebay so I can make the jump to VDPAU Feature Set H and get some of that HEVC hardware decoding goodness. That's when I noticed that OpenELEC 8.04 is stuck on older Nvidia drivers 375.39, about 4 months before the GT 1030 was released.


    Can anyone tell me what the Nvidia driver on the latest stable LibreELEC release is? Should my GT1030 work?


    Also, am I in for any surprises switching from OpenELEC to LibreELEC? The wikipedia page mentioned that OpenELEC was foked into LibreELEC over "creative differences" but it didn't provide any details as to what those were.


    I appreciate any input! :)

  • LE 8.2.5 has Nvidia 390.42, but I am not sure hevc will work with your 1030. And a 1030 will never be able to do HDR, because you need at least 3GB.

  • 8-bit HEVC will work. You will need Windows for 10-bit HEVC.

    Thanks, I read this on the Wikipedia page for VDPAU.


    When I did I assumed that most HEVC content was encoded in 8bit and that 10 bit was pretty rare. Was this an incorrect assumption?

  • Some people even encode h264 in 10bit, although the outcome is rarely any better.

    It all depends on the source video and its recode. I prefer a good quality 8bit video over a 10bit crap quality video.

    The 1030 can do up to 8K resolution, but in Linux/LibreELEC unfortunately only with 8bit.

  • Some people even encode h264 in 10bit, although the outcome is rarely any better.

    It all depends on the source video and its recode. I prefer a good quality 8bit video over a 10bit crap quality video.

    The 1030 can do up to 8K resolution, but in Linux/LibreELEC unfortunately only with 8bit.


    Ahh. So how are people doing this these days? The on board GPU's in newer Intel CPU's?


    I tried using both on board AMD and Intel GPU's for my HTPC experience when I first started out rolling my own Kodi on top of Ubuntu, but I eventually switched to Nvidia and VDPAU, because the MythTV frontend plugin kept crashing to the console with both AMD and Intel GPU's. They would work perfectly in content from my media library, but could not deal well with either live or recorded TV content.


    This problem completely disappeared with VDPAU.

  • Ahh. So how are people doing this these days? The on board GPU's in newer Intel CPU's?


    Either using Intel, which seem to do pretty okay, or by using the 'cheap China' AMlogic boxes, which have their own tricks up their sleeves. AMD Ryzen hardware is still too new for Linux support.

  • I would advise against nvidia purchases. Long-term LE/Kodi support for nVidia GPU's is questionable due to nVidia (again) choosing to set their own 'standard' instead of following the one used by literally everyone else. I'll be writing a blog post about them soon.

  • I would advise against nvidia purchases. Long-term LE/Kodi support for nVidia GPU's is questionable due to nVidia (again) choosing to set their own 'standard' instead of following the one used by literally everyone else. I'll be writing a blog post about them soon.

    Hmm.


    That's disappointing.


    I first started using Nvidia GPU's for Kodi due to a combination of things, one being crashes to desktop when using both AMD and Intel GPU's when watching LiveTV or recordings via the MythTV plugin (local media library file playback worked fine though) and another being - back at the time - a lack of true support for 23.976hz video playback.


    VDPAU and Nvidia GPU's solved this for me.


    It would certainly be simpler to use an on board GPU in a home theater box, but the downside would be that whenever a new video standard comes out, you need a new motherboard and CPU (and possibly even RAM) rather than just buying a cheap entry level video card.


    I have three kodi boxes running in my house, my main one is a Haswell i5-4570T with a Geforce 720GT (soon to be 1030 GT) and the two others are Haswell Celeron G1840's one with a Geforce GT720 and one with a GT630.


    To get to HEVC decoding I'd need to buy three new motherboards, three new cpu's, and since these are all DDR3 systems, I'd also need to buy DDR4 ram for each of them. What a pain. Would be much easier to drop whatever the latest low end Nvidia GPU is into them and call it a day.

  • LE 9.0 still supports nVidia under X11 with the binary blob drivers which provide VDPAU; so everything is 8-bit and no HEVC because nVidia stopped developing VDPAU some time ago. AMD rewrote their formerly VDPAU using drivers to use VAAPI (common with Intel). Kodi v18 is currently broken with VDPAU due to X11 windowing code changes but the main developer that supports X11 has indicated he plans to fix VDPAU support when a replacement test box arrives. Current hardware had some issues and was terminated with a pickaxe. No joke, we have video :)


    LE 10.0 (Kodi v19 so still a long way off) will drop X11 completely and switch to DRM/GBM and KMS (running on the framebuffer, no X11). This works well with Intel/AMD (which dominate user choices) but currently has zero support for nVidia chips because nVidia is solo-championing their EGL streams alternative to GBM buffer sharing. The two current problems are: a) VDPAU is dead code and right now there's zero appetite from Kodi developers to add another proprietary code path for a closed source driver when *all* other GPU/SoC types we plan to support in the future use GBM/KMS, and b) we had a look at EGL streams recently and it failed to run due to nVidia driver bugs. There is a lot of time to kill before LE 10.0 is a serious proposition and we'll maybe look at EGL streams again, or maybe nVidia comes to their senses and uses the same rendering standard as everyone else?


    in the long-term cheap 'Android' boxes/boards will be better all round value for client boxes than x86 kit, except for boxes used as PVR servers, but those don't always need to run Kodi or have the latest GPU in them.

  • LE 9.0 still supports nVidia under X11 with the binary blob drivers which provide VDPAU; so everything is 8-bit and no HEVC because nVidia stopped developing VDPAU some time ago. AMD rewrote their formerly VDPAU using drivers to use VAAPI (common with Intel). Kodi v18 is currently broken with VDPAU due to X11 windowing code changes but the main developer that supports X11 has indicated he plans to fix VDPAU support when a replacement test box arrives. Current hardware had some issues and was terminated with a pickaxe. No joke, we have video :)


    LE 10.0 (Kodi v19 so still a long way off) will drop X11 completely and switch to DRM/GBM and KMS (running on the framebuffer, no X11). This works well with Intel/AMD (which dominate user choices) but currently has zero support for nVidia chips because nVidia is solo-championing their EGL streams alternative to GBM buffer sharing. The two current problems are: a) VDPAU is dead code and right now there's zero appetite from Kodi developers to add another proprietary code path for a closed source driver when *all* other GPU/SoC types we plan to support in the future use GBM/KMS, and b) we had a look at EGL streams recently and it failed to run due to nVidia driver bugs. There is a lot of time to kill before LE 10.0 is a serious proposition and we'll maybe look at EGL streams again, or maybe nVidia comes to their senses and uses the same rendering standard as everyone else?


    in the long-term cheap 'Android' boxes/boards will be better all round value for client boxes than x86 kit, except for boxes used as PVR servers, but those don't always need to run Kodi or have the latest GPU in them.

    I did not realize VDPAU ceased development. That is a shame. At one time it was the preeminent hardware acceleration for video decode under linux.


    Honestly, I would love to go to an android system, but the problem is last time I checked there was no ARM support for some of the plugins I depend on (notably the mythtv PVR frontend)


    That could have changed though, I haven't looked in some time. Maybe by the time LE10 comes out I'll be able to switch. Time will tell. If that happens, I will miss building my own boxes and instead relying on little consumer devices.

  • I can't speak for the Kodi Android repo but the pvr.mythtv frontend is both our 8.2 and 9.0 repos for a number of ARM devices.

  • I can't speak for the Kodi Android repo but the pvr.mythtv frontend is both our 8.2 and 9.0 repos for a number of ARM devices.

    Good to know, thank you.


    This definitely wasn't the case when last built all of my HTPC boxes (two Haswell Celeron G1840's with GT 720's for bedroom and guest room, and Haswell i5-4570 recently upgraded to GT 1030 in my livingroom.


    The GT1030 is installed and running with latest stable LibreElec now. Does quite well in 8bit HEVC, but as mentioned, does not help with 10 bit. Looks like a lot of 4k blurays are compressed with 10bit HEVC, which is kind of a bummer.

  • There is some interesting discussion about NVDEC and how it is supported in FFMPEG now over here.


    Looks like it would be the way to go, but FernetMenta doesn't seem to have much interest, which is a shame.


    You'd think with support in FFMPEG, most of the heavy lifting would already have been done...