3D Optimizations and UVD... AMD_hal.so!

[rainbyte]

HI! After thinking a lot about this (and also chating with cxo on the irc channel) I decided to post...

The idea is to have a binary library on top of the opensource driver, which would have all the special top secret features into it, developed by AMD/Ati.

This binary library would be completely optional but it would benefit both, AMD/Ati and also the opensource community. This would speed up the driver development (and indirectly the implementation of GEM/TTM, Gallium, DRI2) giving us a stable driver that has compatibility with every distro and AMD/Ati would be able to create this library on top it and bring advanced features to every user.

This features would include OpenGL 2D/3D optimization routines for workstation users (mainly FireGL cards), also UVD Accel for normal users and maybe a fast implementation of OpenCL on top of Gallium.

I have also asked Bridgman about this on the "Ask ATI" dev thread (http://www.phoronix.com/forums/showthread.php?t=6585&page=57) .

Source of the idea: http://en.wikipedia.org/wiki/Intel_GMA#intel_hal.so

Well, thanks for your attention, Phoronix rocks!

[Azultra]

Oh please no..

What "special top secret features" ? Of the hardware or of the software ?

This would speed up the driver development (and indirectly the implementation of GEM/TTM, Gallium, DRI2) giving us a stable driver that has compatibility with every distro and AMD/Ati would be able to create this library on top it and bring advanced features to every user.

This features would include OpenGL 2D/3D optimization routines for workstation users (mainly FireGL cards), also UVD Accel for normal users and maybe a fast implementation of OpenCL on top of Gallium.

All of this is already coming with the open source drivers, and why do you assume that a closed blob would be necessarily faster ?

[Nille]

Oh please no..

What "special top secret features" ? Of the hardware or of the software ?


All of this is already coming with the open source drivers, and why do you assume that a closed blob would be necessarily faster ?

We need a CS Module for the UVD/UVD2 and IP Stuff. And as an Optional Component its ok. If you want it Activate it and if not dont use it.


But Currently we can only choose between a feature rich fglrx with some Problems or a Free Driver with only very Basic stuff.

[rainbyte]

Hi! As Bridgman said in other posts, there are some parts of documentation/code that they can't opensource because of legal/competitive issues... The library can solve that problem for the people who need those features.

But that won't be the important part for the community, the benefit for us would be to put all the effort in the opensource drivers, because AMD/Ati would help to implement all the features which don't have legal/competitive problems.

I'm really interested in speed up the development, actually the efforts are so divided that we will get optimized drivers in a lot of time. In the other way, using the library, we can use this features in the short term and replace them with time, so the binary library will be smaller.

I think that people need to use something that works well, and as Nille said, currently some features are only in determined drivers, but it would be ok to have the library on top of an opensource (very stable) driver.

[RealNC]

There's no point investing or working in something that by definition has no future.

[Azultra]

We need a CS Module for the UVD/UVD2 and IP Stuff. And as an Optional Component its ok.
What's "IP Stuff" ? Stands for "Intellectual Property Stuff" ? Could you be more specific ? :confused:
Bridgman said somewhere that UVD was going to be documented.

If you want it Activate it and if not dont use it.
Of course! Freedom!
If you want proprietary drivers Activate it and if not dont use it.
So what's the point with releasing all these specs ?

But Currently we can only choose between a feature rich fglrx with some Problems or a Free Driver with only very Basic stuff.
You wrote Currently with a capital "C", and you may be right about that.

[bridgman]

There are three main problems with this approach :

1. For the 3D driver, the performance isn't just a function of "a secret module" (say, the shader compiler) but from the integration of the entire stack including big chunks of the kernel driver (memory management and command submission). If all those bits aren't used together then the performance is going to drop pretty fast.

2. If you want Linux market share to grow, enough to drive native app and game development for example, you're going to need things like legal BD playback with the associated DRM support. That implies a bottom-to-top closed source solution; open source drm implementations are being discussed but I don't think anyone has a practical implementation yet. Until the "what does Linux want to become ?" discussions settle down (if ever) I don't think it makes sense to take the driver in a direction (closed source 3D mixed with open source modesetting) where we would have to completely discard in order to deliver a secure legal BD solution.

3. For UVD, having a small binary module in an otherwise open source driver doesn't really protect the code at all; it's just too easy to reverse-engineer a closed source module if everything around it is open source. I believe Intel dropped the idea themselves, at least that's the impressino I get from the various articles mentioning it.

For clarity, issue #1 is a big enough problem before even considering #2 and #3.

I think the combination of opening up the install/packaging scripts (on phorogit) plus making the drivers more "chatty" so that problems can be diagnosed and fixed more quickly will go a long way to making the driver more tolerant of system-to-system variations.

[rainbyte]

Well, after reading your post I arrive to a conclusion...

1- As I see, it would be at least very difficult to implement this kind of approach in the opensource driver in order to add 3D optimizations because of the integration between the opensource and the binary parts. I am not a xorg developer but what about supporting only certain versions of the opensource stack, you know something like "AMD Performance Libs version xxx are compatible with Radeon/Mesa version xxx" so they will stay syncronized.

2- About BD and DRM, I think that they aren't (and maybe won't be) used in Linux... The normal user would be playing home-made h264 or xvid content or at least downloaded from internet.

