Mixing open and closed source [Archive]

bridgman

02-01-2008, 12:56 PM

IMHO AMD should drop the development of fglrx for some time and focus on doc and code releasing. Last fglrx driver seems to be quite nice already so people shouldn't complain if they know that AMD for the time being is focusing on the docs and open drivers...

The skill sets are surprisingly different. We do horse-trade resources back and forth but in general we need people with legal and IP background to work on doc and code releasing.

In the long run AMD should drop fglrx for good and just develop some blob module for open drivers for things that couldn't be opened like h.264 hardware decoding or other DRM things... It's a waste of resources to develop both open and closed drivers.

This sounds great and it's an option we do consider, but so far it's not looking that good. Might be possible to have some of the display driver code relying on open source, but most of the acceleration stack (drm, xv*, opengl) will need to be closed source in the future for a couple of reasons :

1. If we're ever going to play protected video (DVDs, HD/BD) then we have to protect the decoded bitmaps all the way to the frame buffer, and we can't do that in an open driver.

2. For workstation business we invest a lot of money in performance-related driver work and wouldn't want to open source that because some of that work *is* useful to competitors.

Since we're not playing protected video today we could convert to use more open source in the short term, but by the time we finished that it would probably be time to start converting back ;)

IMO the best strategy is to have open AND closed drivers and use each one where it fits best.

bridgman

02-01-2008, 01:00 PM

Yeah. The unrest in the AMD user camp (raises hand...got parts, I do, I do...) is, I think, due to (snip) along with a glacial pace for the documentation and the honestly opened stuff.

This confuses me a bit. When we announced the open source initiative we talked about display and 2d in 07 and 3d in early 08. Everyone was really excited that things would be happening so soon. Now display is out, 2d is coming, we're within a few weeks of that schedule and things are "glacially slow". Did someone else post a much more aggressive schedule that I missed, or is this just honest impatience and "internet time" ?

bridgman

02-01-2008, 03:03 PM

Ahh, I think I see the problem. We did a bunch of interviews back at the initial announcment, and I talked about roadmap and schedule in many of them. When I go back and look at the articles it looks like many of them didn't bother with that much detail. Michael was pretty much the only one who asked technical questions and we spent more time talking about implementation plans, how far the open source support would go, differences between the GPU generations, AtomBIOS and the like.

I talked about roadmap and schedule so much I literally never wanted to discuss the subject for the rest of my life, particularly since all the schedules were based on putting together a big heap of estimates, but for all that apparently the roadmap didn't get out to the public as much as I thought.

So...

Sequence of implementation is display/modesetting, then 2d acceleration, then 3d acceleration, then video. The reason for that sequence is :

- a display/modesetting driver is quite useful on its own, albeit a bit sluggish with those big monitors you all seem to have (runs real fast on my 17" ;))

- you need display first or you can't see what you're doing for the other phases

- 2d acceleration hardware doesn't really change much from earlier ASICs -- only real change is with R6xx where it's emulated by the command processor. Existing code *and* existing documentation were sufficient, although I need to re-release the R200 era docs so new developers can join in

- 2d acceleration was also a nice safe way to get the DRM going which could then serve as a foundation for 3d

- programming model for the 3d hardware didn't seem much different from earlier ASICs (as long as we weren't trying to take advantage of all the new features) but we weren't 100% sure and needed time to put documentation together.

- video in 5xx+ ASICs is completely different from earlier ASICs, since we took most of the dedicated image processing hardware out of the overlay and used the space for more shaders. The good news is that we can do cooler things with shaders than fixed hardware -- bad thing is that it means video support has to come *after* 3d support whereas on previous ASICs it was easy to do first

The schedule we expected was roughly :

- display/modesetting lighting up in 3Q07
- 2D acceleration lighting up in 4Q07
- 3D acceleration lighting up in 1Q08
- video acceleration lighting up in 2Q08

By "lighting up" I mean "working for most users, enough functionality for many people, but we'll be adding features and handling corner cases & systems for months afterwards.

If anyone has heard different roadmaps, please let me know.

fhuberts

02-01-2008, 03:03 PM

1. If we're ever going to play protected video (DVDs, HD/BD) then we have to protect the decoded bitmaps all the way to the frame buffer, and we can't do that in an open driver.

This is exactly why I proposed to 'not care' about protected content some time ago and release what you can for non-protected content. Just release enough information that the open source driver can implement video playback of non-protected video.

You will not be in legal hot water if you do so obviously, while still making sure that the open source driver does 'everything'.

bridgman

02-01-2008, 03:14 PM

That's something different, and we are still going to try to do that. I'm just warning everyone that unless we find a way to enable use of UVD in an open driver without compromising the DRM in the closed driver I can't say that we will go any further than the IDCT/MC acceleration. We do DRM and decode in the same block, so exposing one without exposing the other is not necessarily possible.

We've got no problem with trying to enable decoding of non-protected content in the short term, assuming we can get around DRM and legal risks. I just have a problem with proposing to move fglrx on top of an open source driver if we would have to move it all back again to play protected content in the future.

Svartalf

02-01-2008, 05:09 PM

If anyone has heard different roadmaps, please let me know.

I was thinking it was going to be a bit quicker than that ("Internet Time" and all... :D) - but now that we're seeing what you have in mind, it's not QUITE so bad. It's still faintly problematic for the parties needing something substantive now- but it's even nicer looking than I'd thought before. I'm still frustrated, but there's definitely a real plan, we're close to it after all, and the light at the end of the tunnel's not the train coming back to run us over the third or fourth time... >:-) :D

val-gaav

02-01-2008, 05:24 PM

I just have a problem with proposing to move fglrx on top of an open source driver if we would have to move it all back again to play protected content in the future.

I think most people will use the open drivers once those will be complete...
By my experience it will be hard for fglrx to top open drivers on some fields. One may argue fglrx will improve .... well maybe,but who will report bugs to you guys ? I mean if everybody use open drivers (and I'm sure most people will if the quality is ok) the fglrx will experience problems. That's why the "blob module" seemed a better solution for me.

As for protected content support... Are there really users who want that ? From the other topic on phoronix forums I came to conclusion it was more a wish for hardware decoding but not for playing protected drmed content(just for normal unprotected h.264).

Anyway AMD sure is the best right now when it comes to contact with community. Thanks for that and for your answers Bridgman... and time you spent here and various irc chanels :). That's one of the reasons which made me choose a notebook with rs690 with the hope for future support :)

About the "glacially slow" issue I think some people get a bit impatient because they already own ati hardware... that's all.

bridgman

02-01-2008, 05:53 PM

As for protected content support... Are there really users who want that ? From the other topic on phoronix forums I came to conclusion it was more a wish for hardware decoding but not for playing protected drmed content(just for normal unprotected h.264).

Honestly, I don't know. If we conclude that there will never be a demand for protected video playback then that opens more options for the future. On the other hand, the Dell preloaded SKU ships with LinDVD today. DVD doesn't need the same kind of protection that HD/BD requires so it's not an issue for today, but if Dell sees demand for DVD today then that will probably translate into demand for BD tomorrow, and that *does* need protection right down to the kernel drivers.

What I expect is that more people will use the open source driver than the closed source driver, but the people using the closed source driver will continue to enthusiastically express their feelings when they're not happy with it ;)

Besides, what happens when Crysis shows up on Linux ?

EDIT - I just noticed this is the Intel docs thread. We should move somewhere else. Keith and others put in a lot of hard work to get those docs out -- let's show them some respect ;)

val-gaav

02-01-2008, 07:03 PM

but if Dell sees demand for DVD today then that will probably translate into demand for BD tomorrow, and that *does* need protection right down to the kernel drivers.

well right now dell offers laptops with intel graphics so I wonder what will intel and dell do with BD ? they don't have closed drivers...

[EDIT]
someone with mod powers should split this topic :)

bridgman

02-01-2008, 07:51 PM

well right now dell offers laptops with intel graphics so I wonder what will intel and dell do with BD ? they don't have closed drivers...

Good question. Right now it's a chicken/egg situation -- no secure driver, no certified player, no problem :D

Of course nobody knows if there's a market for a certified player app that can legally play HD/BD on Linux anyways.

bridgman

02-01-2008, 08:10 PM

That's one of the reasons which made me choose a notebook with rs690 with the hope for future support :)

Have you tried radeonhd recently ? The recently added 2d acceleration seems to work on 690, according to other users. Once the command processor support and DRM are added, 3d support can start to follow fairly quickly.

It will still be a while for full 3d, so if you need 3d or video and don't feel comfortable switching between fglrx and radeonhd you might want to stay put for a bit longer.

mgc8

02-01-2008, 08:17 PM

First of all, thanks bridgman for providing us with a much-needed window inside the development process for these drivers, your contributions are very welcome!
There is though something that bothers me regarding this discussion:

Honestly, I don't know. If we conclude that there will never be a demand for protected video playback then that opens more options for the future. On the other hand, the Dell preloaded SKU ships with LinDVD today. DVD doesn't need the same kind of protection that HD/BD requires so it's not an issue for today, but if Dell sees demand for DVD today then that will probably translate into demand for BD tomorrow, and that *does* need protection right down to the kernel drivers.

The obnoxious restrictions that encumber formats like BD/HD make these completely incompatible with the spirit, shape and form of free/open-source software. Why should the community even bother supporting them? Why should Linux support the flawed ideas running behind that system? I for one am totally opposed to any implementation of this sort of "driver" that protects my own content from myself. I believe going that route creates a dangerous precedent... if we accept such a closed-source driver for the shallow promise of being able to play "next-gen content", there is nothing stopping other similar ideas from taking hold -- what about a "cpu driver" next to protect even more "valuable IP"?! I think this has to stop before it even begins.

So what happens if users try to play BD in Linux and it doesn't work? Well, we simply educate them about the fact that the format is incompatible with the very idea of GNU/Linux and that they have alternatives. Will this lose some users? Certainly. But winning market share at any cost is _not_ the final goal, the likes of Dell notwhistanding. Or at least I didn't think so.

So please, go with the "options for the future" and provide a stable and commited support to the open-source driver, taking resources out of the closed one if need be. It's ok to have a closed-source driver for workstations, nobody will mind that, but leave "restricted content" much lower on the list.

Please also take into account what will happen if users will have a choice between:
a) open-source driver, stable and good in some areas
b) closed-source driver, more-or-less stable :-P and good in totally different areas

Will they have to switch drivers to watch a movie, then again to play a game, then again to use a workstation app? That doesn't sound very appealing... I'd say sticking with open-source and making sure the open driver is as good as possible, even if it means leaving out some bits, would be the best course of action.

Besides, what happens when Crysis shows up on Linux ?

Why would Crysis (or any other game for that matter) on Linux have an issue with the open driver? Am I missing something here?

Please don't take this the wrong way, it's just that I hate to see all the money and resources spent on implementing crappy ideas like DRM instead of them being used for important issues (like good drivers for current hardware, before it becomes obsolete)...

Best regards

val-gaav

02-01-2008, 08:56 PM

Have you tried radeonhd recently ? The recently added 2d acceleration seems to work on 690, according to other users. Once the command processor support and DRM are added, 3d support can start to follow fairly quickly.

I'm still using the Vista OEM on this laptop. I wanted to try if this OS is as bad as people say ... I hope nobody will kill me here for using it;). It will end up as Linux box once I find the time to set it up ...

The obnoxious restrictions that encumber formats like BD/HD make these completely incompatible with the spirit, shape and form of free/open-source software. Why should the community even bother supporting them? Why should Linux support the flawed ideas running behind that system? I for one am totally opposed to any implementation of this sort of "driver" that protects my own content from myself.

It's not Linux that supports it, it's Dell. Most people will use libcss for their DVDs not LinDVD, but please remember that using libcss is illegal in USA and France... So although I fully agree with you and I don't like it myself it's not really a community that supports it...

Will they have to switch drivers to watch a movie, then again to play a game, then again to use a workstation app? That doesn't sound very appealing... I'd say sticking with open-source and making sure the open driver is as good as possible, even if it means leaving out some bits, would be the best course of action.

that's why I suggested "the blob way" for DRM things... Anyway I'm not into this stuff but I am surprised how deep this protection seems to go ... Yep it's killing the free software (open source) way of doing things.

bridgman

02-01-2008, 08:56 PM

Will this lose some users? Certainly. But winning market share at any cost is _not_ the final goal, the likes of Dell notwhistanding. Or at least I didn't think so.

That's the $64,000 question. There are a lot of initiatives trying to make Linux more acceptable to mainstream users who would be forced to use Windows today. That's good in that it brings more support and investment to Linux products and lets you do more with it, but it's bad in that things like DRM may come along with the ride. I don't know how that will shake out.

Will they have to switch drivers to watch a movie, then again to play a game, then again to use a workstation app? That doesn't sound very appealing... I'd say sticking with open-source and making sure the open driver is as good as possible, even if it means leaving out some bits, would be the best course of action.

If they want to watch protected content that requires a closed driver, then want to use an open source driver "cause it's better", then want to run workstation apps with highest possible performance, then want an open source driver -- yep, lots of switching back and forth.

I don't see that ever happening. There will be enough overlap between the drivers that the open driver will be fine for most things. People who want the last bit of 3d performance, or features like protected video content, will switch to the closed driver and stay there.

Why would Crysis (or any other game for that matter) on Linux have an issue with the open driver? Am I missing something here?

