Qualcomm Calls To "Kill All Proprietary Drivers For Good"

[curaga]

while an iPad 3 can deliver gorgious graphics and top notch UI responsiveness with 10hours of batterylife on a damn high res display>.<

Uh, maybe you haven't noticed, but even diehard Apple fans are disappointed when the pad3 has three times the lag of pad2 (takes three seconds to flip a page in Apple's newsstand magazine reading application in ipad3).

[jrch2k8]

re: open source video decode, the only one saying it's impossible is Q. We're saying it's really difficult and *might* not be possible.

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

[DeepDayze]

Auggh !!

As I said a few times already, it wasn't *our* IP that affected the audio code, it was someone *else's* IP. I don't see how you think we can "be loose with someone else's IP".

re: open source video decode, the only one saying it's impossible is Q. We're saying it's really difficult and *might* not be possible.

If that 3rd party's license does *not* allow redistribution or disclosure then it cannot be released, naturally. it sure can take a lot of time and resources doing socalled workarounds though

[allquixotic]

Auggh !!

As I said a few times already, it wasn't *our* IP that affected the audio code, it was someone *else's* IP. I don't see how you think we can "be loose with someone else's IP".

...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.

re: open source video decode, the only one saying it's impossible is Q. We're saying it's really difficult and *might* not be possible.

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?

[Kano]

@bridgman

with someone else you mean realtek?

[bridgman]

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.

[V!NCENT]

@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

[dfx.]

While everyone loves killer performance, the FLOSS AMD driver users are not realy into that and so I'd like to see work going into a good video hwAccel state tracker instead of a non-abstracted UVD that's only tied to Radeon anyway.

And I'm AMD all the way in terms of GPU's and prefer AMD x86 over Intel x86, while I prefer ARM over x86, because it's fucking rediculous that anything digital still needs moving parts (fans) and draws so much power, while an iPad 3 can deliver gorgious graphics and top notch UI responsiveness with 10hours of batterylife on a damn high res display>.<

Fucking YES!

I absolutely love the idea of anyone being able to debug and improve the way my hardware works, but it's most likely never gonna happen, because the ability to force us into constantly purchasing new hardware by simply discontinuing it's proprietary drivers bears far too much commercial value.

and this is why Artificial/Planned Obsolescence should be a crime, punishable by both local and international trading laws. this is one of biggest types (if not the biggest) of scam ever.

[libv]

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.

[accumulator]

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

Not pointless, it might actually be _essential_.. Apart from the technical benefits of either choice, a shader based decoder might open itself up for legal attacks. Since you basically define the decoding in software (shaders), then transfer those to the hardware, a lawyer might reason that the software is in violation of a patent. If instead UVD is used, the actual decoding algorithm is in hardware, which I suppose is licensed for the decoding..