3- UVD critical information, that would be a problem too, if it is difficult to protect it with this approach we would fall in a legal issue. Maybe there is some way to turn this around or maybe not, I'm not sure.

This has left me a doubt... Would it mean that libva binary approach is insecure too? Will this slow down the development of libva api?

Well, thanks for all your attention again...

[popper]

What's "IP Stuff" ? Stands for "Intellectual Property Stuff" ? Could you be more specific ? :confused:

Bridgman said somewhere that UVD was going to be documented.

....
#80 http://www.phoronix.com/forums/showpost.php?p=57946&postcount=80
Bridgman said:"we are going to look into opening up UVD, I just can't make any commitments until we have actually gone through the investigation and it won't be quick. We have 6xx/7xx 3d code out now, so IMO the next priority should be basic power management. "


popper said:"thats a shame, we are looking at months at the very least then!"

Bridgeman said:"I think the attraction of the [NV cuda] library is that it makes it easy to retrieve the decoded frame, while most of the decoder implementations supplied by HW vendors tend to only output to the screen simply because that was the main requirement.

We make a similar capability available to ISVs :

http://www.cyberlink.com/eng/press_room/view_1756.html
"

popper said:"yep,that about covers it for basic needs it appears, your average dev and indeed Pro coders such as BetaBoy and the CoreAVC coders dont really need that much help once they have the right library and docs access it seems, BetaBoy said he wanted to support ATI UVD in CoreAVC and related apps but you dont give them or the open SW coders access to the ATI UVD."

Quote: 01-08-2009, 07:48 PM
Originally Posted by popper
thats a shame, we are looking at months at the very least then!

Bridgeman said:"For open source, yes, but I expect fglrx will have it sooner."

until those UVD header and UVD docs become available, IF ever, we are going nowere, but i assume and really hope Bridgman is hard on the case regarding that vital UVD review, and doing what he can to push it, and its related documentation to the top of the things to get done by someone? inside AMD/ATI ASAP ;), would that someone be you Bridgeman as the key person?

[rainbyte]

So the implementation of UVD will be slow, we don't have even the specs...

Also we aren't sure about which of them are going to be reviewed, because there is UVD (R600 chips) and UVD2 too (R700 chips, more posibilities to be opened)...

I have a Radeon HD2400 (rv610) and I'm not sure if the opensource driver would support UVD on it.

[popper]

apparently the actually getting to, and perhaps through the investigation/review part will be slow, (at least Months)unless somone? inside AMD/ATI decides to push it through as a "need it now to catch up with the other companies offerings" to 3rd party video devs/apps type thing.

but the actual UVD ASIC if and when its header/docs/code arrives, if ever.... depends on the internal review after all, will be as fast as the other ASIC offerings ,perhaps faster at HW assisted decoding etc.

and its been said/implyed the UVD includes a lot more stuff inside than the NV ASIC etc has, but we cant know for sure, as we dont have that documentation/sample code showing it off TODAY ;) and noone inside AMD/ATI has bothered to write it's capability up and released that information....

[RealNC]

For UVD, having a small binary module in an otherwise open source driver doesn't really protect the code at all; it's just too easy to reverse-engineer a closed source module if everything around it is open source.

Does this matter? If someone reverse engineers it, it's not AMD's fault. Publishing reverse engineered specs is illegal. AMD is not the police.

And I don't really get the "reverse engineering" paranoia. Who needs to actually do it? I can copy BD discs easily anyway. This whole UVD case is useless. It's a PHAIL in big fat letters; it doesn't protect s***t :P You're trying to keep something a secret that no one even gives a flying fsck about how it works because it's circumvented anyway :P

[bridgman]

Yeah, that would be nice... but it doesn't work that way. Whether the information gets published illegally or not, we still get hit by the consequences.

Besides, pretty much *everything* is legal *somewhere* in the world, which wasn't such a problem back when most IP involved which local weeds to grind up into medicine and the Internet relied on ships for routing between continents ;)

One of the hardest parts of any open source program is building and maintaining a model of the reverse-engineering activities which are likely to be enabled (or simplified to the point where someone bothers) by the information you release. All of the risk-related decisions have to be made based on the implications of both released and "likely to be reverse-engineered as a result" information.

[Alex W. Jackson]

If you want Linux market share to grow, enough to drive native app and game development for example, you're going to need things like legal BD playback with the associated DRM support. That implies a bottom-to-top closed source solution

Yes, a closed-source player running on a closed-source API framework talking to a closed-source hardware driver running on a closed-source kernel--in other words, Windows Vista (or OS X)

My understanding is that the "robustness" requirements for the various hi-def DRM standards pretty much categorically exclude anything running on top of a GPLed kernel--and that this was no accident, since Microsoft was heavily involved in crafting these industry standards.