Just that getting the most performance from a graphics card takes a lot of hard work and a lot of coding -- more than anyone in the open source community is willing to step up and do. Not saying our developers are better, just that performance optimization is a lot of hard work and the kind of thing that a commercial driver team will do and an open source developer will not.

If you buy a high end graphics card and run average games on them, you can probably be really happy with a good open source driver. If you need the last bit of performance for high res gaming or workstation then you will still want a closed driver. I picked Crysis because at high resolutions it is barely playable even with high end hardware and highly tuned drivers.

Anyways, all I'm trying to say here is "there are good reasons why closed source drivers still have a place, such as workstation, protected video and high end gaming, but we're making sure you have an open source option as well".

that's why I suggested "the blob way" for DRM things... Anyway I'm not into this stuff but I am surprised how deep this protection seems to go ... Yep it's killing the free software (open source) way of doing things.

Well, it hasn't happened yet and nobody is rushing to make it happen. Hi-def protected content brings a whole new world of DRM fun that all us hardware vendors have to deal with, and so far "just saying no" seems to be acceptable to the Linux market (whew !).

I'm just saying that we would look pretty dumb if the market *did* swing over that way and we had just finished converted to a hybrid open/closed solution that couldn't support BD :D

lucky_

02-01-2008, 09:01 PM

Good question. Right now it's a chicken/egg situation -- no secure driver, no certified player, no problem :D

Of course nobody knows if there's a market for a certified player app that can legally play HD/BD on Linux anyways.
I am pretty sure that when it will be time to put BD in laptop, Intel will come with some closed source driver for their all in one chipset they may have an open source driver but this one will never cover any drm stuff.
Related to the other thread :
Thank you for your post about the schedule, tt is nice to see where we are heading.
I always had a dirty question, how much would it cost, to finish a driver like radeonhd within The year ?
Since doc is provided, I am curious to know how much ressources are spend on it. And would it be possible to see more people hacking on it. (maybe once it can be merged in the kernel, was it question to merge radeon ?)

bridgman

02-01-2008, 09:26 PM

re: what would it cost to finish in a year

I guess it all depends what you mean by "finish". I expect that within a year start-to-finish we will have all the major areas with solid, basic support -- display, 2d, 3d, video.

If that's what you mean by finish, it's probably going to happen within a year anyways. Getting more people working on the driver is always a good thing -- one of the problems with having a successful driver is that users need to be supported, and that sucks up a lot of developer time. One of the great things about open source drivers is that you can talk to the developers -- but that kinda falls down as the user base grows.

A lot of libv's time goes to 1-on-1 user support, and that is time not spent adding features or fixes.

re: merging

The display block of 5xx-and-up was pretty different, so doing new code there rather than building on radeon seemed like the right idea. Same applies to video -- 5xx and up require significantly new code. For 2d and 3d acceleration, however, there is a lot of ocmmonality between the pre-5xx and 5xx+ hardware, so we *are* planning to share a lot of code between radeon and radeonhd.

The places where we can re-use existing code are :

- 2d acceleration (radeonhd developers are using code from radeon as a starting point, but we're keeping the code sufficiently similar that improvements can be pushed back and forth)

- DRM (Direct Rendering..., not Digital Rights...) should be able to stay as common code from 3xx all the way to 6xx.

- mesa (3d driver) again, should be able to stay with largely common code from 3xx to 5xx and 690. Not sure if we'll end up with new code for 6xx -- we'll start with common code and see how it goes.

Note that drm and mesa are not in the "radeon" tree anyways -- they are separate trees already. We plan to just keep them separate and use them with both radeon and radeonhd. It's only the 2d acceleration code that needs to be ported.

duby229

02-01-2008, 11:01 PM

Good question. Right now it's a chicken/egg situation -- no secure driver, no certified player, no problem :D

Of course nobody knows if there's a market for a certified player app that can legally play HD/BD on Linux anyways.

I hate to be a pessimist, but just like CSS, HDCP --will-- be hacked sooner or later and a decryptor licensed under the GPL will be available. It's not a chicken and egg matter. We all know the chicken came first. HDCP will be hacked and will be made available under the GPL.

I personally am a firm believer that if you dont support it, then they cant enforce it. Your actions of supporting DRM only strengthen it. If you didnt support play back of DRM in your drivers in Windows --or-- Linux, then it would be impossible to enforce.

Taking ATi's market presence into consideration, it may well be possible for them to kill off DRM by themselves simply by not supporting it in any fashion on any product using any operation system with any driver. ATi is big enough that if they ignored DRM they could single handedly kill it. That would win over the vast majority of the video market in your favor, becouse the simple matter of fact is that if most people knew what DRM actually was they would fight tooth and nail to get rid of it ASAP.

As a Video company it is ATi's duty to protect its customers --from-- DRM.... That means doing everything possible to actively look for protection mechanisms, and shutting them down, or bypassing them, or at the very least making it known to the user that the content they are trying to view is infected. But instead they walk away in fear from the content mafia, and strengthen it by weakening themselves.

Max Spain

02-02-2008, 01:12 AM

I've got to say that I firmly agree with the spirit of the above post. It seems like all of the hardware out now is being made exclusively for Vista and all of its digital rights management and support for other customers is not a priority. If a hw company like AMD were to release versions of their products without DRM for those who do not wish to compromise their freedom and privacy, then I'd bet that those uninfected products would sell better than the restricted ones.

Btw, as of yet, I have not purchased a product that contains HDCP or any trusted computing technologies (Presidio, and TXT included.) Nor have any of my technically enlightened friends (except 1.)

Mithrandir

02-02-2008, 09:02 AM

Maybe there is some kind of external pressure on ATI to support DRM. But now DRM is being seen more and more unethical even by major companies, so it should be possible to get rid of DRM.

bridgman

02-02-2008, 09:23 AM

If a hw company like AMD were to release versions of their products without DRM for those who do not wish to compromise their freedom and privacy, then I'd bet that those uninfected products would sell better than the restricted ones.

Most of our sales are to big OEMs. OEMs want Windows WHQL certification from Microsoft. WHQL certification requires DRM support. If we say "no thank you, we don't want to participate in your DRM ideas" then OEMs will just buy from someone else, and the biggest chunk of our market disappears. It's possible that there might be a retail market that would accept uncertified Windows drivers and all the hassles which go along with them, but realistically I think we would be talking about Linux-consumer-only products.

Maybe there is some kind of external pressure on ATI to support DRM.

See above. I cringe every time I see an article implying that we invented DRM or are pushing it ourselves. I don't even like TALKING about DRM here for the same reason -- people start thinking it's our idea and we should "just say no". I wish it were that simple.

But now DRM is being seen more and more unethical even by major companies, so it should be possible to get rid of DRM.

I'm not seeing that. There is definitely a change in the audio world, but DRM for video is alive and well, at least for now. That is why I'm saying "let's wait a bit before we look at mixing open and closed source, 'cause if we make that decision today the answer has to be no".

Zooko

02-02-2008, 09:45 AM

Hi bridgman. I'm encouraged to see that the corporate culture at AMD is such that you feel free to openly participate in this forum.

It sounds to me like the strategy of AMD with regard to open source, DRM, etc. is going to evolve in response to customer demand (where by "customer" I include OEM of course).

I wonder what sort of process you can use to hear back from the open-source-using customers. I know that you have strong communications channels with OEMs, of course, and through your end-user support process you probably get feedback from proprietary-driver users, but I suspect there's a communications disconnect from the open-source-using customers (like me) to you.

For almost everyone that I know, the question that is asked is "What's the best/cheapest graphics hardware that I can buy today which will work with 100% Free Software/Open Source drivers?". The answer to that question changed dramatically when AMD/ATI opened up and the radeonhd project took off.

However, for me and all the people I know, the point of contact between myself and AMD has been limited to when I bought the card down at Circuit City and thus sent a few dollars back up the channel towards you.

I had no way of communicating to you that the reason I chose that card was that the radeonhd project listed it as a supported card, for example.

I dislike DRM so strongly that I will tend to avoid supporting products which offer even *optional* support for DRM. For example, all other things being equal, I would prefer to buy a card that does *not* support DisplayPort, because the DisplayPort standard is tainted with the stench of DRM in my mind.

I can probably name a hundred people that I am friends with, or work with, or cooperate on open source projects with, who have substantially the same opinions and buying habits that I do, but I don't know if AMD has any process for learning about this subset of its customers.

Thanks for listening.

Regards,

Zooko Wilcox-O'Hearn

bridgman

02-02-2008, 10:34 AM

It sounds to me like the strategy of AMD with regard to open source, DRM, etc. is going to evolve in response to customer demand (where by "customer" I include OEM of course).

This is one of the big challenges for everyone -- is "majority rule" (ie listen only to what the OEMs want) the best way to run things ? We don't think so but practically speaking it's where you have to start.

I wonder what sort of process you can use to hear back from the open-source-using customers. I know that you have strong communications channels with OEMs, of course, and through your end-user support process you probably get feedback from proprietary-driver users, but I suspect there's a communications disconnect from the open-source-using customers (like me) to you.

Not as much as you think. The problem has been figuring out how to deliver what you want without putting the rest of our business at risk. What you've probably seen over the years is that as we get bigger we are able to listen to more points of view and factor them all into our planning, and now it's your turn.

The Catalyst drivers were the first big step, I guess -- in response to the fact that OEM priorities and end-user priorities were sometimes out of sync. Catalyst was basically two things -- setting up mechanisms to feed end user issues into the development pipe (via customer support) and externally releasing drivers on a schedule that could keep up with ongoing changes in the market (new games, apps, OS changes etc..).

Until recently the Catalyst model was aimed at Windows only, but as you've probably seen we are taking steps to include Linux in the initiative. We'll talk about it more in the Q&A, but the quick answer is "yes we are putting process in place". Part of the reason I'm hanging around here is to help figure out what that process should be.

It's worth mentioning that we have been moving towards this for a couple of years, but mostly behind the scenes. We didn't have the Linux resources to handle 1:1 interaction with customers, but we did set up the beta program (early 1:1 with a small set of customers), and we did actually look at the external Bugzilla reports even if we didn't respond or update the bugs ourselves. For the record, when I say "we" I mean Matthew, his team, and his management -- I only became involved in Linux recently through the open source project.

Since we happen to be first to market with Display Port but within a year everyone will have to support it, I would ask you to consider "not using it" rather than "not buying products which support it" ;)

Here's a question for you. Do you think the Linux consumer market is going to grow substantially from its current size (I mean 10x minimum, not 20%/year), and do you think that growth will be able to happen without an OEM-friendly solution for playing DVDs, HD/BD etc ? The new crop of users are presumably giving up Windows for Linux, so they more than anyone will be influenced by the features available on Windows.

Kano

02-02-2008, 10:55 AM

Do you think that LinDVD is a good player? I really doubt that because it is very old. A new one with HDDVD/BD support would be really interesting, there are patches for mplayer to handle unprotected files, but the cpu usage is pretty high. And I guess Linux HW accelleration will not happen too soon, maybe quad cores will help...

Mithrandir

02-02-2008, 11:09 AM

Here's a question for you. Do you think the Linux consumer market is going to grow substantially from its current size (I mean 10x minimum, not 20%/year), and do you think that growth will be able to happen without an OEM-friendly solution for playing DVDs, HD/BD etc ? The new crop of users are presumably giving up Windows for Linux, so they more than anyone will be influenced by the features available on Windows.

10x growth of course can never happen. Even 20% per year is much. I think this is approximate growth rate of Firefox.

bridgman

02-02-2008, 11:37 AM

Bingo.

The reason I picked 10x is because that is (VERY VERY VERY roughly) where the Linux consumer market becomes big enough to pay for the creation of graphics HW products positioned more-or-less specifically for that market. Without that kind of growth, Linux consumer users need to leverage HW developed for other markets, and those products *are* going to have to have DRM embedded in them.

All the HW vendors have to deal with this reality -- I just happen to be here talking about it. The challenge for the HW vendors, IMO, is how we minimize the impact of that "necessary evil" on the open source community.

glisse

02-02-2008, 12:03 PM

Bingo.

Without that kind of growth, Linux consumer users need to leverage HW developed for other markets, and those products *are* going to have to have DRM embedded in them.

Well i believe this is a matter of education. People start to suffer too much from drm and they are getting angry (and you should when you loose all your music just because the computer for which the key of the drm was generated just die). In my every day life i see a lot of people not aware but neverless suffering from drm they just don't understand what it's. I am sure that the music and movie industry would have to change their politic as more of their customer will become unhappy of the constraint imposed by drm.

Side note i am pretty sure that most people aware of this things don't buy stuff with drm in it (at least i don't and i won't).

bridgman

02-02-2008, 12:18 PM

Well i believe this is a matter of education. People start to suffer too much from drm and they are getting angry (and you should when you loose all your music just because the computer for which the key of the drm was generated just die). In my every day life i see a lot of people not aware but neverless suffering from drm they just don't understand what it's. I am sure that the music and movie industry would have to change their politic as more of their customer will become unhappy of the constraint imposed by drm.

I agree completely. Having said that, most of the real pain of DRM only really comes out when dealing with downloaded content, and so far that mostly applies to audio. As a result, the consumer backlash is mostly on the audio side, and that is where you are starting to see responses from the content owners (ie "record companies"). On the video side, pre-recorded media still dominates (most video jukeboxes are DVD carousels rather than HD arrays holding ripped movies) so the pain is much less today.

Zooko

02-02-2008, 01:29 PM

bridgman:

