Page 5 of 9 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 82

Thread: ATI, please release an Open UVD API

  1. #41
    Join Date
    Feb 2010
    Posts
    519

    Default

    Quote Originally Posted by markg85 View Post
    What we, the users, need most right now [...]
    Erm speak for yourself buddy, I'm doing fine with openGL output in Mplayer.
    Gotta love broad claims...
    AMD/ATI might as well ask the Mplayer team to rename openGL output "ATI GPU acceleration (Work in Progress)" and be done with it... Like anyone would notice anyway.

  2. #42
    Join Date
    Aug 2007
    Posts
    6,683

    Default

    @bridgman

    Would it be possible to access xvba with oss driver?

  3. #43
    Join Date
    Oct 2007
    Posts
    1,329

    Default

    /me waits patiently (and thankfully) for the TGSI-based work and suggests everyone chill out and do the same (or use gbeauche's xvba-video if using Catalyst).

  4. #44
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,578

    Default

    Quote Originally Posted by markg85 View Post
    Right, first one little mistake. The part i didn't believe is:

    <comments about UVD programming info>

    and i replied on that part with:

    <comments about fglrx progress and how long things should take
    OK, I think I see the disconnect. Tell me if this makes sense.

    There are (at least) two different topics under discussion here :

    - opening the XvBA API implemented by the fglrx driver

    - providing programming information for an open source UVD driver

    They are totally different activities - one (XvBA API) started a while ago and is (hopefully) pretty close to being done, the other (UVD programming information) has not started yet and I don't expect it to happen for a while.

    I was talking about UVD programming information, but I'm wondering if you thought I was talking about fglrx/XvBA when I said "6 months" and that triggered your comments about how long things should take ?

    Does that make any sense ?

    Quote Originally Posted by Kano View Post
    @bridgman

    Would it be possible to access xvba with oss driver?
    That (running a modified XvBA proprietary driver over the open source stack)is one of the options we are looking at. The problem is that if you run a proprietary user space driver over an open kernel driver you are making reverse engineering so much easier that the risk is not much different from directly releasing UVD programming info.

    If we finished investigating the release of UVD programming info and concluded that doing so was not *quite* safe but close, then a "UVD driver blob over open source stack" solution might reduce the risk just enough to be viable (depending on what the showstopper risk(s) turned out to be). It's definitely one of the options on the table anyways.

  5. #45
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by bridgman View Post
    Didn't come from me
    (...)

    - UVD only accelerates specific formats so for things like Theora and VP8 you're still going to want shader-based decode IMO...

    - I still think the best plan is to implement an XvMC-ish state tracker over Gallium3D (but designed for modern video formats, not MPEG2) then modify ffmpeg/libavcodec and others to use that state tracker for MC and deblock filtering... you could do more (IDCT etc.. ) on shaders in principle but IMO you're better off avoiding having to push data back from GPU to CPU so best approach is to pick a point in the decode pipe where everything *after* that point can be done efficiently on shaders...

    - IIRC the only sticky part with modern video formats and that approach was inter-prediction... probably do-able but haven't had time to work out the details
    it comes from me! but i can prove it in your writing right here.

    amd payes you for thinking and you "still think (,,,)--> XvMC (,,,) --> Galium3D (...) --> ffmpeg (...) --> on shaders"

    but in the past you write to me there is no clue about doing this because no single gpu company does this and without an uvd unit you should do this on the cpu then i remembers you about the r600 hd2900 with no uvd unit and h264 decode on gpu then you got a light in your mind and the thinking about an OS version of that stuff was born.

    and now the fat brain bridgman thinks about and thats what i talking about amd payes you for thinking so i'm right the AMD OS driver team work on the shader based solution because you think payed by amd about that stuff.

    its Psychoanalysis thats my skill other humans are great progammers and i'm great on thinking about people people do what they can do.

  6. #46
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,578

    Default

    I can't argue with that logic.

    If thinking counts then OK, it came from me

  7. #47
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by bridgman View Post
    I can't argue with that logic.

    If thinking counts then OK, it came from me

    IT software stuff is all about thinking!

    if the biggest greatest mine think that stuff it will come true for all other people.

    so yes thinking count !

  8. #48
    Join Date
    Oct 2008
    Posts
    151

    Default

    Quote Originally Posted by markg85 View Post
    Let me put it in numbers then.
    1 person works 40 hours a week and you put 2 people on it. That's 80 working hours in total for one week. Yes, i say you can figure out if it's all legal to release XvBA documentation in that time. If it's not possible then it's because of bureaucracy. The time is enough to find it out.
    Remind me to never hire you to do any project estimates, at least where technology and the law meets. If it'd take 30 hours to understand the engineering and 30 hours to understand the legal contracts, don't estimate 20 hours to wrap it up.

    You can estimate more like 30*30 = 900 hours trying to figure out what releasing one technical detail means legally and what one paragraph of one contract means technically. Then go into overview mode and apply puzzle theory, can you from the pieces combined figure out more than you should? Then start over.

    Right or wrong, the content industry claims billions of dollars in losses due to broken DRM. Look up Capitol vs Thomas, for sharing 24 songs they got awarded $2 million in court. I'd find it likely that if AMD accidentally handed over the keys to the DRM there'd be a billion dollar lawsuit on their ass. Let's do two weeks of review for that, sure.

  9. #49
    Join Date
    Oct 2007
    Posts
    297

    Default

    Quote Originally Posted by bridgman View Post
    There are (at least) two different topics under discussion here :

    - opening the XvBA API implemented by the fglrx driver

    - providing programming information for an open source UVD driver

    They are totally different activities - one (XvBA API) started a while ago and is (hopefully) pretty close to being done, the other (UVD programming information) has not started yet and I don't expect it to happen for a while.
    They are totally different but very tightly bound to each other since one can't exist without the other.

    Quote Originally Posted by bridgman View Post
    I was talking about UVD programming information, but I'm wondering if you thought I was talking about fglrx/XvBA when I said "6 months" and that triggered your comments about how long things should take ?

    Does that make any sense ?
    Yes it does.
    However in my "experience" 6 months is a LONG time! You can code and find out a LOT in that timeframe and that's why i think you can drastically reduce it. In my opinion to 2 weeks, but lets make it 2 months to keep you happy

    To me this stuff is all moving to slow and i see to much messages like "6 months" and 6 months later no real noticeable changes (for the user! i'm sure a lot changes we can't see)...

    But today something became a lot clearer though.. on the phoronix news for the 10.10 driver : "AMD or their AIB partners have yet to send us any Radeon HD 6000 series hardware, so Linux users are currently left in the dark." which makes me sad but does make me realize (again) that AMD is not caring that much about Linux video drivers..

    A few questions.
    • How much people are at this moment CODING on the linux fglrx driver?
    • Has the legal investigation for UVD even started?
    • If pervious is "yes" then how long did it tok so far and how much longer is it gonna take?
    • Why don't you "sponsor" a few community people to work on the opensource r600g (gallium) driver? It's not expensive at all for AMD but gives a lot of benifit for AMD! My estimate: sponser 5 people for 6 months full time. That's about ~2500$ a month thus 12500$ for 5 ppl thus ONLY 75000$ for 6 months and you end up with a very complete r600g driver in just 6 months! I'm sure AMD can miss that money for the goal.


    Note: don't hire me since i would need months to even do a "hello world" in video drivers.. hire more competent people. I know one that would be very happy!

  10. #50
    Join Date
    Jul 2010
    Posts
    449

    Default

    Quote Originally Posted by markg85 View Post
    However in my "experience" 6 months is a LONG time! You can code and find out a LOT in that timeframe and that's why i think you can drastically reduce it. In my opinion to 2 weeks, but lets make it 2 months to keep you happy
    ...
    i would need months to even do a "hello world" in video drivers
    Your argument seems to be "You, with your knowledge of how things work and what needs to be done, estimate 6 months. That feels like a long time to me so I think it will take you 2 weeks, maybe 2 months."


    Quote Originally Posted by markg85 View Post
    To me this stuff is all moving to slow and i see to much messages like "6 months" and 6 months later no real noticeable changes (for the user! I'm sure a lot changes we can't see)...
    If you're not running from xorg-edgers or installing the latest kernels etc, then it will take time for current development code to filter through. If you are, then I think you would have noticed significant changes. For example, my Evergreen card performs a lot better now than 6 months ago, and I believe that cards on the R600{c|g} drivers have seen one or two performance/functionality improvements in this time.


    Quote Originally Posted by markg85 View Post
    "AMD or their AIB partners have yet to send us any Radeon HD 6000 series hardware, so Linux users are currently left in the dark." which makes me sad but does make me realize (again) that AMD is not caring that much about Linux video drivers..
    I think you are being grossly unfair here. AMD hasn't sent a graphics card to a particular site within a couple of days of the launch of their product, and from this you infer that AMD doesn't care about Linux drivers? They would not have released such large amounts of documentation and be paying people to develop an open source driver that they did not care about (and I imagine Mr. Bridgeman would not be so active here). Give them a chance - does it not seem more likely that it was an oversight or an honest mistake?


    Quote Originally Posted by markg85 View Post
    [*]Why don't you "sponsor" a few community people to work on the opensource r600g (gallium) driver? It's not expensive at all for AMD but gives a lot of benifit for AMD! My estimate: sponser 5 people for 6 months full time. That's about ~2500$ a month thus 12500$ for 5 ppl thus ONLY 75000$ for 6 months and you end up with a very complete r600g driver in just 6 months! I'm sure AMD can miss that money for the goal.
    Would it be complete in 6 months? Is $2500 a month a reasonable salary for a highly skilled developer in the area? Do 5 sufficiently skilled developers want to work for AMD? Can they pack in their current job (assuming they have one) for just 6 months?

Posting Permissions

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