The future of BD and other hi-def support on Linux is most likely going to be the same as the present state of DVD support: software developed in civilized countries without ridiculous paracopyright laws, and distributed in the US and EU on a "don't ask, don't tell" basis.

And hey, there's a possibility that when some company in Israel comes out with a killer BD-playing Linux netbook, and it can't be sold in the US or EU because of the DMCA (or, more importantly, no US/EU company can build anything to compete with it) the lawmakers will take a good, hard look at just whom those laws are actually "protecting".

[RealNC]

It's the content creators who want DRM, not Microsoft. Microsoft simply allows that content to be supported in Windows by making up a standard for it. Hollywood creates the stuff, they want DRM, the consumers want the content, Microsoft allows them to have it.

Not having DRM in FOSS is retarded. Go wait for BlueRay movies to sell in Ogg files.

[energyman]

Does this matter? If someone reverse engineers it, it's not AMD's fault. Publishing reverse engineered specs is illegal. AMD is not the police.

And I don't really get the "reverse engineering" paranoia. Who needs to actually do it? I can copy BD discs easily anyway. This whole UVD case is useless. It's a PHAIL in big fat letters; it doesn't protect s***t :P You're trying to keep something a secret that no one even gives a flying fsck about how it works because it's circumvented anyway :P

if they have the legal obligation they have to keep it secret no matter what you think or hope.

[Alex W. Jackson]

It's the content creators who want DRM, not Microsoft. Microsoft simply allows that content to be supported in Windows by making up a standard for it. Hollywood creates the stuff, they want DRM, the consumers want the content, Microsoft allows them to have it.

Not having DRM in FOSS is retarded. Go wait for BlueRay movies to sell in Ogg files.

DRM is premised on the idea that there is data on a computer that the operating system prevents the user and owner of that computer from accessing, and furthermore that the operating system is hardened against "tampering" by said owner to make that data accessible.

This is literally antithetical to the GPL--what Microsoft or another proprietary vendor considers "unauthorized tampering" is the very raison d'etre of the GPL.

As for Microsoft claiming "we never wanted DRM but the big, bad movie studios forced us to implement it"... I bet you believe the tobacco industry's press releases too.

[RealNC]

I don't see Microsoft making DVD/BD players, the original DRM platform. The content creators would never remove DRM just for the sake of Windows. If Windows wants to offer users to watch those, it has to implement DRM. And Windows can't afford not to offer a legal way to watch protected content.

And you're forgetting something: you're not required to accept DRM even if you're a windows user. You simply stop watching movies from BD and DVD. There, problem gone.

[bridgman]

DRM is premised on the idea that there is data on a computer that the operating system prevents the user and owner of that computer from accessing, and furthermore that the operating system is hardened against "tampering" by said owner to make that data accessible.

This is literally antithetical to the GPL--what Microsoft or another proprietary vendor considers "unauthorized tampering" is the very raison d'etre of the GPL.

Yes and no. A lot of BD players run embedded Linux with DRM implemented above the kernel.

[Alex W. Jackson]

Yes and no. A lot of BD players run embedded Linux with DRM implemented above the kernel.

Yes, but that's an embedded system where the GPL is moot because the kernel binary is baked into a ROM. Surely you've heard of the controversy among the kernel developers over "Tivoization".

I can't see any way a desktop Linux system where the user is able to install a modified kernel can ever meet the BD DRM "robustness" requirements.

[bridgman]

I don't think embedding the OS in ROM removes the obligation to provide source. AFAIK TIVO provides source for the kernel changes distributed with their system.

What folks refer to as "Tivoization" is a bit different AFAIK -- that's when the software is upgradeable but a mechanism is used so that only software from the vendor (or another approved source) can be used for the replacement.

[monraaf]

Not having DRM in FOSS is retarded. Go wait for BlueRay movies to sell in Ogg files.

No, it's the entertainment industry that is retarded they need to revise their business model. Restricting consumers is not the way to go, people just go download the freaking movies in matroska files.

[Alex W. Jackson]

What folks refer to as "Tivoization" is a bit different AFAIK -- that's when the software is upgradeable but a mechanism is used so that only software from the vendor (or another approved source) can be used for the replacement.

Yes, that's exactly what I'm talking about. The only way I can see Linux qualifying for "authorized" BD playback is if the player software and the rest of the stack is tied to an "approved" locked-down kernel binary or a whitelist of such binaries.

And as far as a lot of people are concerned (including some important kernel developers and, less importantly, myself), such a system wouldn't be Linux anymore.

[highlandsun]

Y'know, there's a lot more of us consumers out here than there are people working in the entertainment industry. If enough people cared about this issue, we ought to be able to petition for repeal of a lot of these laws. But so far, average joes don't seem to care (or understand, or something) about how DRM infringes on their rights.

[popper]

the whys and whatfors of DRM seem to be a side issue here,people just want to use the ASIC for HW assisted decoding/Encoding/Transcoding of their (re-)encoded HD videos at the end of the day.

the implication is, that the ATI UVD/UVD2 ASIC block has in fact some form of DRM inside it, and that is the reason Bridgman and ATI/AMD are having problems and not providing the headers/docs in a timely manor, were as the NV etc dont seem have this DRM inside their ASIC (or just dont reference any of that potential DRM part?)and so have a large commercial video assitance advantage here....right now.

if so why did this DRM block get put there instead of its own self contained block for far better security ?, is it really so hard to simply not reference any of this DRM block inside the real important UVD video decoding block headers and documentation everyone wants to see and perhaps use ?.

is it really so hard for the internal UVD ASIC devs and doc writer to simply make a headerfile that just references the video options we want to use as per FFMpeg patchs etc , and write their operation entry/exit points up in a PDF, and spend a day compiling their existing test code that doesn t have any conection to any DRM that may or not be inside that ASIC.


if not then at least get some internal ATI devs to write a full subset API, and provide working code that can replace this virtually useless UVD ASIC due to the DRM inclusion there, on the other parts of the GFx cards.....

put simply, if infact there is DRM inside the UVD ASIC, and so making it almost useless to external devs that want to use everything in it except that potential DRM block, then simply say so and move on, learn the lesson and dont include your DRM block in the next UVD ASIC revision (see an FPGA would have been a very good reprogramable thing here Bridgman ;) )

[bridgman]

What I'm saying is "our top priority is the hardware we said we would open up", ie enough for 2d, 3d and Xv acceleration. That's getting close to being finished now, so some time over the next couple of months I hope to be able to start looking at UVD to see whether it is feasible to open up some hardware info without putting DRM at too much risk.

NVidia has only provided support for their hardware in a closed source driver (like us) so I don't understand your comment about NV not having DRM in their hardware. The distinction here AFAIK is simply that NVidia have made their closed source solution more broadly available than we have, and that they have provided a Windows library for decoding single frames which has been picked up for use in transcoding apps.

[Kano]

Windows library? CUDA is available for Linux too. If you use it tricky you can even run win CUDA apps with wine!

[popper]

well OC i dont know if NV have included any DRM inside their ASIC, all people care about is NV are giving people somethng ATI could be giving too but currently dont, ATI and the OEMs sold the X1xxx, HD2xx ,HD3650,HD4xxx on the premise of real HW assisted video playback and real AVIVO GFx card HW assisted AVC Encoding etc, its all still only CPU bound and run after all this time, no apparent use of the UVD ASIC even on windows!.

its also been said (by the developer relations *manager of genesi)that any 3rd party devs/companies relying on ATI/AMD UVD/UVD2 plans to base a product on are mad/insane to do so.....

i and many others want you to do well in the HW assisted video space, OC, otherwise why would i/we be posting here, just so thats clear ;)


*"Fri Jan 16, 2009 Matt Sealey,(Neko),Site Admin,Genesi, Manager, Developer Relations said:
There is no driver, not even in the binary ones, ATI will not give a schedule for it and may only expose it through a custom "XvBAW" API.

This is not going to get you playing videos right now and it would be insanity to develop a product around it.

We recently finished off a marketing requirements/product requirements document for something, and one of the things we agreed to cut out completely was support for an ATI graphics chip (the E2400) because there are no open-source 3D drivers for RV680 and waiting for them to get stable, or commissioning a binary driver in lieu of that, would not be cost-effective"

[bridgman]

Just because I disagree with you on specifics doesn't mean I don't appreciate what you are trying to do ;)

Kano, the discussion is not about CUDA itself but a specific library provided for use with CUDA, called nvcuvid. That is what uses the video decode hardware to decode a frame and return the contents to the application. As far as I can see, nvcuvid is Windows only right now.

[Kano]

For linux it is vdpau.

[popper]

sure Bridgman, i just put it up for clarity, and the mention of nvcuvid/vdpau kind of brings us back to the OPs point ;) a closed yet documented binary blob from ATI ;) to do all the things and more that the NV sub API cuda ASIC also does...

[bridgman]

For linux it is vdpau.

You might be right -- the API looks like it should allow application read access to a VdpVideoSurface.

VDPAU was already released when folks were still complaining about the lack of a frame-at-a-time decoding API though, and at least one poster mentioned that VDPAU wouldn't work for their application because it was "one way". Doesn't look that way from the API spec though...

[Kano]

Well i know that it works with mplayer and xinelib as i use both.

[bridgman]

Yep, for straight playback I don't think there's any question.

Popper was talking about frame-at-a-time decode with application read-back in earlier threads, however.

[popper]

yep, the requote i put in the first page
http://www.phoronix.com/forums/showpost.php?p=61565&postcount=9
covered that "frame accurate" app editing point.

in essence, its the basis for all your AVCHD video edited work flows and the like, its a shame (or perhaps not? if the review fails)the potential AVIVO Encoding/Transcoding/muxing part isnt using the UVD HW, OR IS IT?, or at least the Encoding parts included in some ATI API , something like the Kdenlive HD video editor project http://www.kdenlive.org/ could make very good use of these two parts from inside FFMpeg.

