Announcement

Collapse
No announcement yet.

OpenELEC 3.2 Packs In XBMC 12

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • OpenELEC 3.2 Packs In XBMC 12

    Phoronix: OpenELEC 3.2 Packs In XBMC 12

    OpenElect 3.2 is now available...

    http://www.phoronix.com/vr.php?view=MTQ2MTU

  • #2
    Interesting that they went with 3.10... sure that's UVD for Radeon, but you miss out on DPM which is important if you have an APU in your media center.

    Comment


    • #3
      We use fglrx only with XVBA for xbmc. OSS radeon with uvd still has some problems for us and directly fall through our tests.

      xbmc is fully 3D, e.g. OpenGL. The vdpau pixmap implementation is far too slow on the radeons, so we just could not replace it. 1080i50 or also 720p50, both LiveTV formats are currently unwatchable within xbmc.

      Old xvba (amd does not really care since two years) has API calls that directly work in OpenGL (e.g. TransferSurfaces), which makes xbmc performance by a factor 2.

      We will be the first, that will happily drop fglrx, if it is possible for our users.

      Comment


      • #4
        Originally posted by fritsch View Post
        We use fglrx only with XVBA for xbmc. OSS radeon with uvd still has some problems for us and directly fall through our tests.

        xbmc is fully 3D, e.g. OpenGL. The vdpau pixmap implementation is far too slow on the radeons, so we just could not replace it. 1080i50 or also 720p50, both LiveTV formats are currently unwatchable within xbmc.

        Old xvba (amd does not really care since two years) has API calls that directly work in OpenGL (e.g. TransferSurfaces), which makes xbmc performance by a factor 2.

        We will be the first, that will happily drop fglrx, if it is possible for our users.
        I'm glad to see there's a specific reason fritsch, but I also hope you're actively working with upstream on the problems youre facing

        Comment


        • #5
          Originally posted by fritsch View Post
          We use fglrx only with XVBA for xbmc. OSS radeon with uvd still has some problems for us and directly fall through our tests.

          xbmc is fully 3D, e.g. OpenGL. The vdpau pixmap implementation is far too slow on the radeons, so we just could not replace it. 1080i50 or also 720p50, both LiveTV formats are currently unwatchable within xbmc.

          Old xvba (amd does not really care since two years) has API calls that directly work in OpenGL (e.g. TransferSurfaces), which makes xbmc performance by a factor 2.

          We will be the first, that will happily drop fglrx, if it is possible for our users.
          Last time this came up, the radeon developers were on here asking what the problems were. They seemed to think they had spent some time looking at the xmbc codebase and thought it should all be working, and were hoping you guys would open up bug reports or let them know what was failing.

          I have no idea why they were doing that on phoronix forums instead of xmbc, but i guess maybe they tried that without response before?

          Comment


          • #6
            "OpenElect 3.2 is now available."

            not yet

            Comment


            • #7
              Originally posted by smitty3268 View Post
              Last time this came up, the radeon developers were on here asking what the problems were. They seemed to think they had spent some time looking at the xmbc codebase and thought it should all be working, and were hoping you guys would open up bug reports or let them know what was failing.

              I have no idea why they were doing that on phoronix forums instead of xmbc, but i guess maybe they tried that without response before?
              I really hope this can get worked out, deathsimple started to work on NV_vdpau_interop but has no time to finish it.
              http://lists.freedesktop.org/archive...st/043546.html

              Comment


              • #8
                I went into contact with both amd oss devs, exactly after the first bunch was merged. I really like how open we can now talk about driver / mesa / features and so on. I tried since more than 2 years with closed source fglrx people to get solutions (if you think that we did their job with implementing xvba). It was quite hard. But there are also quite a lot good guys, that really like to help, but sometimes can't.

                But I think it needs some time. mplayer was first and it works great. xbmc with its gl frontend is something special, that needs other handling.

                If you see what the oss devs did within 3 months, one can just bow before them and be thankful as much as possible. Really great.

                Comment


                • #9
                  Not an easy-to-install disro, I have a media center pc running xbmc 12.0 with Arch. I find it really suited because drivers are up-to-date and once the system is set up, they're a breeze to install and maintain, at least nvidia, dunno about AMD, just bought the cheapest card I could find in the store, 1080p working. AUR entry for XBMC user repositories so you get all the XBMC goodness you could ask for.

                  Comment


                  • #10
                    Originally posted by Laser View Post
                    Not an easy-to-install disro, I have a media center pc running xbmc 12.0 with Arch. I find it really suited because drivers are up-to-date and once the system is set up, they're a breeze to install and maintain, at least nvidia, dunno about AMD, just bought the cheapest card I could find in the store, 1080p working. AUR entry for XBMC user repositories so you get all the XBMC goodness you could ask for.
                    Strange. Personally, I found OpenELEC 3.0 to be the easiest OS install I ever did. I'm looking forward to 3.2 (will be re-installing to take advantage of the availability of the new 64-bit generic build).

                    Edit: On second thought, I suppose I should clarify that I equate ease of install with length of install. From download to first boot, OpenELEC 3.0 was the fastest OS install I ever did, which is why I call it the easiest install I ever did. I don't remember if the installation process itself was simple or not, but I remember it had only a few steps, everything was quick, and everything went the way it was supposed to. For comparison, other installs that are supposed to be "easy" but result in me having to troubleshoot or research and employ work arounds increase the time it takes to install, which is why I consider them to be hard installs (Fedora 18 is an example of what I call a difficult install that's still fresh in my mind). I suppose other people would use other standards to measure ease of install.
                    Last edited by Serge; 09-14-2013, 11:56 AM.

                    Comment

                    Working...
                    X