Thanks for the quick and courteous reply.

Certainly the Linux consumer market won't grow 10x. Microsoft has stumbled badly with Vista, but Mac rather than Linux will benefit, and anyway Microsoft will get its feet back under it soon enough.

I wouldn't ask you to waste your company's resources serving a niche market -- I was suggesting only that you try (even more) to understand the people in that market, because such niches turn out to be important sometimes. I'm guessing that you don't have any automated process for tracking the evolution of my niche.

How to do such tracking? I'm not sure. You participating on this forum is a good start, but such participation gives you only a limited sample, of course. Hopefully companies like Novell/Suse and Canonical can give you good insight -- I don't know.

By the way, much of what you said in your reply -- about "Catalyst" for example -- was somewhat irrelevant to me, because I'm not interested in linux, I'm interested in free software / open source (and also in complete freedom from DRM). I'm not really sure what "Catalyst" is, even though I've been a loyal purchaser of ATI hardware (and also AMD hardware) for many years. Before the radeonhd project, I was on the verge of buying a new graphics card to build my wife's new workstation -- it was going to be a Radeon 9250, which was known to work well with the 'radeon' driver. After the announcement of radeonhd, I bought her a Radeon 2400 Pro.

Here is a forum that you could look into which represents a related but different point of view than does Phoronix: LWN.net. There have been two topics this week that are relevant to your business:

http://lwn.net/Articles/267048/

http://lwn.net/Articles/267436/

I suspect that the subscribers to and contributors to LWN.net are almost a completely non-overlapping set of people from the folks on phoronix.com.

Regards,

Zooko Wilcox-O'Hearn

Max Spain

02-02-2008, 01:48 PM

See above. I cringe every time I see an article implying that we invented DRM or are pushing it ourselves. I don't even like TALKING about DRM here for the same reason -- people start thinking it's our idea and we should "just say no". I wish it were that simple.

I agree with you there, the HW manufacturers are NOT to blame for doing what M$ tells them to, but regardless of the cause, the consumer is still the one getting the shaft.

Most of our sales are to big OEMs. OEMs want Windows WHQL certification from Microsoft. WHQL certification requires DRM support. If we say "no thank you, we don't want to participate in your DRM ideas" then OEMs will just buy from someone else, and the biggest chunk of our market disappears. It's possible that there might be a retail market that would accept uncertified Windows drivers and all the hassles which go along with them, but realistically I think we would be talking about Linux-consumer-only products.

I've got another big market for you: Disenfranchised XP users. At my lan parties my friends who could afford them, are using high end NV/ATI DX9 series cards. If you'll look at the Steam Hardware Survey (http://www.steampowered.com/status/survey.html) over 82% of people are using XP. Also notice that ATI is taking a HUGE beating on their current high-end vid cards. M$ had better be subsidizing AMD/ATI like crazy because nobody is buying their stuff.

I can probably name a hundred people that I am friends with, or work with, or cooperate on open source projects with, who have substantially the same opinions and buying habits that I do, but I don't know if AMD has any process for learning about this subset of its customers.

Perhaps AMD could create a web form where a person could input serial #'s from AMD/ATI products that they own (to show that they are legit customers) and leave comments/suggestions. If you got the word out about that, I'm sure you'd discover a big section of your market that is being turned off by recent hw trends.

bridgman

02-02-2008, 02:10 PM

Yeah, that's a tricky one. Linux is different things to different people. For some, it's the embodiment of free and open software; for others, it's the dominant Unix-like operating system for those who want the benefits of a Unix-like system and it's free-ness is largely irrelevant. The workstation business, for example, loves Linux but doesn't care about free and open software. That's because workstation used to be a Unix market until inexpensive Linux distros almost wiped out the commercial Unix business.

I do keep an eye on LWN, but they don't get much into GPUs much so when they do it tends to be more of a Slashdot-like feeding frenzy than the more reasoned discussions you see here. LWN is definitely interesting reading and gives a wealth of information in non-GPU areas but I have a tough time getting a clear "what does a GPU customer look like ?" picture from LWN.

I agree that the two groups don't overlap much.

Max Spain

02-02-2008, 02:13 PM

Kano

02-02-2008, 02:29 PM

As you are from ATI and the Win drivers provide h264 encoding, how about that for Linux? That would be interesting as h264 encoding is really time consuming...

bridgman

02-02-2008, 03:20 PM

In the proprietary driver -- no problem, just a question of priority relative to bug fixing, new ASIC support and other features. It's a fair amount of driver work though, unless MS brings DXVA to Linux so we can do a straight port ;)

In an open driver -- we're not sure yet so I'm saying "no" for now.

TheIcebreaker

02-02-2008, 05:25 PM

As you are from ATI and the Win drivers provide h264 encoding, how about that for Linux? That would be interesting as h264 encoding is really time consuming...

Whenever the required support whatever that according to you comes in the driver then how can we use it.

Will the simple daily build of mplayer svn use the hardware h264 decoding straightaway or will it require more work.

Kano

02-02-2008, 09:09 PM

Well decoding is possible using the ffmpeg - mplayer can use the built-in or external ffmpeg. Also there is a patch to use coreavc as decoder.

http://code.google.com/p/coreavc-for-linux/

No decoder is hw accellerated. But not only decoding would be nice to have, also encoding. Currently mpeg4 encoding is fast enough (could be always faster howerver) but h264 is really slow.

Maybe somebody implements it for CUDA (NVIDIA 8 series), that would be a possibility.

duby229

02-02-2008, 10:53 PM

Tillin9

02-03-2008, 05:32 AM

First off, like many other users I was to thank Bridgman for listening to users' opinions. Its nice to know that ATI/AMD cares and is implementing changes designed to accommodate Linux users.

My 2 cents are that the DRM issue should be pushed till later. The major area where work should go is into 3D support. Right now I find the 3D support for older cards better with the open source drivers, fglrx has major artifacting with my 9500 and 9700 Pro and has since 8.35 (I'm more than willing to help debug if there is interest). Also, compiz has never worked right for me with fglrx, but works fine (albeit somewhat slowly) with the radeon drivers. Since I also have X850s I'm fairly sure this is because fewer resources are going to supporting and regression testing older cards. Since you seem to suggest r300/r400/r500 ASICS share enough commonality, I'd suggest getting those specs out to the open source developers to be a priority.

Another area which might help is getting in contact with the WINE developers. Basically they all use Nvidia cards since the opinion is no ATI/AMD driver supports enough OpenGL extensions for it to be possible to get games working. The head WINE Direct3D developer says this outright in his recent wineconf talk: http://www.youtube.com/watch?v=eJ-zyKR1N2A I think getting Windows games running under Linux is a much bigger priority than BlueRay since games sell graphics cards, not movies.

Redeeman

02-03-2008, 06:23 AM

bridgman:

theres just one thing i find so incredibly stupid.

all the drm crap is already broken, everyone that wants to copy this material already does.

i'd like to show a theoretical example:
I buy an ati card, ati has (THEORETICAL; REMEMBER) released fully open drivers. I now use my skills to modify the software stack to dump a movie. This takes a shitload of time.

and now for the question.. Why does it matter if i modify the ati software to do it, rather than going on a few torrent sites and getting the content? its even slower for me to do it by exploiting ati software, plus i gotta have BOUGHT the damn movie, so no matter how one looks at it, the content providers are better off with the ati driver allowing me to dump it, than without.

And giving the fact that it will realisticly only be a few people in the scope of the world that even has the ability(atleast few compared to all the people who has a bluray/hddvd movie), what does it matter that we now have an EXTRA, and more annoying, slower, method of extraction, which actually ends up earning content providers more money?

so now im about ready to make this claim: any content provider who would see these free drivers as something that should be stopped, are DIRECTLY STUPID, and doesent even know how to ensure their own continued stream of money properly.

And now, i have a question for you bridgman(and please keep in min that im not going after you personally, but rather AMD/ATI):
Does AMD/ATI feel they wish, and that its better for them, to babysit the complete and utter stupidity of some totally clueless and moronic content providers, to keep them believing in FALSE "truths", rather than directly giving their own customers what they want?

I already have a pretty good idea of the answer, but i would like for you to go to whomever is in charge around there in AMD/ATI, and ask them this question, because im really interrested in it, and this should clarify just how far AMD will be going, who their loyalties really is to, stupid content providers, or the customers who put the food on the table(well, ill bet some of those higher-ups of AMD gets alot of food on their own personal table from clueless content providers, but thats a different story).

Thanks in advance!

rbmorse

02-03-2008, 09:20 AM

Reedman: Read post #20 of this thread.

givemesugarr

02-03-2008, 09:22 AM

I hate to be a pessimist, but just like CSS, HDCP --will-- be hacked sooner or later and a decryptor licensed under the GPL will be available. It's not a chicken and egg matter. We all know the chicken came first. HDCP will be hacked and will be made available under the GPL.

I personally am a firm believer that if you dont support it, then they cant enforce it. Your actions of supporting DRM only strengthen it. If you didnt support play back of DRM in your drivers in Windows --or-- Linux, then it would be impossible to enforce.

Taking ATi's market presence into consideration, it may well be possible for them to kill off DRM by themselves simply by not supporting it in any fashion on any product using any operation system with any driver. ATi is big enough that if they ignored DRM they could single handedly kill it. That would win over the vast majority of the video market in your favor, becouse the simple matter of fact is that if most people knew what DRM actually was they would fight tooth and nail to get rid of it ASAP.

As a Video company it is ATi's duty to protect its customers --from-- DRM.... That means doing everything possible to actively look for protection mechanisms, and shutting them down, or bypassing them, or at the very least making it known to the user that the content they are trying to view is infected. But instead they walk away in fear from the content mafia, and strengthen it by weakening themselves.

then nvidia would support it and production companies would push out everything to that boards. only an agreement between hw producers to not support it would lead to its removal, but since amd, nvidia, ati, intel and other companies were the founders of drm the problem is that the one who will get out from it would simply lose market share and will die, unless it would come out with something that would lead community to stay tuned to it. for example the new display port seems wuite promising and interesting, but i don't think that it would strike down hdmi, since it has already been established in most of the hw present around the world, and if it's not 100% compatible with this hw, maybe through a phisical adapter, then it will lose and will be remembered as one of the great hw flops. the other problem is that there's on the market enough protected content that cannot be played without hw capable of doing it and that a lot of money was invested into it that it is almost unlikely to just be removed. what would you do if you're told that the bd film you've buyed for 50 or 60$ need to be changed in order to be played on your pc?!

I dislike DRM so strongly that I will tend to avoid supporting products which offer even *optional* support for DRM. For example, all other things being equal, I would prefer to buy a card that does *not* support DisplayPort, because the DisplayPort standard is tainted with the stench of DRM in my mind.

for what i've read displayport is the free alternative to the non-free drm protected hdmi, but i might be wrong on this. i need confirmation of this statement from someone who is better informed on the matter.

I think getting Windows games running under Linux is a much bigger priority than BlueRay since games sell graphics cards, not movies.

true. this is what ports people to linux. but here there's ne need of software houses that would step to linux. id has made its move and now i'm waiting for other houses like ubisoft and blizzard. i think that the moment in which gallium and opengl 3 will be here then we'll see a native support for windows/linux games with only one code and we'll see the end of directx. only when companies would drop directx and tune to opengl (which now is starting to be faster than directx in different games), and when there would be drivers like catalyst with a good part of code that is the same for different oses then we'll see a real passage of games to linux and a lesser domination of windows in the oem's plans. but for now this simply isn't the time for it.

ince you seem to suggest r300/r400/r500 ASICS share enough commonality, I'd suggest getting those specs out to the open source developers to be a priority.

the new specs would mean more driver work than implementing new code for the radeonhd driver, because from a programmer view it's simpler to write new code than modifying old code that wasn't written by you to have it fit to your needs. the one thing that after the read of this thread has gotten in my mind is a foolish thing:
why not concentrating for lets say 2 weeks on identifying the stuff that is equal in the chips and what is different. then take the equal stuff based on what it does and put it into a module, put another stuff into other module and so on. make a diagram of the various features and how they were implemented or not implemented yet, then take the driver and split it based on this new diagram. for example i'd put things like this:

1. base atombios, from which, based on the board reads you'll start loading its modules, named radeon_core.so
2. a module of 2d accel for r200, r300, r400 and earlier r500 boards that could be named radeon_2d_pre600.so
3. a module of 3d accel for r200, 300, 400 ecc named radeon_3d_pre600.so
4. a module of 2d/3d accel for igps named radeon_igp_accel.so
5. a module of 2d accel for newer r600 named radeon_2d_hd.so
6. a module for 3d accel for newer r600 named radeon_3d_hd.so

this would mean that developing of new features would hold down for some time, but there would start the integration of the code for the various drivers. from what i've read around the future is a single radeon driver that would be ok for all the boards, but with the differences in functionality and hw implementation this would require a lot of work and superfluous code just for compatibility issues.
the same fglrx could benefit from this developing by removing igp features and board detection from it. then the devs would use the atombios core module for initialization and then would put on their own 2d/3d module. for the igps, if their code is so different there's a good point of splitting them from the fglrx and readeon stuff and putting them as a single big module separated from the others. in this way the developing process would be faster in the future and there wouldn't be the need to deal with compatibility code and with regressions for older cards after the implementation of new features in the newer ones.
this would also allow amd to easily implement modules on top of various modules for a future implementation of hw hd decoding or of other features that wouldn't be opensourced if they'd want to go on that road in the future.

Zooko

02-03-2008, 10:14 AM

That's interesting that you notice Phoronix discussions to be more reasoned. You are probably right -- I haven't read many Phoronix discussions -- but I do find LWN discussions to be well-informed. I tend to think of the LWN posters as being programmers and the Phoronix posters as being users. (With no disrespect intended, of course.)

I stopped reading slashdot long ago (I started reading slashdot when it was new -- a regularly updated news source targeted at geeks! It was just another miracle of that thrilling year.) but I have always been pleased at how the level of discourse on LWN.net has never descended to slashdottiness.

Hm... Actually I left this reply written but unposted overnight, and while I was away from my computer it occurred to me that you might find the Phoronix posters to be more "reasonable" because they are saying things that agree more with your prejudices. That's completely natural of course, but it is the kind of thing that you want to be wary of if you are trying to learn about previously unknown markets -- you don't want your filters to be too good at excluding "unreasonable" customers from your view of the world.

Regards,

Zooko Wilcox-O'Hearn

P.S. I hope that you looked at those two LWN discussions that I referenced. You replied saying that LWN rarely focussed on GPU issues, and you are right, but those two discussions from last week did focus on GPU issues.

djdoo

02-03-2008, 10:39 AM

Hm I 've read the full discussion here and really found it very interesting...

@bridgman:

I can understand AMD worries about all those DRM,BD,HD restricted stuff but don't forget that Linux and generally open source system by that way of thinking shouldn't even play commercial DVD's!
And I bet that DRM and so will be hacked extremely easy and fast from our hackers.
As far as I can understand DRM is an M$ (and generally movie industry's) weapon to open source communities cause they are really aware that they are loosing more and more costumers by the every day growing Linux and rest open communities.

I happen to know a lot of people really hate and become very angry with the fact that laptop OEM companies ship their products with M$ windows and have to pay about 100 or more Euros for a really crappy OS like Vista is.
Can you tell me why they don't sell their laptops without an OS installed??

Can there be closed parts within the open source based driver for the specific restricted problematic formats and patented designs?
Do we have to maintain a fully closed driver in order to play some restricted video formats (which would be restricted for very little time in Linux)??

And finally John great thanks to you my friend cause now we have someone from the company to discuss our thoughts and of course help as much as we can too. And AMD for change the policy about Linux users!
But also consider bringing up a driver for our FreeBSD brothers...

Best Regards
Jim

Mithrandir

02-03-2008, 11:03 AM

But also consider bringing up a driver for our FreeBSD brothers...
Jim

FreeBSD can already use radeonhd.

bridgman

02-03-2008, 11:18 AM

My 2 cents are that the DRM issue should be pushed till later. The major area where work should go is into 3D support.

No argument there. This thread is not about working on DRM today. There was a (perfectly reasonable) proposal from a few people that we re-architect fglrx to use a 3d blob over an otherwise open source driver, but that causes us problems in markets like workstation, or if we are required by our customers to implement DRM in the future, so I suggested that we stay away from that discussion for a while and focus on specific things like 3d and video.

I think getting Windows games running under Linux is a much bigger priority than BlueRay since games sell graphics cards, not movies.

My sense is that games sell midrange and high-end chips and movies sell low end, high volume chips, but I agree with you about Wine. When we had a totally workstation focus Wine wasn`t a consideration, but for general desktop users it does seem important.

That's interesting that you notice Phoronix discussions to be more reasoned. You are probably right -- I haven't read many Phoronix discussions -- but I do find LWN discussions to be well-informed. I tend to think of the LWN posters as being programmers and the Phoronix posters as being users. (With no disrespect intended, of course.)

I agree with the split, although lwn seems to be a mix of developers and slashdot-style ranters. The devs are fine (and you can see them trying to keep discussion on track) but for example if you look at the Intel article there was more ranting than reasoned discussion there. I agree that if you just read the articles it`s a real good site... I just don`t find the comments to be of the same quality you get here.

Hm... Actually I left this reply written but unposted overnight, and while I was away from my computer it occurred to me that you might find the Phoronix posters to be more "reasonable" because they are saying things that agree more with your prejudices. That's completely natural of course, but it is the kind of thing that you want to be wary of if you are trying to learn about previously unknown markets -- you don't want your filters to be too good at excluding "unreasonable" customers from your view of the world.

Always a risk, and something I constantly look out for. One of the reasons for being here (and other boards) is to make sure that doesn`t happen.

bridgman

02-03-2008, 12:08 PM

then nvidia would support it and production companies would push out everything to that boards. only an agreement between hw producers to not support it would lead to its removal, but since amd, nvidia, ati, intel and other companies were the founders of drm...

Hold on there buddy ;)

We are *not* the founders of DRM. We are the companies that are required to implement it in order to sell chips. Intel developed HDCP because DRM on the outputs was a requirement from content providers in order to play HD or BD on PCs. Macrovision and (I think) CGMSA came from outside the PC industry. The rest of the standards (CSS, ACSS etc.) came from content providers and consumer electronics groups.

... the problem is that the one who will get out from it would simply lose market share and will die, unless it would come out with something that would lead community to stay tuned to it.

Bingo

the new specs would mean more driver work than implementing new code for the radeonhd driver, because from a programmer view it's simpler to write new code than modifying old code that wasn't written by you to have it fit to your needs.

The problem with starting fresh for 2d and 3d is that you effectively duplicate the code even though the HW is largely unchanged. Better IMO to have code splits based on hardware splits as you say.

why not concentrating for lets say 2 weeks on identifying the stuff that is equal in the chips and what is different. then take the equal stuff based on what it does and put it into a module, put another stuff into other module and so on. make a diagram of the various features and how they were implemented or not implemented yet, then take the driver and split it based on this new diagram.

We did that at the start of the project. That`s how we ended up with separate code for display and common code for everything else. I even have slides ;)

from what i've read around the future is a single radeon driver that would be ok for all the boards, but with the differences in functionality and hw implementation this would require a lot of work and superfluous code just for compatibility issues. the same fglrx could benefit from this developing by removing igp features and board detection from it.

Here`s where it gets tricky. The display block is totally different between 4xx and 5xx, so it needs new code, but display implemented the way we wanted will be the smallest part of the driver stack once the other parts of the driver stack are added. Since display was implemented first the issue seems simple today, but once 2d, 3d and video get in the amount of similar hardware will be bigger than the amount of different hardware.

for the igps, if their code is so different there's a good point of splitting them from the fglrx and readeon stuff and putting them as a single big module separated from the others.

Actually, IGPs are not much different. The memory management setup is a bit different (which is a huge pain if you are RE-ing but otherwise not a big deal) and the 3d engines need vertex processing in software, but everything else is the same.

this would also allow amd to easily implement modules on top of various modules for a future implementation of hw hd decoding or of other features that wouldn't be opensourced if they'd want to go on that road in the future.

It`s harder than that. Everything below the decoding would need to be closed source and tamper proofed. Between that and the closed source 3d everyone seems willing to consider, there isn`t much left.

givemesugarr

02-03-2008, 01:06 PM

Hold on there buddy ;)

We are *not* the founders of DRM. We are the companies that are required to implement it in order to sell chips. Intel developed HDCP because DRM on the outputs was a requirement from content providers in order to play HD or BD on PCs. Macrovision and (I think) CGMSA came from outside the PC industry. The rest of the standards (CSS, ACSS etc.) came from content providers and consumer electronics groups.

sorry, i was confusing this with tcg and tcpa. i think that about all the users know what it is and what the real problem is with this stuff. you're right instead about drm, which is a microzoz patent (strange). if someone doesn't know what tcg and tpca are, they're the same organization and wikipedia has articles about it http://en.wikipedia.org/wiki/Trusted_Computing_Group and about the chip that "should protect and not invade our rights" called tpm http://en.wikipedia.org/wiki/Trusted_Platform_Module

Bingo

The problem with starting fresh for 2d and 3d is that you effectively duplicate the code even though the HW is largely unchanged. Better IMO to have code splits based on hardware splits as you say.

yep, but i was suggesting that the basecode should be equal and that the split codes would be loaded by this core module based on the identification of the board. it should be easier to use and also maintain. also, maybe some devs that see a code to do something that is done in a bad way would rewrite it better. this means that new codebase would also clean out old "brutal" code present in the old codebase.

We did that at the start of the project. That`s how we ended up with separate code for display and common code for everything else. I even have slides ;)

have you showed them to the devs?! :D
i'm joking on this.

Here`s where it gets tricky. The display block is totally different between 4xx and 5xx, so it needs new code, but display implemented the way we want is the smallest part of the driver stack. Since display was implemented first it seems a lot more black-and-white now, but once 2d, 3d and video get in the amount of unchanged hardware will be bigger than the amount of different hardware.

wouldn't the splitted module help more on the cleaness of code?! also if the various different chips get maintained in different small modules is faster to find out where the problems are when modifying stuff. i'm for the split theory since i think that putting many small modules is more proficient also in the memory use, not only in the code maintenance. also if we now know that old boards cannot have better code then it should be better to split them into modules so that these modules wouldn't be touched by new code written for the newer boards. porting the new code to the old modules would be simple since there would only be the need for testing the new modules on older boards and see what happens. that should help you avoid problems like the ones with firegl boards ot working. if they'd have own dedicated modules from older releases they'd have still worked even if the new code lines for the new boards would prevented them to work.
but if the base settings and initialization of the board is different then this doesn't apply anymore.

Actually, IGPs are not much different. The memory management setup is a bit different (which is a huge pain if you are RE-ing but otherwise not a big deal) and the 3d engines need vertex processing in software, but everything else is the same.

so what they really need is just to reset the hw registers and set up the correct ones (what it seems for catalyst to do on windows at startup) to work better?!

It`s harder than that. Everything below the decoding would need to be closed source and tamper proofed. Between that and the closed source 3d everyone seems willing to consider, there isn`t much left.

i haven't said that you should do it right away. i was telling out that having the same core module for fglrx and radeon at startup would mean that in the future the 2 drivers could somehow share stuff if amd would consider the thing as a good street to walk on in the future. what problem would be to have a fglrx 3d module only that does not only 3d accel but also uvd and other stuff, but using opensource 2d module instead of fglrx one?! obviously this won't work on newer boards that emulate 2d via 3d. also since drm is present also in the kernel why not using directly the xorg drm also for fglrx?! is it so different?! having this might also get drm stuff to be better supported into the kernel itself and could also make linus consider some way of middle way between supporting these "life intrusion" mechanisms as drm and similar stuff and not supporting them at all. this is what happened when the selinux tried to get supported into the kernel and a new security layer was created. this could also happen, under the right circumstances, with this stuff. a user for example would not have this compiled by default, but if he wanted, he could compile the modules and use bd and other stuff on his pc.
i'm talking about this because i'm planning to build a multimedia home-tv center to be attached to my lcd tv and i'd like to put inside a bd viewer to be able to take advantage of the full-hd definition films. but to do that i'd need to use windows and pay a lot of money for windows tools, to have them do what they want and not what i want them to do, while i have myth-tv and a lot of other useful stuff on linux and i wouldn't be required to pay a single chip if i don't want to donate to the various projects and i'd have the apps configured and working the way i like and the way someone else likes.

bridgman

02-03-2008, 01:56 PM

yep, but i was suggesting that the basecode should be equal and that the split codes would be loaded by this core module based on the identification of the board. it should be easier to use and also maintain. also, maybe some devs that see a code to do something that is done in a bad way would rewrite it better. this means that new codebase would also clean out old "brutal" code present in the old codebase.

On the first implementation I expect the split code will be tiny and the base code will be 90+%. Most of the cruft is in the base code that doesn't change from one chip to another. I figure we're going to want to do a fresh implementation from scratch once Gallium stabilizes anyways, so why do it twice ?

also if we now know that old boards cannot have better code then it should be better to split them into modules so that these modules wouldn't be touched by new code written for the newer boards. porting the new code to the old modules would be simple since there would only be the need for testing the new modules on older boards and see what happens. that should help you avoid problems like the ones with firegl boards ot working. if they'd have own dedicated modules from older releases they'd have still worked even if the new code lines for the new boards would prevented them to work.

I agree -- if there aren't resources to test and fix issues on older boards then separate modules may be the way to go, even if they contain largely duplicated code. Downside of this is that you stop enhancing support for older boards and the owners come looking for you with flaming torches and pitchforks. If you always push changes from one module to the other then having separate modules is a waste of time. This issue is tough enough with fglrx but I don't think open source drivers should leave the older chips behind, particularly when 90% of the code will be the same. Fair question though.

Again, if I thought there would be significantly different code for the different ASIC generations then I would be arguing for separate modules. It's not that we don't understand where separate modules can be useful, it's that so much of the code *is* common across the generations.

but if the base settings and initialization of the board is different then this doesn't apply anymore.

Drivers for the current mesa architecture have a lot of code that isn't specific to the ASIC. One of the things Gallium brings is that the drivers are a lot more "pure", ie they contain relatively more chip-specific stuff and relatively less common stuff. I figure that's the time to clean house.

(IGP) so what they really need is just to reset the hw registers and set up the correct ones (what it seems for catalyst to do on windows at startup) to work better?!

That's one part. The other part is that someone has to write the code that makes up for the lack of vertex shaders. Dave Airlie did the initial work and got 3d running on RS4xx, but more work is still needed.

i haven't said that you should do it right away. i was telling out that having the same core module for fglrx and radeon at startup would mean that in the future the 2 drivers could somehow share stuff if amd would consider the thing as a good street to walk on in the future. what problem would be to have a fglrx 3d module only that does not only 3d accel but also uvd and other stuff, but using opensource 2d module instead of fglrx one?! obviously this won't work on newer boards that emulate 2d via 3d.

Simple. Protecting the decoded HD/BD images requires DRM code in the display and kernel drivers, not just the video decode/render bits. That doesn't leave much to open source.

also since drm is present also in the kernel why not using directly the xorg drm also for fglrx?! is it so different?! having this might also get drm stuff to be better supported into the kernel itself and could also make linus consider some way of middle way between supporting these "life intrusion" mechanisms as drm and similar stuff and not supporting them at all. this is what happened when the selinux tried to get supported into the kernel and a new security layer was created. this could also happen, under the right circumstances, with this stuff. a user for example would not have this compiled by default, but if he wanted, he could compile the modules and use bd and other stuff on his pc.

The kernel DRM will need a full implementation of TTM at minimum (including management of video memory and migration between pools) before it can support our client code. A lot of the features added by TTM & Gallium have been in proprietary drivers for a while. That's one of the reasons I'm saying "let's not have this discussion now".

If it was just "leaving stuff out" that would be OK, but the stuff that stays in pretty much needs to be double-implemented depending on what lower level functions are present. We also need to tamper-proof any of the secure code, and that means everything below needs to be tamper-proofed as well.

If you believe in separate code for separate functions, that argues for separate implementations of the secure/nonsecure paths, and once you do *that* you end up with an open driver which is the collection of nonsecure modules, and a closed driver which is the collection of secure modules. Plus or minus 20%, anyways.

We went through many of these discussions internally, including consideration of various open/closed hybrids, before settling on the current "two driver" plan. I think there are places where we could use open source effectively in fglrx, particularly installation and initialization/startup, but going much further than that starts to put real constraints on what we can do with fglrx in the future.

bridgman

02-03-2008, 02:00 PM

My fingers are getting tired. Can we stop talking about DRM for a while ?

;)