BTW Carl Eugen Hoyos on the FFmpeg dev list is the one working the VDPAU FFmpeg patchs...

[duby229]

2. If you want Linux market share to grow, enough to drive native app and game development for example, you're going to need things like legal BD playback with the associated DRM support. That implies a bottom-to-top closed source solution; open source drm implementations are being discussed but I don't think anyone has a practical implementation yet. Until the "what does Linux want to become ?" discussions settle down (if ever) I don't think it makes sense to take the driver in a direction (closed source 3D mixed with open source modesetting) where we would have to completely discard in order to deliver a secure legal BD solution.


All I have to ssay about that is..... Bullshit....

Whether you guys ;like it at ATi or not DRM --WILL-- be cracked. And despite all the work you guys have put into fighting it, I will be able to watch commercial BD movies on my open source operating system with open source drivers and open source players with out a single line of DRM code.

It's going to happen.

[energyman]

that drm might be cracked does not change the fact that AMD and NVIDIA (and INTEL, Microsoft) are bound by CONTRACTS and associated LAWS.

Earth to duby229, laws and contracts have to be followed. If you like them or not.

[yotambien]

All I have to ssay about that is..... Bullshit....

Whether you guys ;like it at ATi or not DRM --WILL-- be cracked. And despite all the work you guys have put into fighting it, I will be able to watch commercial BD movies on my open source operating system with open source drivers and open source players with out a single line of DRM code.

It's going to happen.


Yeah...and since no matter what assasinations are going to happen, I guess the sensible, logical, practical thing to do is to hand guns to everybody.

[curaga]

yotambien, good ol' America has done that for years now :D

[duby229]

that drm might be cracked does not change the fact that AMD and NVIDIA (and INTEL, Microsoft) are bound by CONTRACTS and associated LAWS.

Earth to duby229, laws and contracts have to be followed. If you like them or not.

None of which effect the Linux market AT ALL. What ATi NEEDS to do is simply say that we are not interested in providing any support for BD playback on linux. Period. Instead what we will do is release information about our hardware to the public that will enable you to develop your own entirely independent implementation, of which we hold no liability for. Limitations to this documentation include but are not limited to any hardware that is required for restricted playback of protected content. In such cases where that information about that hardware can lead to playback of restricted content it will not be made available.

It means that any implementation that is made will be made independently from ATi, and they will have no liability for it. It would be kinda like you hacking into the Iranian Embassy and Novell getting blamed for it because you used there OS....

This scenario is entirely possible, and would probably already have happend if ATi would have dropped fglrx year and a half ago.

[duby229]

yotambien, good ol' America has done that for years now :D

If everybody in the grocery store was carrying a gun, would you rob it? I didnt think so...

[bridgman]

None of which effect the Linux market AT ALL. What ATi NEEDS to do is simply say that we are not interested in providing any support for BD playback on linux. Period. Instead what we will do is release information about our hardware to the public that will enable you to develop your own entirely independent implementation, of which we hold no liability for.

The risk to AMD/ATI has nothing to do with the independent implementation, unless it publishes reverse engineered information. The risk is that information published or reverse-engineered for use in an independent implementation might *also* be used to attack the content protection paths on other OSes. Without robust content protection on those other OSes, we risk losing a big chunk of sales on those OSes (and those OSes count for maybe 98% of our sales).

Limitations to this documentation include but are not limited to any hardware that is required for restricted playback of protected content. In such cases where that information about that hardware can lead to playback of restricted content it will not be made available.

I think that's pretty much what we are doing, isn't it ?

It means that any implementation that is made will be made independently from ATi, and they will have no liability for it. It would be kinda like you hacking into the Iranian Embassy and Novell getting blamed for it because you used there OS....

Or, even crazier, a firearms manufacturer being sued because a criminal stole one of their products and used it in a robbery, or an airplane manufacturer being sued because of a pure "pilot error" crashes. Both happen every year.

This scenario is entirely possible, and would probably already have happend if ATi would have dropped fglrx year and a half ago.

What does dropping fglrx have to do with it ?

[amirel]

The risk to AMD/ATI has nothing to do with the independent implementation, unless it publishes reverse engineered information. The risk is that information published or reverse-engineered for use in an independent implementation might *also* be used to attack the content protection paths on other OSes. Without robust content protection on those other OSes, we risk losing a big chunk of sales on those OSes (and those OSes count for maybe 98% of our sales).


Sorry, bridgman. Everything above may be true. However, this is a significant problem for AMD/ATI. It actually means, that some other company (we all know, which one) can actually dictate AMD/ATI what to do and what not to do. Does the AMD/ATI have any plans to be independent or this is the policy of AMD/ATI to always allow this other company to say the final word?

p.s. Excuse me for bad English --- it's not my native language.

[bridgman]

That one company has been able to dictate to the PC industry for a long time, long before DRM was a factor. That said, I don't believe that the DRM issues are driven by any company in the PC industry. The companies which create and own the content (aka "Hollywood") dictate how their IP will be protected, and any OS developer who wants to offer legal playback of that content in their major markets needs to follow the rules established by the content owners.

