Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: OpenELEC 3.2 Packs In XBMC 12

  1. #1
    Join Date
    Jan 2007
    Posts
    13,410

    Default 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. #2
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,746

    Default

    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.

  3. #3
    Join Date
    Feb 2011
    Posts
    124

    Default

    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.

  4. #4
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,746

    Default

    Quote 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

  5. #5
    Join Date
    Oct 2008
    Posts
    2,908

    Default

    Quote 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?

  6. #6
    Join Date
    May 2013
    Posts
    13

    Default

    "OpenElect 3.2 is now available."

    not yet

  7. #7
    Join Date
    Sep 2012
    Posts
    24

    Default

    Quote 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

  8. #8
    Join Date
    Feb 2011
    Posts
    124

    Default

    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.

  9. #9
    Join Date
    Jun 2011
    Posts
    29

    Default

    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.

  10. #10
    Join Date
    Feb 2013
    Posts
    269

    Default

    Quote 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 at 11:56 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •