I don't know if you noticed, but it's evidently not THAT easy, since the open source community is dropping hardware too. Yeah, if you are a programmer you could adapt and maintain old hardware if you want. But there aren't unlimited devs, and not all the users of older hardware are devs either.
I agree, anyway, that it's far easier when it's open source than when it's proprietary, since you avoid the duplicate efforts and the reverse engineering, when you know how to code. You will probably have a full featured driver from the begining, and your task would be adapt it to API changes and/or applying new techniques. Other than that, mostly bugfixes.
not to offend but i think UVD is pointless, i think would be a lot better a common gpu independant shader/CL accel API(not inside mesa) library that can be used and optimized by third parties like FFMPEG or x264 to offload the heavy compute code to GPU regardless the codec and a shader/CL filter/effect library for the eye candy
cuz been realistic no one in linux is gonna watch bluray's "legally" to begin with and UVD only support very few codecs compared to the massive landscape of codecs that FFMPEG can handle legally (or not i just don't care), and in fact if AMD could release UVD stripping the DRM crap we won't be able to watch bluray's either way cuz we miss the DRM crap so we have to procede the crack the disc either way since i doubt the MPEGLA will ever permit open source software to play content legally so i prefer have all my videos with GPU accel/filters at the expense of more power and not be tied to a VPU.
ofc this will require some tuning but if my phenom can handle 1080p like a champ without drop frames at all, even a modest HTPC class GPU should offer a very respectable performance using heavy filters to improve image quality
...Okaaaay, but how is this different from AMD itself refusing to open their own IP?
If a neighbor comes to your door wanting to borrow a cup of sugar, and you say "no -- absolutely not", are they going to care whether the reason why you said no is (a) you're an asshole, or (b) the guy you bought the sugar from at the supermarket is an asshole, who told you that you can't share it with anybody?
In both of these situations, you're to blame. The blame is obvious in situation (a), and I'm sure that (UVD aside) AMD wouldn't actually be in that situation, so you probably agree with me that this case wouldn't come up for AMD very often. For situation (b), you might be pointing at the guy at the supermarket and saying vehemently, "Hey, it's his choice, not mine!" -- but it was you who bought the product in the first place. "Let the buyer beware" -- AMD didn't think through the consequences of their actions when they purchased that IP.
Now it needs to reap the inevitable consequences of that, such as its customers being irrational/unreasonable and asking, "well why the hell would you buy sugar from someone who wouldn't let you share it with other people?!" When you make bad choices, expect them to come back to bite you. The world does not forget or forgive as easily as you want us to, especially when we have a quite-inflated sense of entitlement resulting from having bought your company's products and/or having invested varying degrees of cash into your company's stock.
This may not be a particularly common request -- after all, how many Windows users are insisting on free drivers or care about the encumbered IP -- but this is one of those decisions that is much more consequential than a cup of sugar, so the collective consciousness of your customers is all hoping that AMD will make wise and far-sighted decisions in the design of its hardware, accounting for market forces and potential situations that may not be fully realized at the time.
For all of the hardware decisions made up through, say, HD6000, I forgive you, because I know that you guys (the open source group within AMD) had very little involvement in the planning for that hardware. But if this situation crops up again for HD8000, it will be clear to all that you guys tried, unsuccessfully, to design a GPU free of external IP, and that the need for a quick fix for the Windows users took precedence over your concerns. If that's how it's gonna be, don't worry -- AMD alternatives are starting to emerge as Intel ramps up its GPU performance.
For this one I'm actually going to give you an easy out that a lot of people won't accept. Get the Gallium3d shader-based video decoding working well and I'll let you off the hook for UVD. From a desktop perspective the two solutions are equivalent in the results, except maybe a measurable difference in power, but who cares for a desktop?
@bridgman
with someone else you mean realtek?
re: the IP in the audio software -- we gave it a quick check before Alex wrote the code and it seemed OK. Turned out we were wrong -- it happens, but not that often. Do you want a written apology or something ?
Seriously, I don't understand why you are getting so upset about this. We already pushed the programming information (hw info) -- it was some of the *code* that was impacted, and Alex was looking through that code today and identifying portions which would still be useful.
re: UVD - Christian actually put quite a bit of work into shader-based decode before we switched to UVD. The problem is that nobody has figured out how to make the entropy decode step (CAVAC/CAVLC) run effectively on a GPU, and now that the rest of the pipe has been SIMD-ized on modern CPUs it's really the entropy decode that sucks up a big chunk of the CPU time.
Last edited by bridgman; 03-29-2012 at 09:35 PM.
@iPad3 issues: Apple didn't optimize the app. That doesn't mean that the ARM CPU isn't a killer...
@GPU table problems... Nothing that can't be fixed in future designs, right? I mean Fusion, which already fixes this somewhat, right?
I love AMD's open source efforts and, while it's not much, it has resulted in about 10 GPU's sold for use mainly with Windows PC's, just because of my advocacy if you will. I value your 'service' to get the UVD done as a drop-in replacement for Gallium, but I still don't realy care. As Alan Kay has said in 1997 (and still true today); the real computer revolution hasn't been started yet. I realy believe this to still be true today, but it's going somewhere and untill that happens, noobs will use Apple/Windows and Linux guys know how to get a good CPU for (networked) transcoding on the fly. So to me, Linux is still just a work in process before anything good can hit the block and so I, as a Radeon open source Linux user, don't mind the UVD. Instead of a jacks of all trades, master of none, I'd realy like it more if AMD would just enable the impossible thing with these drivers. Decoding a movie isn't impossible because of the CPU and Gallium3D is still a way better architecture (maybe not in terms of implementation, yet) than UVD.
$0,02
It is interesting that of all people some guys from qualcomm are stating this (i wonder to what extent Qualcomm management backs this). As far as i can tell there was some transfer of IP from AMD to Qualcomm whereby the former ATI Imageon turned into the Adreno (anagram of?). Since there has been such a transfer both companies are most likely involved in opening up any of or for the adreno. The IP buzzword, involving two companies with some undisclosed contract agreement in between, that is going to involve lots of lawyers and has plenty of opportunity for people to stall or subvert open source projects around it. So nice statement, guys from qualcomm, but good luck cleaning up in front of your own door.