The need to follow the content protection rules applies to all OS vendors, not just the biggest one. Linux is one of the (few) exceptions., where a collective decision has been made to forego the ability to provide legal-in-all-markets BD playback even if that results in a reduced market share. I suspect this is why the major distributions plan are not targeting the consumer market, but are trying to make a living selling into (and supporting) enterprise customers, where multimedia capabilities are not so important.

[Qaridarium]

Does this matter? If someone reverse engineers it, it's not AMD's fault. Publishing reverse engineered specs is illegal.

no in german reverse enginnered specs are legal!!!!!


in the US Clean-ROOM reverse enginnered specs are LEGAL...

in Germany no cleanroom is needet.

[Qaridarium]

(and those OSes count for maybe 98% of our sales).

i think the market share is completly wrong i buy a lot of vga carts in the past and all of them not improve the linux market share becourse the pc's or the carts not selling with linux...

in my buessenes and privat linux has more than 30% markshare!

[energyman]

well, for you it is 30% but I am admin in a small (ca 80-120 pc) network. And there are only two fulltime linux users I know of. Which is a lot more than macosx users...

[curaga]

If everybody in the grocery store was carrying a gun, would you rob it? I didnt think so...No, but I wouldn't feel safe shopping there either, when all that is needed to take my life is one pissed off customer or a glitch in a gun.

[Qaridarium]

well, for you it is 30% but I am admin in a small (ca 80-120 pc) network. And there are only two fulltime linux users I know of. Which is a lot more than macosx users...

what is the problem ? fulltime linux user???
you can't use ATI VGA based linux pcs fulltime becourse you need to start windows XP for playing gammes in wine..
an nvidia based linux pc.. there is no XP needet!

i think with the right drivers for the 3D carts.. the market share will grow up!

[duby229]

No, but I wouldn't feel safe shopping there either, when all that is needed to take my life is one pissed off customer or a glitch in a gun.

In my town your allowedto carry a concealed gun, provided that you also have your permit on you when carrying the gun. The only exception to this law is if a property owner clearly posted that you arent allowed to carry a concealed gun on their premises. The thing that I find highly interesting is that most places where your not allowed to carry a gun also has the highest crime rate. In the better parts of town you wont see a posting telling you that you cant carry a gun.

[energyman]

what is the problem ? fulltime linux user???
you can't use ATI VGA based linux pcs fulltime becourse you need to start windows XP for playing gammes in wine..
an nvidia based linux pc.. there is no XP needet!

i think with the right drivers for the 3D carts.. the market share will grow up!

I haven't windows installed. I stopped using windows 8 years ago. I also don't have wine installed. But when I was still nvidia user, most games didn't work with nvidia either - or at least t he games I cared about. I know because once in a while I tried. I just wanted to see if the games I once played on windows would work - they didn't.

Oh - and 'part time linux users' are maybe three or four. Still more than macos - but at the end there aren't 30% market share. Not even 10.

[duby229]

The risk to AMD/ATI has nothing to do with the independent implementation, unless it publishes reverse engineered information. The risk is that information published or reverse-engineered for use in an independent implementation might *also* be used to attack the content protection paths on other OSes. Without robust content protection on those other OSes, we risk losing a big chunk of sales on those OSes (and those OSes count for maybe 98% of our sales).



I think that's pretty much what we are doing, isn't it ?



Or, even crazier, a firearms manufacturer being sued because a criminal stole one of their products and used it in a robbery, or an airplane manufacturer being sued because of a pure "pilot error" crashes. Both happen every year.



What does dropping fglrx have to do with it ?


Hi Bridgeman, thanks for taking the time to respond. Awesome man, just awesome.

About Risk, just dont release the information that puts you at risk. It really is that simple. I dont knwo what else to tell you. I know it's hard work to look through all the documentation and to try and assign a risk value to all the information that is needed to write a modern graphics driver. I fully agree with you on that.

However what I DONT agree with is that Linux MUST except a closed source DRM implementation. That is bullshit.I hate to be so blunt but it's true. If that is what we need then Blueray can go suck on an apple whole.. Besides I totally disagree witrh you. Not only can we live successfully without DRM, we can still develop the means to play back restricted content without interference from you.

The point is that DRM will be cracked. With oyu, or without you. How can you use ATi as an excuse to hinder development of open source blueray playback when you know full well that it is inevitable. If ATi never even existed open source blueray playback would still have been inevitable. It's going to happen.

[rbmorse]

Someday Duby, I hope to visit your planet. It seems like a nice place.

[bridgman]

However what I DONT agree with is that Linux MUST except a closed source DRM implementation. That is bullshit.I hate to be so blunt but it's true. If that is what we need then Blueray can go suck on an apple whole.. Besides I totally disagree witrh you. Not only can we live successfully without DRM, we can still develop the means to play back restricted content without interference from you.

You might be surprised to find that I agree with you. I'm just saying that the technology isn't really there to make an open source, license-compliant DRM implementation, so in the short term living without a closed-source DRM implementation means living without a legal-in-all-markets BD solution, which in turn means less OEM preloads and probably slower market share growth as a result. Going that route would be a perfectly reasonable decision.

