Page 6 of 7 FirstFirst ... 4567 LastLast
Results 51 to 60 of 64

Thread: XvBA on Evergreen

  1. #51
    Join Date
    Aug 2007
    Posts
    6,607

    Default

    Depends no your cpu and the content you want to watch. If you only watch lower bitrate content you don't need vaapi/vdpau so much.

  2. #52
    Join Date
    Dec 2008
    Posts
    984

    Default

    I think the bigger problem here is that there are no incentives for ATI to do the right thing. This closed API is merely taking something that was already closed and making it even more closed. There is no license that prohibits that, and there's nothing you can do about it.

    I would love the idea if kernel devs started locking down the kernel against such abuse. I think this can be done by making the kernel symbols they are using in their proprietary driver GPL_ONLY. Give companies such as AMD a grace period of 2 years and if not fully open source by that time GTFO.

    But since I don't see that realistically happening, I will save my own money for more open source friendly companies such as Intel.

  3. #53
    Join Date
    Aug 2007
    Posts
    6,607

    Default

    It is basically possible to replace gpl only symbols by the ids and link against that. At bit tricky however

  4. #54
    Join Date
    Dec 2008
    Posts
    984

    Default

    Quote Originally Posted by Kano View Post
    It is basically possible to replace gpl only symbols by the ids and link against that. At bit tricky however
    I think that would be called "willful infringement"

  5. #55
    Join Date
    Jun 2009
    Location
    Paris
    Posts
    428

    Default

    Quote Originally Posted by Kano View Post
    What would happen when the xvba sdk would be leaked and amdpcom.h/amdxvba.h would be public?
    I don't see how since we are the only users left in the game... And since colleagues don't even know where I hide those, this cannot happen unless I am terribly drunk.

    Would amd shares lose value? When pcom works why don't allow the use of it? One command can be guessed by the hwdecode demos configure script btw. - the rest was removed.
    I have checked the configure script, there is nothing PCOM related. Anyway, you can get all PCOM functions available from the XvBA libraries...

    That's pure ATI/AMD logic. You can NOT release something that WORKS...
    It works *better*, I wouldn't say it just works. Sure, in my experience this is tear-free, but it has some other problems that access well (or not) the recovery capabilities of the driver...

    Now, I could buy some G210 gfx. Or I could wait a little bit. Should I? ;-)
    Just buy a G210 now, mine is a Gigabyte fanless one. It does the job unless you try new features from the 256.xx NVIDIA series driver...

  6. #56
    Join Date
    Aug 2007
    Posts
    6,607

    Default

    Tearfree, Evergreen support, do we expect h264 l5.1 from pcom too

  7. #57
    Join Date
    Jun 2009
    Location
    Paris
    Posts
    428

    Default

    Quote Originally Posted by Kano View Post
    Tearfree, Evergreen support, do we expect h264 l5.1 from pcom too


    BTW, PCOM is just about presentation, i.e. displaying the decoded frames onscreen. This is the 2D alternative to OpenGL. The rest is common and a subset is even shared verbatim with Windows... So core decoding capabilities are the same, be it PCOM, OpenGL or something else used to present the result. This is what I would assume though.

  8. #58
    Join Date
    Jun 2009
    Location
    Paris
    Posts
    428

    Default

    Quote Originally Posted by bridgman View Post
    You might want to play with gl sub-options as well. Maybe try something like mplayer -vo gl:yuv=2:rectangle=1..

    The first option should reduce CPU load by doing YUV-RGB conversion on the GPU rather than the CPU, second option should reduce memory usage by using non-power-of-two textures. Default for both of the sub-options is 0.
    Do you mean that even with GL_texture_non_power_of_two, GL_TEXTURE_2D textures may be oversized to 2^n dimensions? Would you know the actual threshold? One of the XvBA bugs tends to confirm something like a threshold to keep using 2^{n,m} textures for small textures that are not a power of two in size.

  9. #59
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,385

    Default

    Can you explain what you mean by "oversized" here - I might be oversimplifying your question.

    IIRC the "rectangle=1" setting uses the GL_ARB_texture_rectangle extension rather than GL_ARB_texture_non_power_of_two but I haven't heard about any problems with that option up to the hardware limits of the GPU (8K x 8K on 6xx/7xx I think). I don't remember trying rectangle=2 though...

  10. #60
    Join Date
    Oct 2007
    Posts
    321

    Default

    Quote Originally Posted by curious.developer View Post
    Hi

    To mr. Bridgman - is there any real chance to get XvBA on Linux? How much? 100%? Probably yes? Dunno? Probably not? Any timeframe?

    ATM I'm building a HTPC solution and I've bought HD5450. A grave mistake it looks. My fault anyway.

    Now, I could buy some G210 gfx. Or I could wait a little bit. Should I? ;-)
    The main thing to watch out for is the cpu and video card... Most current processors (Like the Athlon II x4) have enough power to stay at the lowest speed stepping and still decode 1080p h264 video with very few dropped frames. Anyways, It'd be interesting to see 1080p and 720p videos that are encoded with h264 ( or AC1) be able to be decoded with the radeon hd 5000 series graphics card.

    Anyways, with that said, i would fully call my desktop fully ready as a htpc solution. Of course, i would also like to state that if your using xbmc make sure it's newer than revision 30566 because that specifically fixes the bugs with the texture matrices and glsl.

Posting Permissions

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