givemesugarr

02-03-2008, 02:43 PM

On the first implementation I expect the split code will be tiny and the base code will be 90+%. Most of the cruft is in the base code that doesn't change from one chip to another. I figure we're going to want to do a fresh implementation from scratch once Gallium stabilizes anyways, so why do it twice ?

correct observation. this means that for the moment the right thing is to continue adding features and do a full cleanup when gallium has stabilized.

I agree -- if there aren't resources to test and fix issues on older boards then separate modules may be the way to go, even if they contain largely duplicated code. Downside of this is that you stop enhancing support for older boards and the owners come looking for you with flaming torches and pitchforks. If you always push changes from one module to the other then having separate modules is a waste of time. This issue is tough enough with fglrx but I don't think open source drivers should leave the older chips behind, particularly when 90% of the code will be the same. Fair question though.

well, a workaround for this split vision might be to have the various older modules ready and to have them inserted when there are compatibility problems. for example, you release a new version but for some reason this new version doesn't work anymore on the rs400 series. at this point, you push out the oldest module that worked fine for these chipsets with the name rs400 and the driver would use that one and will use the new one for the other chips. this could be a workaround for the problems that a split duplicate code would insert.

Again, if I thought there would be significantly different code for the different ASIC generations then I would be arguing for separate modules. It's not that we don't understand where separate modules can be useful, it's that so much of the code *is* common across the generations.

well, this is good to hear, since this means that the docs released could be helpful also for older boards and that the process for implementing new features in radeonhd could be somehow faster because of already written code.

Simple. Protecting the decoded HD/BD images requires DRM code in the display and kernel drivers, not just the video decode/render bits. That doesn't leave much to open source.

well, maybe in the future someone could think of a solution for this problem...

The kernel DRM will need a full implementation of TTM at minimum (including management of video memory and migration between pools) before it can support our client code. A lot of the features added by TTM & Gallium have been in proprietary drivers for a while. That's one of the reasons I'm saying "let's not have this discussion now".

If it was just "leaving stuff out" that would be OK, but the stuff that stays in pretty much needs to be double-implemented depending on what lower level functions are present. We also need to tamper-proof any of the secure code, and that means everything below needs to be tamper-proofed as well.

If you believe in separate code for separate functions, that argues for separate implementations of the secure/nonsecure paths, and once you do *that* you end up with an open driver which is the collection of nonsecure modules, and a closed driver which is the collection of secure modules. Plus or minus 20%, anyways.

We went through many of these discussions internally, including consideration of various open/closed hybrids, before settling on the current "two driver" plan. I think there are places where we could use open source effectively in fglrx, particularly installation and initialization/startup, but going much further than that starts to put real constraints on what we can do with fglrx in the future.

ok, now i've understood why actual base merging for fglrx and radeon isn't possible, but from how you've described it when gallium arrives that will most likely happen and maybe at that time we would be able to switch from radeon to fglrx without much pain.
i'd like to thank you for the time you've spent around here giving answers to our questions and for helping us understand better how the things are going inside the developing process and on what to expect from amd in the near future and in the long term one.

TheIcebreaker

02-03-2008, 04:07 PM

duby229

02-03-2008, 04:14 PM

My fingers are getting tired. Can we stop talking about DRM for a while ?

;)

Wrong thread, but yes, I agree. :D

doubledr

02-03-2008, 04:42 PM

givemesugarr

02-03-2008, 04:52 PM

Here is my two cents. I have a seven years old box and I am still using it. Basicly I only watch tvrips and browse webs, so it is ok. However, since today's tvrips I watch are in H264 720p format mostly, my box can't do this job anymore. I don't care about BD/HD-DVD, but I do want a hardware decoder to decode unprotected H264 content. I think other people on this forum already say this. We only want H264 decoding... Bridgeman, if it is Ok to release the H264 part of UVD, please release it. If the closed source driver is the only possible choice, please please make this driver decoding unprotected H264 content too, please!

first there's the need to support hw decoding in fglrx. for example i'm not able to use my board's hw decoding capabilities (divx 5 compliant movies) with fglrx but i'm able to do this with the radeon driver. so, i suspect that either the hw decoding isn't enabled in fglrx or it isn't on my board. i haven't tried the other boards since i don't often use them. i also haven't seen anything in the release notes about hw video decoding capabilities in fglrx.

Zooko

02-03-2008, 05:06 PM

I agree with the split, although lwn seems to be a mix of developers and slashdot-style ranters. The devs are fine (and you can see them trying to keep discussion on track) but for example if you look at the Intel article there was more ranting than reasoned discussion there.

Hm... I just went back and read through the comments on the Intel article:

http://lwn.net/Articles/267436/

I can see what you mean about some of the comments having a high level of emotion, and it must feel bad to you personally when people say things like "ATI, and later AMD, have been promising to release hardware documentation repeatedly, for over 8 years. ... They've been mocking us...".

Obviously no-one at ATI was ever in the business of "mocking" customers, so this is inaccurate and inflammatory language.

On the other hand, that comment, and every comment that I looked at in that discussion, contains at least a little bit of substantive relevant fact. That particular one includes this news article: "October 21, 1999: [...] ATI announces that it will be releasing 3D programming information for its video adapters". Mentioning that fact that ATI announced that on that date isn't just ranting -- it's also pointing out something that is highly relevant to some of us -- ATI's "track record" of following through on releases that it has publicly promised.

So, while that post and one or two others in that discussion are fraught, none of the posts that I looked at were devoid of relevant facts. Contrast this with post #41 in this thread, which offers a strongly held opinion but no added facts.

It must be interesting to ATI/AMD that out of two dozen people who posted on that thread, eight of them publicly exclaimed that they were eager to replace their current discrete graphics components with Intel components because of this news, and one mentioned that he had recently purchased an integrated graphics component from Intel because of their tradition of open source. I wonder if there is any way that ATI/AMD could find out if people like those eight posters follow through with this intent: how can you tell who buys what graphics components, and how can you tell why?

(I can tell you personally that when my brother bought a new laptop last year I advised him to choose the model with Intel integrated graphics, specifically because of Intel's stellar track record of open source drivers.)

Regards,

Zooko

duby229

02-03-2008, 05:15 PM

(I can tell you personally that when my brother bought a new laptop last year I advised him to choose the model with Intel integrated graphics, specifically because of Intel's stellar track record of open source drivers.)

Regards,

Zooko

But then you have to look at the performance of the hardware, and ask yourself if it will be adequate for your needs? For most people the answer will be hell no. I'm not trying to diminish your closing statement any, just pointing out that Intel's graphics performance is much less then sub par.

Zooko

02-03-2008, 05:36 PM

But then you have to look at the performance of the hardware, and ask yourself if it will be adequate for your needs? For most people the answer will be hell no. I'm not trying to diminish your closing statement any, just pointing out that Intel's graphics performance is much less then sub par.

Yep -- you are right of course. My answer to that question has apparently been different than yours. For myself over the last decade or so, for my son's computer three years ago, for my wife's workstation this year, and for my brother's laptop last year, the answer was always that the performance of the most-open-source hardware was adequate. As I mentioned, until the radeonhd announcement, this was the Radeon 9250 (using the open source 'radeon' driver) in discrete components, and the in integrated components it was the Intel chips.

From my particular perspective, the strategic situation is that Intel was doing a good job of being open source, but a terrible job on performance, where ATI was doing a good job on performance, and a terrible job on open source. Recently, ATI nee AMD suddenly started doing better on open source, and Intel, with the aforementioned release of its graphic programming manuals, went from "good" to "just about perfect" on the open source front. Looking into the future, Intel apparently has plans to jump into new levels of performance and generality with its Larrabee project, and AMD is continuing to make progress on better and better open source support, thanks to the efforts of folks like John Bridgman here.

Now, if Intel can deliver competitive new products while maintaining its current excellent level of openness, despite the DRM pressures that John Bridgman has described here, or else if AMD can overcome those DRM pressures to achieve the kind of openness that Intel currently has, then we'll have a real winner of the little niche market that I live in.

Regards,

Zooko Wilcox-O'Hearn

bridgman

02-03-2008, 05:47 PM

Mentioning that fact that ATI announced that on that date isn't just ranting -- it's also pointing out something that is highly relevant to some of us -- ATI's "track record" of following through on releases that it has publicly promised.

That was a perfect example. What the poster missed, and others corrected them on, was that we *did* release 3d information for the then current chips (R100/R200), and that information was used to write a good part of the current "radeon" driver and the corresponding drm & mesa bits.

If someone wanted to complain that we trailed off after the R300 (when producing and releasing docs became exponentially more difficult) and only restarted recently, that would be true, but what you read is usually much worse.

oliver

02-04-2008, 12:25 AM

What I wonder though, what I don't get is, why wouldn't it be possible to have DRM support in an OSS driver? I suppose because everybody could just take that code, modify it to his own needs, and then have it unprotected, e.g. 'grab-able'. I always was under the impression if you do something properly, it can be open and secure. Security through obscurity never worked ...

It always really is only a temporary thing anyway, as the protection gets cracked anyway (just like with DVD, just like it has been done with HDDVD/BD already).

I know we all agree that DRM really only is there to annoy customers, as those who'd want to circumvent it know how to do so anyway, and those who don't care, buy their media anyway.

I fully understand why AMD has to support it, no questions there. You wanna feed your kids, Others make you do it pretty much.

It's just a shame to have developer resources split across all these things.

All in all, I'm glad Audio DRM is slowly going away. It's hurting the consumers, those who actually buy it.
Whether the same will happen for video ... maybe people are becoming more aware. In the old days, we always fast forwarded past the copyright stuff. So no issues there, on copied VCR tapes, you would have already skipped it and never noticed it. With DVD's it became annoying, that you coudln't skip it. Was it annoying to hackers, kids who download their stuff, people who copy them? They didn't care. It only annoyed people who actually bought the thing.

Anyway. Sorry to have ranted about DRM, again. I know your fingers where getting tired as it is :) I joined this discussion late.

Here's hope, that we one day have one solid mighty performing open source driver, with a closed source DRM module (fine, it would be a rebuild driver with the DRM module embedded) that makes everyone happy :)

P.S. Thanks John, for giving us feedback. I can only imagine how many hours per day are burned keepying you from real work, but it's AMD's company image you are strongly improving. It's geeks like us that make decisions for a lot of peoples purchases, if that is the mattering part. But having a community of geeks speaking highly of you and supporting you should be worth more then just hard cash earned ... Thanks from all of us.

sloggerKhan

02-04-2008, 02:25 AM

I don't care about the ability to decode DRM'd crap.

I just want decent hardware video decoding for un-DRM'd stuff.

No offense, I don't know 1 person who owns something outside of an xbox that has an optical device for HD playback. Not one. Yet I still know tons of people who watch various unencrypted h264, xVid, theora, mpg4, etc., on their computers. The only, and I mean only, DRM'ed format I see people using is DVD, which everyone and their brother circumvents anyhow, whether it's because they want to make backups or skip the warnings, ads, and trailers.

You guys are just part of a collusive anti-consumer industry, which must suck.

Personally, instead of modularity, I think you should just do one open source driver that works right instead of having all this monkey business with like 3 drivers, none of which actually work well.

I do appreciate your guys efforts, and I know hearing this stuff must be frustrating and discouraging, but there are those of us who own ati cards which no matter what driver we use basically function at like 60% of what they should because with every driver there is some stupid trade-off based around stuff like this discussion.

Just give me working 3-D, decent video playback for unprotected video, and monitor autoconfiguration that actually works properly in one driver and I'll be happy. Until you've done that, worrying about DRM is putting the cart before the horse.

Svartalf

02-04-2008, 09:40 AM

Why would Crysis (or any other game for that matter) on Linux have an issue with the open driver? Am I missing something here?

I'm not QUITE sure what he was getting to on the comment about Cysis. In all honesty, if the drivers perform, as a developer on consulting contract for a publisher, I don't think anyone gives a flip about whether the driver's proprietary or not. R200 support works pretty well. Well enough to support some of the titles we've done in the past. It's open. It works. fglrx currently doesn't support some of the functionalities that are present in all the other drivers that are relevant for the games in progress. It works, but only sort-of, and on only really well on select GPUs. It's closed. The lack of FBO support is obnoxious because we'd LIKE to rid ourselves of the PBuffer type programming needed to do dynamic texture support that is needed for some types of games we're porting.

THAT, folks, is what studio cares about.

bridgman

02-04-2008, 09:41 AM

Just give me working 3-D, decent video playback for unprotected video, and monitor autoconfiguration that actually works properly in one driver and I'll be happy. Until you've done that, worrying about DRM is putting the cart before the horse.

Amen to that. I should probably remind everyone that I'm not arguing *for* DRM here, I'm saying "let's not talk about rearchitecting fglrx to an open/closed hybrid (because of complications like DRM and the workstation business) until those basics are running".

It was the weekend though, and the open/closed hybrid question is an interesting one which we talked about a lot internally and I thought deserved an answer here. Problem is that even the mention of DRM does push a lot of buttons ;)