Not sure what you mean by "interference from us" though. The worst we will do is hold back information which puts us at risk, and the riskiest of the information is around the DRM paths (which is a problem for UVD).

Whether the generic DRM mechanisms get cracked or not is irrelevent; we just don't want it to be OUR FAULT :D

We also need to make sure that we don't release information (or raise the starting point for reverse-engineering which results in someone else releasing information) which would allow our DRM implementation to be cracked but not our competitors. That is the biggest risk associated with supporting open source development, and is what makes supporting open source expensive and risky rather than the "cheap, easy and good for you" exercise everyone on the outside assumes.

The point is that DRM will be cracked. With oyu, or without you. How can you use ATi as an excuse to hinder development of open source blueray playback when you know full well that it is inevitable. If ATi never even existed open source blueray playback would still have been inevitable. It's going to happen.

Same "I don't understand" as above; how are we hindering development other than by holding back the highest-risk information ?

[Kano]

I guess DRM in Linux context was a bad name as DRM in other context is something completely different ;) Aren't you interested how Intel wants to implement VDPAU? I guess that's something ATI/AMD could do too. If ATI wants to use something else, then why did not invent it BEFORE the others. Before VDPAU was introduced it seemed everybody (especially ATI+Intel) waited for the rest to do something like changeing ABI for XvMC. Intel introduced VA-API, but as the supported hardware is really hard to get and the driver seems to suck badly so there is only one working implementation for accellerated H.264 left. Without users/testers it is very unlikely that a new ABI will be successful. So jump on the train and develop something compatible.

[bridgman]

Yeah, the Good DRM / Evil DRM thing is the bane of my existence ;)

I didn't get the impression that Intel had decided on VDPAU, just that it was on the list of APIs they were looking at. I haven't had a chance to watch the video of Eric's talk all the way through yet, but people who attended his talk said that there didn't seem to be any kind of decision yet.

The other issue is that VDPAU seems to have been designed for direct-rendering only, not server-side implementation, and AFAIK the current DRI/DRM implementations don't actually handle multiple clients very well today (whereas implementing in the X server would bypass that problem). VAAPI seems to have been designed for server-side implementation while VDPAU was not -- I suspect that's the main reason we don't have that decision yet.

[Kano]

I guess some wider range of support would not hurt. Also those ABIs seem to be relatively similar as you could see from that VDPAU->VA-API wrapping lib - I would have expected it the other way around because there is not only mplayer but even xine with vdpau support. Maybe somebody will do this too ;)

[duby229]

You might be surprised to find that I agree with you. I'm just saying that the technology isn't really there to make an open source, license-compliant DRM implementation, so in the short term living without a closed-source DRM implementation means living without a legal-in-all-markets BD solution, which in turn means less OEM preloads and probably slower market share growth as a result. Going that route would be a perfectly reasonable decision.

Not sure what you mean by "interference from us" though. The worst we will do is hold back information which puts us at risk, and the riskiest of the information is around the DRM paths (which is a problem for UVD).

Whether DRM gets cracked or not is irrelevent; we just don't want it to be OUR FAULT :D



Same "I don't understand" as above; how are we hindering development ?

I can see why your confused, so I'll just quote what you said instead...


2. If you want Linux market share to grow, enough to drive native app and game development for example, you're going to need things like legal BD playback with the associated DRM support. That implies a bottom-to-top closed source solution; open source drm implementations are being discussed but I don't think anyone has a practical implementation yet.

Of course this isnt the whole thing, its just the part that I have issues with. The only thing that I mean is that whether ATi was contributing to the Linux Market or not DRM would still be cracked eventually. The only thing ATi needs to do is: Dont release documentaiton that puts you at risk. You dont need a closed source DRM stack to do that. The final open source projects that facilitate open source playback of restricted content may not be in there final development just yet. But I assure you that competent people are working on the basic principles that these later open source projects will rely on.. The fundemental principles behind HDCP and AACS are already well understood. Blueray movies are already being hacked. You can already download full quality Blueray titles illegally right now. Most blueray titles are already available for download. For video playback all we need right now is a realtime decrypter. Your not being blamed for the work that is ongoing right now, so why on earth would you assume that you would be blamed for the future open source projects that will be based on this existing work: Of which you arent being blamed for anyways????

[bridgman]

Ahh, I get it. I think my initial comment might have been a bit ambiguous.

I was not trying to say "you must accept a closed source DRM solution", just "without a legal-in-all-markets BD solution, which today implies a closed source stack, you're going to have a tough time getting OEMs to aggressively market systems with preloaded Linux -- and without OEM preloads the *visible* Linux market share is probably not going to grow as quickly as some folks would like".

Sorry about the lack of clarity there.

[amirel]

That one company has been able to dictate to the PC industry for a long time, long before DRM was a factor. That said, I don't believe that the DRM issues are driven by any company in the PC industry. The companies which create and own the content (aka "Hollywood") dictate how their IP will be protected, and any OS developer who wants to offer legal playback of that content in their major markets needs to follow the rules established by the content owners.


