Reply With Quote@bridgman
Would it be possible to access xvba with oss driver?
Senior Member
Erm speak for yourself buddy, I'm doing fine with openGL output in Mplayer.Originally Posted by markg85
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.
Kanotix Developer
@bridgman
Would it be possible to access xvba with oss driver?
Senior Member
/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).
AMD Linux
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 ?
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.
Banned
it comes from me! but i can prove it in your writing right here.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
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.
AMD Linux
I can't argue with that logic.
If thinking counts then OK, it came from me
Banned
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 !
Senior Member
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.
Senior Member
They are totally different but very tightly bound to each other since one can't exist without the other.
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!
Senior Member
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."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
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.
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?
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