bridgman

02-04-2008, 09:43 AM

Svartalf, is there a Bugzilla ticket open for the specific FBO stuff you see as missing ?

AFAIK the new OGL stack has FBO support so maybe it isn't being exposed properly or something.

Svartalf

02-04-2008, 09:49 AM

I wonder if there is any way that ATI/AMD could find out if people like those eight posters follow through with this intent: how can you tell who buys what graphics components, and how can you tell why?

Heh... I'm one of the type that followed through on the comments. When I got my next laptop and when I bought my GPU for my new desktop setup, it was NVidia that I bought. Had AMD had a more compelling story at that time (They're looking much better now than when I bought- I bought because of years of suppar support of their products...) or had Intel real functioning, compelling discrete parts, I'd have bought much differently. Open's very important to me- but performance and stability is even MORE important to me. AMD's currently, unfortunately, not there in that regard- though it's shaping up nicely, though not fast enough for my liking. Intel's beginning to shape up in that space- the GMA X3500's something of a decent low-end performer if the benchmarking's to be believed.

Raven3x7

02-04-2008, 12:51 PM

First Bridgman thanks for openly participating in this discussion. Its nice to know where AMD stands and i can fully understand the reasoning for the current situation. I have to say most traditional linux people will not care about accelerated DRM HD playback but most would want some none-DRM HW decoding. I have an offtopic question though. Any chance hybris graphics will be supported in Linux at some point in the future?

bridgman

02-04-2008, 03:56 PM

glisse

02-04-2008, 05:00 PM

As far as I can see we will be able to provide all the HW info required to implement hybrid graphics, but it requires a lot of driver work at all levels of the stack. Probably will have to wait for a full rollout of TTM as well.

In fact i believe linux will be able to be a lot more better on hybrid graphics than windows. If i am correct on windows you need to reboot to have the low performance gpu. With open source we should able to do the swap while running without reboot (if hw doesn't forbid this).

Svartalf

02-04-2008, 05:36 PM

Svartalf, is there a Bugzilla ticket open for the specific FBO stuff you see as missing ?

Not yet. I'll be honest and admit it's been a little bit since I last looked at the drivers since I've been a bit busy with a raftload of things on my plate...

AFAIK the new OGL stack has FBO support so maybe it isn't being exposed properly or something.

I'll have to recheck- last time I checked, it didn't seem to be working right for whatever reasons. I'll admit that I've been a bit busy for words (Heh... Trying to get a couple of games straightened out for LGP, sample Linux applications for a new eval board for a new ADI part, a couple civil actions, some of my own making, some of others' have kept me quite a bit distracted lately)- I didn't have much time to follow up on what was busted when I found it not working.

If I'm in error because of changes somewhere along the way that I've missed, I'll retract my claims- if not, I promise to get the bug logged so you guys can fix it. I definitely don't want to be part of the ongoing problems here. :D

domi

02-06-2008, 04:02 AM

First of all, I'd like to thanks Bridgman and AMD for all discussion. I do not always agree but the discussion is always welcome :)

The obnoxious restrictions that encumber formats like BD/HD make these completely incompatible with the spirit, shape and form of free/open-source software. Why should the community even bother supporting them?

Err, in this instance, AMD would support the driver. It still will be uncomfortable for the user because support will come from AMD and open source community. So deciding whom to contact to report a bug will not be easy.

Please also take into account what will happen if users will have a choice between:
a) open-source driver, stable and good in some areas
b) closed-source driver, more-or-less stable :-P and good in totally different areas

Taking into account video playback, I think the choice will be more like:

a) open-source driver, stable, 100% legal, no video playback, easy to find support
b) open-source driver, stable, (maybe) video playback, legal problems in most countries (because of decryption code), easy to find support (except may be for the decryption stuff)
b) closed-source driver, more difficult for support (need to reproduce a bug without closed source driver to get community support)

Anyway, the fact that people will have a choice is always good (even if puzzling for new users :p )

bridgman

02-06-2008, 04:28 AM

Err, in this instance, AMD would support the driver. It still will be uncomfortable for the user because support will come from AMD and open source community. So deciding whom to contact to report a bug will not be easy.

The open source drivers are all "community supported" and have a single point for bug reports. The community member who helps may work for AMD or not -- it's invisible to the user. One of the decisions we made early on was to work within existing xorg support mechanisms (mailing lists, IRC, bugzilla) rather than setting up AMD-specific forums etc...

Taking into account video playback, I think the choice will be more like:

a) open-source driver, stable, 100% legal, no video playback, easy to find support
b) open-source driver, stable, (maybe) video playback, legal problems in most countries (because of decryption code), easy to find support (except may be for the decryption stuff)
b) closed-source driver, more difficult for support (need to reproduce a bug without closed source driver to get community support)

Anyway, the fact that people will have a choice is always good (even if puzzling for new users :p )

Since the Linux community tends to... um.. decrypt first and playback second, I don't think this will be an issue. The open source drivers will have video and will not be doing decryption so I don't think there will be any legal concerns.

Not sure what you mean about repro-ing a closed source driver issue on open source to get support -- that only works if you switch to the open source driver. There are pretty good support forums for the closed source driver (Phoronix for example) and the request is normally "post your logs" not "repro on an open driver".

We're trying to keep the driver choice simple. Most distros will include the open source driver, so that's what we expect people to use by default. Users would upgrade to the closed source driver to get specific features or performance not available in the open source driver. OEMs shipping SKUs with Linux preloaded could choose either, depending on the features they needed and on whether they were looking to the distro or to AMD for integration support.

gfxdrone

02-07-2008, 01:26 AM

Bridgman, you asked a question re GNU/Linux market penetration a while back in this thread, if it was expected to rise 10x. Since you are the first real sign of actual openness I've seen in a few years from ATI, I thought I'd give you some reasonably accurate stats.

I'm connected to a fairly large financial products website, that caters to what can be called a true 'average' user base. I've used this for several years to check where GNU/Linux is actually at.

A few years ago it was hovering at around low 0.15-0.25% Linux re total sessions, eg, Windows, Mac, Linux, but I just checked it again, and much to my surprise, that is at about .6%, a very significant rise if you consider the extremely conservative nature of the site's demographic, and their age (older, few under 40 I'd guess). The visitor numbers are high enough to be statistically solid and meaningful, this site will not experience any fluctuations year over year based on fads. These are real.

So in answer to your question, will Linux use increase 10x in the near future? I seriously doubt it. Unless of course you take as your starting point the roughly 0.25% market share Linux based desktops have had over the past years. Then, yes, 2.5-3% market share is looking more and more realistic. I believe that it will break roughly 2, maybe 3% real world market share in the next few years. After that it's too hard to tell what will happen. Given the near universal loathing of vista, coupled with the continuing legal suppression of MS by the antitrust stuff, which basically forces MS to stand by and do nothing while companies like ASUS, release very popular non MS running laptops and desktops, it might just really start to grow, and even now Dell (although their real numbers are miniscule at this point). Firefox went from very very low numbers to about 15-20%, much more in some countries, in relatively no time at all, a few years. Suddenly a lot of people just got sick of the MSIE nonsense, the insecurity, the active x holes, all that.

But given recent developments like the EEE from ASUS, and some other products which are getting quite popular, without catering at all to the geek crowd, it's entirely possible that the numbers could go even higher. I believe I read that EEE is selling in the millions currently, and Asus can't keep up with demand.

And this is not to mention the rest of the world, where more and more major movements, large scale corporate rollouts, you know the ones, 10k here, 20k there, entire regions in Spain, all going Free software, and not using chips that won't work, at this point, that means Intel only.

Hopefully this is the kind of information you were looking for. Obviously, always ignore any stats from tech oriented sites, those are totally worthless in terms of deducing real world market share. And don't even read those silly Linux stats from opt in visit sites that get trumpeted as if they have any meaning at all beyond a distrowatch like willingness to boost GNU/Linux numbers by visiting the pages over and over...

This thread is the first sign of actual open communication I've seen with AMD/ATI, and it's long long long overdue. We'll see how the radeon and radeonhd do, currently our users are basically screwed if they are running the R300/350 series. Only intermittent fglrx support. Advice to our users, and any other users, for this year: wait and see what really happens, next year, maybe start buying ATI again, but only if fglrx support improves and remains steady and consistent.

Good luck on getting this stuff working better. Improve your tracking of new kernels and xorg, minimize installation problems, make sure your released installers actually work, or don't release them, that's the distro specific stuff. Your quality has been junk for years, you have a lot of ground to make up to regain the user trust, it's up to you, not the users at this point.

We offer basically one click switch between radeon(hd) and fglrx for users, and that's proved to be necessary after break after break in fglrx forces users who can to go to the free drivers. Every day I read new bug reports from our users, but we no longer offer active support of ATI installer driven fglrx because it's too time consuming to track, and nobody is paying...

domi

02-07-2008, 03:44 AM

One of the decisions we made early on was to work within existing xorg support mechanisms (mailing lists, IRC, bugzilla) rather than setting up AMD-specific forums etc...

That's excellent news :)

The open source drivers will have video and will not be doing decryption so I don't think there will be any legal concerns.

For AMD or Xorg, no there won't be legal concerns. My point was that it may be another story for the user. Currently, to view a DVD on a Linux machine, I have to load css lib which are in a gray legal zone. For some folks in some countries, it will be a relief to have a driver (even if closed) that enable them to view DVD without installing legally-gray and harder to find decryption libraries. This will also apply to BD or HDDVD.

Not sure what you mean about repro-ing a closed source driver issue on open source to get support -- that only works if you switch to the open source driver. There are pretty good support forums for the closed source driver (Phoronix for example) and the request is normally "post your logs" not "repro on an open driver".

Well, in kernel land, the answer is generally "remove this proprietary driver, reproduce the problem, then we'll talk".

On Xorg mailing list, they won't hear about problems involving proprietary driver. For AMD/ATI users, it may be hard to decide if the issue is a fglrx problem or an Xorg problem.

If Phoronix can be used (an advertised) as a single point of support for AMD/ATI problems, then users should be fine. In this case, Phoronix should redirect the queries to Xorg mailing list when needed.

We're trying to keep the driver choice simple. Most distros will include the open source driver, so that's what we expect people to use by default. Users would upgrade to the closed source driver to get specific features or performance not available in the open source driver. OEMs shipping SKUs with Linux preloaded could choose either, depending on the features they needed and on whether they were looking to the distro or to AMD for integration support.

Good.

Thanks for the explanations

damentz

02-07-2008, 10:23 PM

I have to load css lib which are in a gray legal zone.

Come on, be honest. You know its un-enforceable to prevent people from installing those libraries. Its like a common sense things to install on every new install of linux on my systems. I wouldn't even worry about that.

duby229

02-07-2008, 11:16 PM

Come on, be honest. You know its un-enforceable to prevent people from installing those libraries. Its like a common sense things to install on every new install of linux on my systems. I wouldn't even worry about that.

Yeah it would effectively be telling us that we cant watch dvd movies becouse of our choice of operating systems. Can you imagine the shit storm that would follow.

I would actually love to see it go to court. That would be wonderful. If ATi is unwilling to kill DRM, that theoretical court case might possibly do it. And if not then it would certainly put a big dent in the system, and provide the good guys with some precedence for our cause.

Redeeman

02-08-2008, 03:41 PM

Reedman: Read post #20 of this thread.
and that essentially means: Yes, we WILL spit on the private customers so that we may sell to oems, which btw, are doing completely stupid stuff..

i'd like to have heard from bridgman what AMD's official answer to my direct questions are.. but i guess that wont happen, as all the AMD highups are too spineless to actually admit that they are a bunch of ba******

bridgman

02-08-2008, 04:05 PM

and that essentially means: Yes, we WILL spit on the private customers so that we may sell to oems, which btw, are doing completely stupid stuff..

It's not just OEMs who need this. Board manufacturers also want WHQL certification, which means that the protection mechanisms have to be there in both the GPU and the driver.