Sorry again, bridgman. I understand your position --- I guess, it coincides with AMD official position. What was my question actually about: does the AMD have any plans to get rid of this "one company" dictate? Simply speaking, can we expect brighter future or not?

[RealNC]

Sorry again, bridgman. I understand your position --- I guess, it coincides with AMD official position. What was my question actually about: does the AMD have any plans to get rid of this "one company" dictate? Simply speaking, can we expect brighter future or not?

I don't think AMD can play any role here. It's up to companies like CyberLink to release Linux versions of their players.

[rbmorse]

http://shop.canonical.com/product_info.php?products_id=243&osCsid=8a539e3a1931f32cf073009a56c8e4df

[RealNC]

Hey, that's great. And it seems it has been offered for quite some time. So I guess the argument of not being able to legally play protected content on Linux doesn't really apply anymore?

[duby229]

Ahh, I get it. I think my initial comment might have been a bit ambiguous.

I was not trying to say "you must accept a closed source DRM solution", just "without a legal-in-all-markets BD solution, which today implies a closed source stack, you're going to have a tough time getting OEMs to aggressively market systems with preloaded Linux -- and without OEM preloads the *visible* Linux market share is probably not going to grow as quickly as some folks would like".

Sorry about the lack of clarity there.

I'm sorry but I am 100% convinced that your wrong. Most distro's wont ship with a proprietary implementation preloaded. They dont come preloaded with your drivers now. What makes you think that will change once DRM is implemented?

The faster we get an open source work around that will come preloaded, unlike your closed implementation, the better off we will all be.... The goal for everyone right now should simply be an open source solution. It's the only answer that makes sense.

[RealNC]

If it's not preloaded, install it afterwards. I don't see the problem.

[curaga]

We also need to make sure that we don't release information (or raise the starting point for reverse-engineering which results in someone else releasing information) which would allow our DRM implementation to be cracked but not our competitors.Heeeeyy, would that mean you could release information that could crack everyone's DRM?

[bridgman]

Yeah, but we need to make sure we don't do that. It's the main reason supporting open source graphics development is so time consuming and expensive.

The bigger risk is releasing info which allows *our* DRM implementation to be cracked but not those of our competitors.

RealNC; the content protection rules for DVD are a lot less restrictive than for BluRay. The Cyberlink player that rbmorse linked to is DVD only as far as I know.

[duby229]

I don't think AMD can play any role here. It's up to companies like CyberLink to release Linux versions of their players.

And why would anybody want linux versions of those players? The video codec is already supported. The audio codec is already supported. The container format is already supported. The subtitle format is already supported. The menu format is already supported. The only thing left for an open source player to work is developing a real time decrypter to get around DRM, and that work is already progressing nicely.

My guess is right now we'll likely have a working open source player before the year is out.

[RealNC]

And why would anybody want linux versions of those players? The video codec is already supported. The audio codec is already supported. The container format is already supported. The subtitle format is already supported. The menu format is already supported. The only thing left for an open source player to work is developing a real time decrypter to get around DRM, and that work is already progressing nicely.

My guess is right now we'll likely have a working open source player before the year is out.

The point is that this is illegal. Decrypters are not authorized by the content owners. Only authorized players enable you to legally play this content on your PC. Hence my point about CyberLink. That's how it is. When you rent or buy a DVD or BD, you agree to its license. If you don't agree, stop watching them.

Of course most of us ignore legal issues.

[curaga]

They are completely legal here in most of Europe. Why would anyone pay for a player when there are better open-source alternatives available.

[energyman]

and in some countries it is legal to crack copy protection to use content you paaid for. But the content mafia is doing everything to change that. Luckily politicians are cheap.

[Kano]

They used to sell only the DVD players only to OEMs not end users. It would be a nice addon to a fast booting linux environment - just accelleration is needed then. Currently those system use only vesa capable xservers. I tried to install NV binary drivers on Moblin but was unsuccessfull. The kernel module compiled but there was an issue with the X server. So for embeeded use in BD players you have to create something that really boots fast.

[duby229]

The point is that this is illegal. Decrypters are not authorized by the content owners. Only authorized players enable you to legally play this content on your PC. Hence my point about CyberLink. That's how it is. When you rent or buy a DVD or BD, you agree to its license. If you don't agree, stop watching them.

Of course most of us ignore legal issues.

The DMCA can suck on a big fat apple whole. I am firm believer in FAIR USE. According to the fair use act, it is perfectly legal. As far as I'm aware that act is still in place. Any contradictions that happen can be sorted out by the politicians. And if ATi wants to aviod that mess, all they have to do is simply dont release documentation that puts them at risk. And that would be doing me a great favor. Frankly I dont want DRM laden hardware. The less DRM laden documentation we have the better off we will all be. If we could develop a driver that was completely DRM free, that would be the ideal. And I believe that it is possible to do just that. All this making excuses about how necessary DRM is... Is well, bullshit.