Page 10 of 20 FirstFirst ... 89101112 ... LastLast
Results 91 to 100 of 200

Thread: ATI R600g Gains Mip-Map, Face Culling Support

  1. #91
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,418

    Default

    Quote Originally Posted by Agdr View Post
    For instance, right now there is no public Evergreen support at all...
    I should probably make it clear that the public repos already contain display / modesetting code and the kernel driver portion of the acceleration code.

    What we're missing right now is the userspace portion of the acceleration code... we're trying to do things in a different sequence this time to shorten the delay between "having support available" and "having support available in a distro" and to reduce duplicated effort between X and 3D drivers.

  2. #92
    Join Date
    Jul 2010
    Posts
    46

    Default

    Quote Originally Posted by bridgman View Post
    I should probably make it clear that the public repos already contain display / modesetting code and the kernel driver portion of the acceleration code.
    Yes, sorry, I meant support in Mesa.

    And sure, starting with KMS and DRI is the way to go.

  3. #93
    Join Date
    Oct 2009
    Posts
    2,081

    Default

    Quote Originally Posted by bridgman View Post
    Sure, complaining about us not releasing a consumer PC-oriented video decode solution is fair.

    It's important that you complain about the right thing if you want anyone other than me to listen
    I suppose that a very important question is WHO should we be complaining TO?

    ** especially to get new and highly wanted features in open source?

    We know that obviously YOU are aware of what we want, so who do we complain to who can tell you that it is now time to make it happen yesterday?

  4. #94
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,418

    Default

    If it's an open source feature, complain to me.

    If it's something in the proprietary driver then it's not so easy, you basically need to complain back up the channels you are buying from, or just ignore the fact that you were given a lot of advance warning by Phoronix and wait for us to actually finish development

  5. #95
    Join Date
    Oct 2009
    Posts
    2,081

    Default

    Quote Originally Posted by bridgman View Post
    If it's an open source feature, complain to me.

    If it's something in the proprietary driver then it's not so easy, you basically need to complain back up the channels you are buying from, or just ignore the fact that you were given a lot of advance warning by Phoronix and wait for us to actually finish development
    So would inviting you out for beer get us video decode faster?

  6. #96
    Join Date
    Jan 2009
    Posts
    515

    Default

    Quote Originally Posted by droidhacker View Post
    So would inviting you out for beer get us video decode faster?
    Actually, I'm working on a vdpau backend for gallium right now. Its close beeing able to decide mpeg2, but thats only for softpipe and r300 should work but is untested.

    As soon as it works for softpipe, I will start implement it for r600.

  7. #97
    Join Date
    Jan 2009
    Posts
    515

    Default

    Quote Originally Posted by tball View Post
    Actually, I'm working on a vdpau backend for gallium right now. Its close beeing able to decide mpeg2, but thats only for softpipe and r300 should work but is untested.

    As soon as it works for softpipe, I will start implement it for r600.
    EDIT:
    Actually, I'm working on a vdpau backend for gallium right now. Its close beeing able to decode mpeg2, but thats only for the softpipe. R300 should theoreticfally work too, but is untested by me. The video-pipe I am using, is AFAIK already working with the xvmc state-tracker. I am just also implementing it as a vdpau state-tracker.

  8. #98
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,418

    Default

    Sounds like buying beer for tball might be the smart move

  9. #99
    Join Date
    Oct 2009
    Posts
    2,081

    Default

    Quote Originally Posted by tball View Post
    EDIT:
    Actually, I'm working on a vdpau backend for gallium right now. Its close beeing able to decode mpeg2, but thats only for the softpipe. R300 should theoreticfally work too, but is untested by me. The video-pipe I am using, is AFAIK already working with the xvmc state-tracker. I am just also implementing it as a vdpau state-tracker.
    Mpeg2 doesn't take too much CPU to decode. I take it the intention is ultimately to take on h.264 and similar?
    Edit: I wish I knew more about video decoding.... got a couple of engineering degrees here.

  10. #100
    Join Date
    Apr 2010
    Posts
    141

    Default

    Quote Originally Posted by droidhacker View Post
    Mpeg2 doesn't take too much CPU to decode. I take it the intention is ultimately to take on h.264 and similar?
    Edit: I wish I knew more about video decoding.... got a couple of engineering degrees here.
    Yes after MPEG2 is done, I think H.264 will be the next target.

Posting Permissions

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