I think you're suggesting that we build different GPUs which operate without the protection mechanisms, targetted only at the Linux consumer market ? The problem with that, to be blunt, is cost of development vs. the sales we could reasonably expect -- even a tiny change to a modern GPU costs millions of dollers in fab charges for each GPU and I imagine we would at least need a high end and low end GPU per year -- and as far as we can see there isn't anywhere near enough market to cover the costs. What we *can* do is develop drivers which give you the benefits of the hardware without the restrictions of the protection logic -- once that is done, what do you see as the remaining problem ?

i'd like to have heard from bridgman what AMD's official answer to my direct questions are.. but i guess that wont happen, as all the AMD highups are too spineless to actually admit that they are a bunch of ba******

Sorry, I thought I had covered your questions with previous answers.

Does AMD/ATI feel they wish, and that its better for them, to babysit the complete and utter stupidity of some totally clueless and moronic content providers, to keep them believing in FALSE "truths", rather than directly giving their own customers what they want?

Not really. In order for our products to get to our end customers, we first need to sell them to OEMs and board manufacturers, and *those* groups both require what *they* perceive as a legal solution for HD/BD playback, which usually means the combination of a MS operating system and a certified player app. For SD DVD there is a bit more wiggle room and as far as I can see we should be able to open up that part of the hardware to the dev community so they can implement completely DRM-free drivers.

I already have a pretty good idea of the answer, but i would like for you to go to whomever is in charge around there in AMD/ATI, and ask them this question, because im really interrested in it, and this should clarify just how far AMD will be going, who their loyalties really is to, stupid content providers, or the customers who put the food on the table(well, ill bet some of those higher-ups of AMD gets alot of food on their own personal table from clueless content providers, but thats a different story).

Again, see above. The problem is that we don't sell chips to you directly -- we sell chips to companies who build PC products, and *those* companies have legal requirements to... well, you get the idea.

I have to admit I don't fully understand this last question. Are you suggesting that we should refuse to participate in the bulk of the Windows market and try to survive selling only DRM-free products into the Linux consumer market ?

Kano

02-08-2008, 04:12 PM

Do you know that the intel driver has a possibilty to load a binary part? This is not yet used but how about that way?

bridgman

02-08-2008, 04:17 PM

I believe Intel did use the binary mechanism for a while then stopped. I'll try to ask Keith about it at FOSDEM, but my guess is that they found it was a good approach for SD DVD but wasn't sufficiently secure for HD/BD. There are also rumours it was only used for a shader optimizer and had nothing to do with content protection, so it's anyone's guess.

We will look at all those options. I just don't want to get anyone's hopes up about UVD unless we have a solution in hand. Right now I'm pretty confident about the IDCT/MC blocks but less confident about UVD.

Zooko

02-08-2008, 04:37 PM

Hello bridgman. Zooko here with your regular LWN sales pitch. LWN's coverage of LCA talks on X:

http://lwn.net/Articles/268378/

include Your Editor, Jonathan Corbet, reporting that "word on the street" is that the radeon driver is likely to be the winner over the radeonhd driver.

Regards,

Zooko Wilcox-O'Hearn

Michael

02-08-2008, 04:40 PM

I believe Intel did use the binary mechanism for a while then stopped. I'll try to ask Keith about it at FOSDEM, but my guess is that they found it was a good approach for SD DVD but wasn't sufficiently secure for HD/BD.

Intel's binary module for their video driver was optional and had just contained Macrovision registers and some 3D optimizations. (Though I never noticed any performance difference.)

There was a discussion about it last year on the xorg or LKML that I'll see if I can find.

Michael

02-08-2008, 04:44 PM

There was a discussion about it last year on the xorg or LKML that I'll see if I can find.

Macrovision confirmation:
http://lkml.org/lkml/2006/8/12/10

3D confirmation:
http://lists.freedesktop.org/archives/xorg/2006-September/018437.html

glisse

02-08-2008, 04:59 PM

On Xorg mailing list, they won't hear about problems involving proprietary driver. For AMD/ATI users, it may be hard to decide if the issue is a fglrx problem or an Xorg problem.

If Phoronix can be used (an advertised) as a single point of support for AMD/ATI problems, then users should be fine. In this case, Phoronix should redirect the queries to Xorg mailing list when needed.

Xorg people are ready to provide support on things we can fix, if we start helping user with closed source driver we are heading for a lot of wasted time. So we simply don't provide any support and you likely will have a crude answer from one of us.

Phoronix is not where we want to see bug report, if you face a bug go to bugs.freedesktop.org and try to check if there isn't yet a but similar to the one you are facing if not then open a new one and provide enough informations. Meanwhile phoronix.com also provide a good place to look for help & informations.

My point is that there is already a central place where user can find support and where he should report problem. Every things is on freedesktop.org. There is several wiki their and we are always looking for people to contribute to it (for instance you can documents their how you worked around a problem you had or any others revealent things).

glisse

02-08-2008, 05:14 PM

I would actually love to see it go to court. That would be wonderful. If ATi is unwilling to kill DRM, that theoretical court case might possibly do it. And if not then it would certainly put a big dent in the system, and provide the good guys with some precedence for our cause.

It's not up to ATI to kill DRM. DRM have been sell by few big IT company to big media company (some being the same company). They did sell DRM by telling that this will help to create new market like pay per view, or renting. They also lied to the media company by stating that this drm would protect them from piracy, which you can't given the amount of money several illegal organization make by breaking this protection.

So in the end it all boils down to wait for media company to understand that they are just shooting themself in the feet with DRM and that their legal user have less freedom than their illegal one and once enough people realize that it won't last long.

In the meantime their is a market which ask for DRM capable hw whether you like it or not. AMD could not afford not being on this market.

Will linux grow support for new DRM, maybe but i don't think so given how apple had to include things in their kernel. I don't think linux kernel community will accept any invasive change. So we will likely stay away of this things.

As an end note, in the whole world there is very few people really aware of what is DRM, what it does, how did it appear, and why it's useless. Not every people read technical things, in fact most of people prefer to skip this kind of things :)

djdoo

02-08-2008, 06:01 PM

@glisse:
I totally with you my friend and i think we have made this DRM thing a software CIA agent here.

I can remember almost same discussions about the macrovision restrictions of the normal DVDs a few years ago then someone(as usual...) broke that thing and we can all playback, rip, copy industrial Video DVDs under Linux.

So why DRM should be a difficult situation for our hackers?

I understand that OEMs are asking for that DRM cause they want be legally covered but against who?
Who is the one that will take the OEM company to the court if it doesn't use DRM??
The movie industry?
That is what I don't understand...

Redeeman

02-08-2008, 06:22 PM

It's not just OEMs who need this. Board manufacturers also want WHQL certification, which means that the protection mechanisms have to be there in both the GPU and the driver.

I think you're suggesting that we build different GPUs which operate without the protection mechanisms, targetted only at the Linux consumer market ? The problem with that, to be blunt, is cost of development vs. the sales we could reasonably expect -- even a tiny change to a modern GPU costs millions of dollers in fab charges for each GPU and I imagine we would at least need a high end and low end GPU per year -- and as far as we can see there isn't anywhere near enough market to cover the costs. What we *can* do is develop drivers which give you the benefits of the hardware without the restrictions of the protection logic -- once that is done, what do you see as the remaining problem ?

Sorry, I thought I had covered your questions with previous answers.

Not really. In order for our products to get to our end customers, we first need to sell them to OEMs and board manufacturers, and *those* groups both require what *they* perceive as a legal solution for HD/BD playback, which usually means the combination of a MS operating system and a certified player app. For SD DVD there is a bit more wiggle room and as far as I can see we should be able to open up that part of the hardware to the dev community so they can implement completely DRM-free drivers.

Again, see above. The problem is that we don't sell chips to you directly -- we sell chips to companies who build PC products, and *those* companies have legal requirements to... well, you get the idea.

I have to admit I don't fully understand this last question. Are you suggesting that we should refuse to participate in the bulk of the Windows market and try to survive selling only DRM-free products into the Linux consumer market ?
Im suggesting that what you(not you personally, but AMD) are doing is caving in to totally clueless stupidity. the DRM is broken, and it _ALWAYS_ will. If the DRM actually served a good purpose i might, MIGHT be willing to accept that you sacrifise the very small user base, in favor of the large one. This is not the case however, so what you are doing is essentially bowing down because OEMS are clueless and doesent understand the reality of things.

If i were AMD, i would be pressuring them, or at the very very least, make sure that the drm crap is totally separate, to not sacrifise the smaller groups, who pay more for less(which it seems you MAY do for the next-next-gen ones.).

but what i would expect and think AMD should do, is to pressure OEMS, and microsoft. lets face it, AMD cannot compete in the performance area, be it cpu's or gpus, but this is gpus, and nvidia has the performance crown, and that doesent seem likely to change soon, so why do people buy amd/ati? because its slightly cheaper. And this matters to OEMS, and OEMS matters to m$, as those are what keeps them in power. So i say, tell the OEMS they can shell up more for nvidia, or put pressure on m$. hell, if you didnt have to develop drm crap you might be able to sell such a chip for $1 cheaper, or $0.5. This matters if an OEM is about to buy 10 million chips.

but that wasnt really relevant, my question was, if AMD prioitizes catering to the needs of completely clueless and useless opinions of content providers and those oems, than the people who go out in shops and buy a retail AMD/ATI chip.

alternatively maybe you should have some sort of "pay for what you get" policy, kindof like how it is EVERY OTHER INDUSTRY. so that if AMD disallows me to use some feature, they dont charge me for it.

Basically what im asking is, what compells me to, and what justifications is there, for having me pay full price for a piece of hardware, which AMD tells me i must not use - and i dont mean drm, i dont give a damn about that, what i do care about is the video decoder itself, which should be a generally available video decoder.

From where i stand, this is no different than if some car dealer sells a 5 gear car, and since im male, the car dealer does nothing, and i can enjoy all 5 gears, but if a female shopper bought the car, the car dealer would put a big fat lock and chain on the fifth gear, and still charge full price, advertising it as a 5 gear car.

i realize that OEMS and m$ to some degree are against you, but from my perspective, given the information i have(and if its incomplete, i would suggest that a priority should be to get the real stuff out here), AMD is doing far from all it could, and basically all of these things would be in its own interrest.

What do AMD get out of this? well.. people like me typically influence alot of shopping. I work as a consultant (IT related), i do all sorts of stuff. Stuff i regularly do is get contacted for advise on what to buy. This is not so attractive to me per se, as i am primarily a developer. However i have started seeing it from a much bigger perspective. If i get to basically decide what hardware gets bought, in somewhat big quantities, i can that way show with dollar signs what i want. And this is just to say, AMD is loosing big time. i realize that you have much bigger customers than for example 1-10k pieces of hardware (gpu and/or cpu) each year, but im just 1 person. And i can tell you now, I do not recommend AMD, and i given the information you have provided, i do not see this changing any time soon, and take this from me, never in my life before have i ever bought intel cpu's - well guess what, now i recommend to EVERYONE to get intel stuff, and theres a huge trend for shifting to laptops now - and well, thats really nice, since intel has graphics and cpus, and they act the best there is on the market today, so i recommend them. I would love to recommend AMD/ATI even for desktops, unfortunately i cannot do that, as well.. intels desktop graphics is fast enough for the vast majority, and well...

well.. im still not nearly an OEM, but im here, and theres more like me.

just try to understand, AMD's bowing down to clueless moron OEMS doesent actually help you, Try to educate them, and you'd get a whole slew of benefits you(well, your boss(s) anyway) probably cant even imagine.

The free/open -source community can be a very great asset, not to mention alot of users who doesent care, but simply would be HAPPY customers.

so i ask, is AMD currently involved in trying to educate OEMS, which you indicate is a big showstopper for you actually doing what end users want, or do you just bown down without caring? (again, by "you", i mean AMD/ATI, not you personally)
Because if indeed such efforts are under way, it would count big time towards what i percieve as trying to act in the end users interrest - the only thing i could see you do much better then, is to just no matter what they think, make hardware that has features available for everyone. DRM is inheritly something we do not give a damn about, so its naturally we dont care about info on getting that to work - but video decoder, we care very much about that(well, intel(hehe, them again) is helping alot with getting that care away, by putting out extremely powerful cpu's much cheaper than AMD(hello E8400)), but still, this is a feature that SHOULD work without drm, and if it indeed did, i wouldnt care about drm not being available.

So i can only hope AMD's newer hradware will have this separate as it really really should be, and that you ofcourse also would try to go in and educate clueless OEMs, instead of just letting them terrorize end users, because even though the OEMS might "force"(i dont believe in that, ultimately its AMD that decides to do it, but they do apply pressure), its not the OEMs i see as the "bad guy". I do not buy from OEMs, i buy from you(well, via some card manufaturer). and im sorry to say, its you i see limiting me when i cannot use my hardware(not that this is happening, as i do not have such new ATI hardware)

Well.. this was a long message, but i hope you can use some of what i've written to improve relations/products towards us, and in turn, help AMD. Because i really always only bought AMD, but today, the reasons against it is just so very very big, while the reasons for are.. well... not quite so big.

bridgman

02-08-2008, 06:37 PM

its not the OEMs i see as the "bad guy". I do not buy from OEMs, i buy from you(well, via some card manufaturer). and im sorry to say, its you i see limiting me when i cannot use my hardware

OK, let me try again.

OEMs and board vendors want Windows drivers. Without WHQL certification the drivers won't install. You don't get WHQL certification without the DRM support, whether you are AMD, Intel, NVidia, or anyone else.

ATI has always been the most outspoken company in the industry about DRM. You are having this discussion with an AMD/ATI employee, not someone from another graphics vendor even though everyone implements the same DRM capabilities and everyone has the same challenges in the Linux market. Do you think we are the only ones who implement DRM ?

I honestly don't understand why you are picking on us rather than other graphics vendors. I hate to think it's because we are the only ones willing to actually talk about it.

glisse

02-08-2008, 06:43 PM

Im suggesting that what you(not you personally, but AMD) are doing is caving in to totally clueless stupidity. the DRM is broken, and it _ALWAYS_ will. If the DRM actually served a good purpose i might, MIGHT be willing to accept that you sacrifise the very small user base, in favor of the large one. This is not the case however, so what you are doing is essentially bowing down because OEMS are clueless and doesent understand the reality of things.

If i were AMD, i would be pressuring them, or at the very very least, make sure that the drm crap is totally separate, to not sacrifise the smaller groups, who pay more for less(which it seems you MAY do for the next-next-gen ones.).

I haven't read carefully all post but from my understanding of previous conversation i did have with AMD peoples is that the video decoding capabilities are tightly tied with the video content protection system. As such giving the informations on video decoding will lead easily to find out the protection system things, and like all of DRM in computer nowadays, it relies on the obscurity ie if you know one of the piece in chain you can break the whole easily.

On the other hand, i believe AMD is designing its next hw in a way where they can split decoding and DRM things ie where they can expose without any risk decoding. You must understand that current hw have been designed years ago when ATI had not commitment to open source and so just didn't care to split DRM from decoding.

I am sad about it but this is just how it's right now. But i am pretty sure using the 3d engine we can accelerate enough things to remove some pressure of CPU. Well we still have big bunch of code todo before getting their :)

Just a side note years ago their was hack to disable macrovision on nv or ati hw, if such things happen nowadays i believe any of this company will have to seriously increase the payroll of their layers :(

djdoo

02-08-2008, 06:57 PM

WHQL... So that's the problem here... WHQL certification does not come without DRM. Bingo!

Without WHQL certification the drivers won't install.

So it is not the movie industry, Microsoft is the Blocker! and OEMs just do what Mr Gates wants.

God Bless America... We are facing a global software dictatorship here guys!

Now Mr Gates is making business with countries and my country Greece became one of them very recently. We are totally holded by the b****.

Svartalf

02-08-2008, 07:04 PM

I haven't read carefully all post but from my understanding of previous conversation i did have with AMD peoples is that the video decoding capabilities are tightly tied with the video content protection system. As such giving the informations on video decoding will lead easily to find out the protection system things, and like all of DRM in computer nowadays, it relies on the obscurity ie if you know one of the piece in chain you can break the whole easily.

The encryption is separate from the actual data stream in pretty much all aspects- otherwise you wouldn't have MPEG1/2/4 or h.264 software decoders on Linux in the first place. The reason I've been able to ascertain that they don't have them as separate components is that the media companies are so damned paranoid someone will dip into the decrypted stream that they have to prevent a separation of the two functionalities so that you "can't" do it. Unfortunately, they've not quite twigged onto the reality that at some point you HAVE to break it apart to show it to a human being, especially if you want to get PAID for producing it.

Heh... Most of what they're worried about is like locking excrement in a safe and then locking the safe inside a safe, really.

I'd be looking elsewhere for hardware boost of operations, really- you're not going to get ANY traction out of companies like AMD for some time yet. Probably until either the media companies wise up, or the computer industry as a whole wakes up from the delusion that they actually "need" the media industry to keep themselves going at the levels they're at. Sure, they are helping it along- but they're not needed by the other.

bridgman

02-08-2008, 07:06 PM

In fairness, it's still the content providers who hold the cards. Microsoft made the effort to come up with technical proposals which the content providers would accept, making it possible for PC equipment suppliers to "legally" (and yes, I understand that means different things in different countries) play HD content on PCs.

It's important to understand that this is something the PC industry in general *wanted*. I have heard here from many users that video playback is one of the key things they do on their systems, whether through a certified player app or some other means, and being able to offer HD playback in all countries is a huge boost to the PC industry.

You can probably blame Microsoft for organizing the party, but most of the players were going to party somewhere anyways.

djdoo

02-08-2008, 07:07 PM

@bridgman:

Alright then can we just have Crossfire and XvMC support on either of the 3 drivers for now?(And the bugfixes for fglrx AGP HD problems and the rest)

And after that we can discuss DRM stuff with cleaner minds...

Svartalf

02-08-2008, 07:09 PM

WHQL... So that's the problem here... WHQL certification does not come without DRM. Bingo!

So it is not the movie industry, Microsoft is the Blocker! and OEMs just do what Mr Gates wants.

Heh... All they did was sell the media industry on DRM like a few other players (looks Sony's way...), making them think they could control all the content, make things more pay for play, and keep people from copying things so that they'll be forced to buy and buy even though the law allows making copies for personal use under many circumstances.

It's not just Bill and Co. It's all the execs at the RIAA member labels and all the execs at the MPAA member studios doing this stuff more than the rest. They're the ones clamoring for it. DRM wouldn't be a big deal if you didn't have them with the pull they seem to have all over the place. DMCA wouldn't be law either.

bridgman

02-08-2008, 07:15 PM

Alright then can we just have Crossfire and XvMC support on either of the 3 drivers for now?(And the bugfixes for fglrx AGP HD problems and the rest)

And after that we can discuss DRM stuff with cleaner minds...

That sure seems like the highest priority to me :)

djdoo

02-08-2008, 07:21 PM

@Svartalf:
Hm... So these guys found their saviour for PC industry at Microsoft and Mr Bill... I see no light for now unfortunately.

@bridgman:
I forgot to tell at the previous post about simple XV for my IGP X1250...I really hate to boot into windoze env in order to watch a movie correctly whereas in linux we have a much better and newer video playback architecture than WinXP has. I used to use XvMC with my old GF FX 5200 card for DVDs and quality and performance was truly excellent, although nvidia driver has problems with XvMC if Xine didn't crash you could see big difference between Xv and XvMC.
Much, much lower CPU usage, precise audio-video synchro and even better colours!
And with my new X1250 I cannot even use XV overlay! It's a pity for the hardware man!

Jim

djdoo

02-08-2008, 07:28 PM

That sure seems like the highest priority to me :)

But I am truly happy that you(and I hope AMD too) see the situation from this point of view for present speaking!:)

Jake

02-08-2008, 10:09 PM

Okay, I'll bite. Let's break this down a bit.

DRM is a form of content protection - but for digital, it is no different than Macrovision, CGMSA and so on. Content protection is a technical mean to enforce copyright rights. Hopefully we can all agree on that. Let me repeat. It is a technical means to enforce copyright rights. I will continue to use Content Protection (CP) instead of DRM for clarity.

As a human, we don't like being told that we aren't trusted. We are fundametnally talking about a technical means to enforce copyright rights because the copyright owner doesn't trust us.

Now let's play a game of swap the players nouns and pronouns.

DRM allows the MPAA to ensure you don't copy movies.
Technical means of copyright protection allows the copyright owner to ensure you don't violate the copyright owners protected (copyright wise) works.
The GPL_ONLY flag allows the Kernel Developers to ensure you don't derive from their kernel code.

Now I know people will claim but it's different, both are interpretations from the copyright holders point of view, not the users. Interpretation is just that.

This view is not just mine, here is a good link from LKML.

When we try to dictate what people are doing in the privacy in their home, we're no better than the MPAA or the RIAA.
http://lkml.org/lkml/2006/12/16/131

Play the swap the nouns and pronouns a bit in a lot of the posts in this article, and a surprisingly large number would look quite bad from the kernel developers point of view.

I am not saying DRM is right, but I am saying that it is just as right as the GPL_ONLY flag in the kernel.

Regards!

Zooko

02-09-2008, 02:27 AM

OEMs and board vendors want Windows drivers. Without WHQL certification the drivers won't install. You don't get WHQL certification without the DRM support, whether you are AMD, Intel, NVidia, or anyone else.

Hello bridgman: the following is not picking on you, but an "honest question", meaning that I don't know the answer but I assume there must be one. The question is: how is Intel able to have fully open sourced drivers and fully documented hardware and still get WHQL certification? Do their drivers include open source DRM?

Regards,

Zooko Wilcox-O'Hearn

agd5f

02-09-2008, 03:51 AM

Hello bridgman: the following is not picking on you, but an "honest question", meaning that I don't know the answer but I assume there must be one. The question is: how is Intel able to have fully open sourced drivers and fully documented hardware and still get WHQL certification? Do their drivers include open source DRM?

Intel has DRM too. Everyone has to if they want to be WHQL certified. They just don't implement SW support for the HW drm "features" in their open source driver and they don't provide any documentation for it. AMD is providing open drivers and documentation for our chips as well, however, like Intel, we are also not able to release any information on the HW drm implementation.

Alex

glisse

02-09-2008, 07:12 AM

The encryption is separate from the actual data stream in pretty much all aspects- otherwise you wouldn't have MPEG1/2/4 or h.264 software decoders on Linux in the first place. The reason I've been able to ascertain that they don't have them as separate components is that the media companies are so damned paranoid someone will dip into the decrypted stream that they have to prevent a separation of the two functionalities so that you "can't" do it. Unfortunately, they've not quite twigged onto the reality that at some point you HAVE to break it apart to show it to a human being, especially if you want to get PAID for producing it.

Heh... Most of what they're worried about is like locking excrement in a safe and then locking the safe inside a safe, really.

I'd be looking elsewhere for hardware boost of operations, really- you're not going to get ANY traction out of companies like AMD for some time yet. Probably until either the media companies wise up, or the computer industry as a whole wakes up from the delusion that they actually "need" the media industry to keep themselves going at the levels they're at. Sure, they are helping it along- but they're not needed by the other.

Well, i likely didn't explain properly here is what i mean, you got the idct register:
MMIO offset 0xDEADBEEF IDCT_SETUP
bit 0 enable IDCT
bit 1 enable MACROVISION
bit 2 ....

Now here what AMD could make public:
MMIO offset 0xDEADBEEF IDCT_SETUP
bit 0 enable IDCT
bit 1 unused have to been set to 1
bit 2 ....

You see if you expose bit 0 and all others bits in this register there will be people wondering what the hell this bit is for and they will try to see and find out quickly that by clearing it you can disable macrovision. I have debileratly taken an easy example but i hope you get the idea why they can't expose decoding possibilities and what they mean by tightly bind together with DRM well at least this is my understanding of their problem.

Of course people can RE things but you won't see me and likely not many others people starting doing RE on windows, i haven't installed one in more than 8 years and i would have to learn many things to know how to RE on that crap.

Redeeman

02-09-2008, 12:02 PM

OK, let me try again.

OEMs and board vendors want Windows drivers. Without WHQL certification the drivers won't install. You don't get WHQL certification without the DRM support, whether you are AMD, Intel, NVidia, or anyone else.

ATI has always been the most outspoken company in the industry about DRM. You are having this discussion with an AMD/ATI employee, not someone from another graphics vendor even though everyone implements the same DRM capabilities and everyone has the same challenges in the Linux market. Do you think we are the only ones who implement DRM ?

I honestly don't understand why you are picking on us rather than other graphics vendors. I hate to think it's because we are the only ones willing to actually talk about it.

well obviously i dont think its okay for other vendors either. I am picking on you(AMD/ATI) because you have made a graphics card design where even though you seem to be opening up most of the docs, you are leaving out key features, because of DRM. i can only hope that changes on newer hardware. I have nothing against you making DRM for all sorts of OEMS or even my neighbor, i just dont want some big OEMs drm shit to ruin my ability to use a feature of my graphics card, thats all.

Redeeman

02-09-2008, 12:06 PM

Okay, I'll bite. Let's break this down a bit.

DRM is a form of content protection - but for digital, it is no different than Macrovision, CGMSA and so on. Content protection is a technical mean to enforce copyright rights. Hopefully we can all agree on that. Let me repeat. It is a technical means to enforce copyright rights. I will continue to use Content Protection (CP) instead of DRM for clarity.

As a human, we don't like being told that we aren't trusted. We are fundametnally talking about a technical means to enforce copyright rights because the copyright owner doesn't trust us.

Now let's play a game of swap the players nouns and pronouns.

DRM allows the MPAA to ensure you don't copy movies.
Technical means of copyright protection allows the copyright owner to ensure you don't violate the copyright owners protected (copyright wise) works.
The GPL_ONLY flag allows the Kernel Developers to ensure you don't derive from their kernel code.

Now I know people will claim but it's different, both are interpretations from the copyright holders point of view, not the users. Interpretation is just that.

This view is not just mine, here is a good link from LKML.

Play the swap the nouns and pronouns a bit in a lot of the posts in this article, and a surprisingly large number would look quite bad from the kernel developers point of view.

I am not saying DRM is right, but I am saying that it is just as right as the GPL_ONLY flag in the kernel.

Regards!
quite wrong.

the EXPORT_SYMBOL_GPL is there to guide people, it doesent prevent anyone from doing stuff.. and it most certainly does not prevent people from removing it, or doing whatever. its made as a tool to help people know if what they are doing is a derived copy or not.

that is, it doesent stop people from using their FAIR USE rights.