Why I think the DRM and open source debate is nonsense

[maggot_brain]

I reckon that CPUs will get fast enough to handle HD content in a couple of years without GPU acceleration. I can remember back in the late 90s/early 00s when you had to have GPU acceleration or a hardware mpeg2 card to watch DVDs. My old k6-2 500 with 128 Mb Ram and 16 Mb 3dfx card couldn't handle watching DVDs. Most modern computers can.

My c2d 1.6 gig laptop can handle 720p hd content without GPU acceleration on VLC media player so I reckon in a couple of years the debate will be obsolete. What does anyone else think?

[Kano]

How about 1080p/i in h264?

[duby229]

How about 1080p/i in h264?

All I know is that I encode all my DVD movies into x264 with a 480p resolution, and it seems to work at about 6% CPU usage with mplayer, and about 10% with xinelib, both using gl2. GStreamer is totally broken with h264 video at this point, and I never tried VLC becouse the GTK interface is totally unusable right now.

Provided decent 3d support any 2ghz K8 or newer, or 30ghz P4 or newer, or 1.8ghz C2D or newer should be able to handle 1080p h264 streams. Of course this isnt considering decryption, but anybody in there proper mind would have decrypted there movies as soon as they bought them any way. BD and HDDVD will have a decryptor available soon enough. Thats why AMD trying to support DRM in linux is asinine at the best. It's totally irrelevant and worthless. It isnt needed. It's a waste of money and talent.

All it's going to do is piss a lot of people off.

[bridgman]

Not sure I understand the connection between DRM and decode here. We`re not trying to support DRM in Linux -- we`re just trying to make sure that supporting unprotected decode in Linux doesn`t put our Windows DRM (on the same hardware) at risk.

[duby229]

Not sure I understand the connection between DRM and decode here. We`re not trying to support DRM in Linux -- we`re just trying to make sure that supporting unprotected decode in Linux doesn`t put our Windows DRM (on the same hardware) at risk.

What your effectively saying is that hardware decoding will not be possible in the open driver because of DRM... There really isnt any other way to interpret it.

I think it is unfair and ridiculous considering that it is a moot point for the linux market anyway because most content will be unencrypted from the start and for that content that is encrypted it --will-- be cracked sooner rather then later. There is zero point in supporting DRM in hardware, when an open source software solution will be available shortly. It's going to be hacked whether you like it or not. It's inevitable, and supporting it in your drivers is a futile waste of engineering talent and money. You'd be better off spending your engineering talent --helping-- us crack DRM in an open and free way.

[bridgman]

What your effectively saying is that hardware decoding will not be possible in the open driver because of DRM... There really isnt any other way to interpret it.

Actually, there is. If you read my other posts on this, what I'm saying so far is "we're pretty sure we know how to expose IDCT/MC decoding hardware to open source without putting DRM at risk, but we don't have a way to do that for UVD yet".

There is zero point in supporting DRM in hardware. It's going to be hacked whether you like it or not. It's inevitable, and supporting it in your drivers is a futile waste of engineering talent and money.

Are you saying "we shouldn't support DRM on the Windows products either", or "we should make different chips for Linux than Windows, and leave the DRM out of the Linux chips" ? We can't sell chips into the largest sections of the Windows market without DRM. Rbmorse said it well a couple of posts earlier.

[rbmorse]

Sure there's a point to it. It keeps AMD from being sued into oblivion by the people from whom crackers are stealing content. I can see where AMD might think that was important.

I have to admit I was a bit surprised when I started reading that AMD was going to begin supporting the development of an open source driver. I am very pleased that they are doing so. But, as John keeps pointing out, AMD didn't create the problem (Intel may have...or at least helped but that is a separate discussion) and it's just as big a headache for them as it is for the teeny, tiny (but, growing) number of people who care about such things on the user side. As opposed to a couple of humdred million who just want to be able to watch movies on their PCs and don't view DRM as a violation of some unenumerated natural right, or more likely, simply don't care about the issue at all. That crowd buys A LOT of video cards.

It is clear that there are going to be limits, at least in the near term, on how far AMD can go with this both in terms of their business model and what the lawyers will allow.

I commend John (and others) for being so up front about that. No pie-in-the-sky promises, just simple declarative sentences saying they will do what they can and that's all they can do, but anything ***AMD*** does on the open source side will not be allowed be allowed to compromise the protected driver. I appreciate their honesty

And no, it doesn't matter if anybody thinks that's not fair.

[rbmorse]

...Rbmorse said it well a couple of posts earlier.

Actually, John, I pulled that post on my own because I thought it a bit harsh. But, I'll say it again, if AMD can't sell video cards that support DRM under Windows, they won't sell enough video cards to maintain the business at all. And that would be bad for all of us.

One does not have to like that state of affairs, but it is the unfortunate reality we have to face.

[duby229]

Actually, there is. If you read my other posts on this, what I'm saying so far is "we're pretty sure we know how to expose IDCT/MC decoding hardware to open source without putting DRM at risk, but we don't have a way to do that for UVD yet".



Are you saying "we shouldn't support DRM on the Windows products either", or "we should make different chips for Linux than Windows, and leave the DRM out of the Linux chips" ? We can't sell chips into the largest sections of the Windows market without DRM. Rbmorse said it well a couple of posts earlier.

I think this is the fundeental issue, and thank you for bringing it up. Yes I think that AMD would be better off by not supporting DRM in any way shape or form on any product using any operating system period. ATi is large enough, and diverse enough with enough customers that if the Content industry wanted to sell there content then they would have no choice but to release it without restrictions.

If anyone is in a strong enough position to eliminate drm it is ATi. If they spent as much money and an power educating the public about DRM as they do supporting it, they could easily kill it within the next year. I understand that you dont represent ATi as a whole, just the open source documentation, so please dont consider this a personal attack on you. It isnt. I just feel that ATi as a whole should be attacking DRM with all of it's might and man power becouse DRM is the source of these problems. And ATi as a video card company is right smack dab in the middle of it.

Lets face it, if DRM didnt exist we wouldnt be having this conversation. there wouldnt be any risk of law suites. There wouldnt be any problem with decoding content. The only problem that exists is DRM. So lets fix the problem.

[duby229]

Actually, John, I pulled that post on my own because I thought it a bit harsh. But, I'll say it again, if AMD can't sell video cards that support DRM under Windows, they won't sell enough video cards to maintain the business at all. And that would be bad for all of us.

One does not have to like that state of affairs, but it is the unfortunate reality we have to face.

And this is where we disagree. ATi is in more markets then just PC's. If anybody could kll DRM it is ATi, and they could do it in a year if the chose to do so.

By simply telling the public at large that they cant watch what they bought because of DRM would enrage them. And lets face it, if ATi never supported DRM in the first place the masses wouldnt be able to watch DRM content and it would have died already.

ATi has done nothing --but-- put themselves in this situation. They weakened there own position and strengthened the content industry. Fortunately they are still able to kill if they dropped support for DRM in all future driver releases for all existing hardware and all future hardware, and explained to the public that it is DRM's fault.

ATi could still kill DRM if they wanted to.

[bridgman]

And this is where we disagree. ATi is in more markets then just PC's. If anybody could kll DRM it is ATi, and they could do it in a year if the chose to do so.

Not sure I agree with you there. We are active in four main markets -- PC graphics, consumer electronics (DTV), handheld devices (phones, PDAs) and game consoles. Of the four, PC graphics probably has the lightest DRM requirements although there is a segment of the handheld business which is trying to "open up". To a large extent, the same content providers feed all four segments.

By simply telling the public at large that they cant watch what they bought because of DRM would enrage them. And lets face it, if ATi never supported DRM in the first place the masses wouldnt be able to watch DRM content and it would have died already.

DRM is not an ATI/AMD issue, except to the extent that we are part of the PC industry and (like everyone else) have to choose between implementing industry standards or giving up those markets to our competitors. If ATI had never supported DRM then OEMs would have purchased exclusively from other graphics vendors who did support it. ATI, not DRM, would have died and gone away.

Adopting DRM was something the PC mfgs *wanted* because it allowed them to legally play DVDs (and now HD/BD) on their products and increase their market as a result. If all the graphics vendors in the world had agreed to boycott DRM no matter what the cost that might have kept DVD playback and DRM off PCs, but even then the outcome would just have been more portable DVD players (which have had DRM from day one) and fewer PCs with DVD drives.

Content providers would not be affected, but PC users and PC mfgs would lose.

[duby229]

Not sure I agree with you there. We are active in four main markets -- PC graphics, consumer electronics (DTV), handheld devices (phones, PDAs) and game consoles. Of the four, PC graphics probably has the lightest DRM requirements although there is a segment of the handheld business which is trying to "open up". To a large extent, the same content providers feed all four segments.



DRM is not an ATI/AMD issue, except to the extent that we are part of the PC industry and (like everyone else) have to choose between implementing industry standards or giving up those markets to our competitors. If ATI had never supported DRM then OEMs would have purchased exclusively from other graphics vendors who did support it. ATI, not DRM, would have died and gone away. Adopting DRM was something the PC mfgs *wanted* because it allowed them to legally play DVDs (and now HD/BD) on their products and increase their market as a result.

If all the graphics vendors in the world had agreed to boycott DRM no matter what the cost that might have kept DVD playback and DRM off PCs, but even then the outcome would just have been more portable DVD players (which have had DRM from day one) and fewer PCs with DVD drives. Content providers would not be affected.

And that is how ATi has weakened there position. Becouse they actually believe that crap.

Monopolies are iilegal in most countries. ATi isnt going anywhere. Additionally they already have so much hardware saturated in the market that if the content industry wanted to sell content they would have no chioce but to fill ATi's wishes. I install cable for a living in my home town, and a see Tv's with ATi codecs all the time. PVR's with ATi tuners and chipsets. I see PC's and laptopswith ATi video cards, and XBOX 360's and Nintendo's with ATi graphics processors. The list goes on and on and on. If ATi boycotted DRM across the board on all of it's products they could kill DR in a year.

Of course it is clear that ATi is afraid, and weak. And it is entirely there own fault.

[maggot_brain]

I think I need to clarify my original post a bit. What I'm basically saying is

1. That in a couple of years I reckon CPUs will be quick enough to play HD content without GPU acceleration. So the DRM/UVD issue won't be as much of an issue.

2. DRM is evil - no argument there.

3. DRM will probably be reverse-engineered and implemented in free software like for example with CSS and DeCSS anyway.

4. DRM decryption can't be implemented in a FOSS driver for obvious reasons anyway as it could be used as a circumvention mechanism

so basically AMD should not involve DRM in the RadeonHD driver in any way shape or form. DRM for HD media will be reverse-engineered and we can use Free OSes to watch this content when the opportunity arise.

Notice how I used the term 'reverse engineered' and not cracked wrt DRM decryption. I don't believe asserting our own right to watch content whichever way we wish on our OS of choice is an illegal or immoral act.

[rbmorse]

Duby...is there something here beyond wishful thinking or am I missing something? I didn't get from AMD last financial statement that they were in a position to throw away sales into the Windows markets.

[bridgman]

so basically AMD should not involve DRM in the RadeonHD driver in any way shape or form. DRM for HD media will be reverse-engineered and we can use Free OSes to watch this content when the opportunity arise.

Nobody is talking about putting DRM in the RadeonHD driver. The issue is that we *do* put DRM in the hardware for use by the Windows drivers, and as a result of that there may be certain HW functionality we can't expose for use in RadeonHD.

Of course it is clear that ATi is afraid, and weak. And it is entirely there own fault.

... and not the other graphics vendors ? We all sell into the same market, and we all implement DRM, and we all face the same issues re: opening video-related HW to the open source market. It's probably worth a gentle reminder that this whole discussion is about whether AMD will be the *first* to expose HD decode HW, not the *last*.

[duby229]

Duby...is there something here beyond wishful thinking or am I missing something? I didn't get from AMD last financial statement that they were in a position to throw away sales into the Windows markets.

You think theyd be throwing away sales? How so?

If anything once they announced to the general public that they have eliminated a threat to them, they'd become hero's, and most folks would use there products exclusively. I personally beleive that it is ATi's duty.

That said I fully realize and appreciate that it will never happen. It's sad and shameful, but poor unfortunate folks actually believe that there is no other way. As such, all I'm askng for is to keep DRM out of Linux. It's in the hardware, and there is nothing that can be done about it, but keep it out of the drivers, and disable the infected hardware. If they want to use it in windows then so be it, but it isnt welcome in linux.

Dont use DRM as an excuse for crippling the open source drivers. if the hardware is capable of decoding h264 then the open source drivers should be able to take advantage of that capability, and using DRM as an excuse is not a good facet to get going on. As far as DRM'd content goes, it'll be hacked sooner or later and an OSS solution will be available. It's in this way that Linux --will-- be able to view and use --ALL-- the same content as Windows while using free and open source software to do it. It's going to happen whether ATi likes it or not, and they should be encouraging it and even helping it along.

[duby229]

One more time. Nobody is talking about putting DRM in the RadeonHD driver. The issue is that we *do* put DRM in the hardware for use by the Windows drivers, and as a result of that there may be certain HW functionality we can't expose for use in RadeonHD.



... and not NVidia's, or Intel's ? We all sell into the same market, and we all implement DRM, and we all face the same issues re: opening DRM-related HW to the open source market.

It's probably worth mentioning that this whole discussion is about whether AMD will be the *first* to expose HD decode HW, not the *last*.

Of course, but dont use that as an excuse. please.

What would be truly impressive is if you could say that you did it without stooping to there level by not implementing DRM. Help the open source community instead. DRM will be cracked, and all the same functionality will be exposed to us all while using free and open software to do it.

That would be truly impressive.

You come into this assuming that it cant be done with free software and --that-- is the flaw in your logic. Whether you like it or not it --will-- be done with free software.

[bridgman]

I have to admit I don't get the connection between this discussion and "doing it with free software".

The question is not what is done with free software, the question is what *we* do to protect (or not) technology which we have committed to keep safeguarded. Even if someone successfully reverse engineers a playback solution (and that has already happened for most of the major protection mechanisms), that has no impact on our obligations or liabilities.

[duby229]

What exactly are you proposing ? Are you saying that we should expose all the hardware specs and not worry about protecting DRM, even if that means massive lawsuits and significant loss of business outside the open source market ?

How do you figure it would lose a bunch of business? For those folks that dont know about DRM, they'll continue using the closed driver, and for those that do, they'll start using the open driver....As such any business that you lose will be due to your own lack of educating the your customers. If you started spending your resources now to educate your customers, then they would know better. I deal with people all day long, and I know first hand that average people are not as stupid as folks make them out to be. People are not sheep.

Be honest with them, and tell them what DRM is, and then give them a chioce between a closed source DRM infected driver, and an --equally-- functional open source driver, and I'll guaranty that ost folks will continue using your hardware with the open source driver. And if the content industry sues you then you've got an ass ton of anti competitive case law on your side and you'll win in a month.

[rbmorse]

I don't think Duby understands that the vast majority of AMD video chipset sales are to OEMs who don't give a rat's patoot about DRM one way or the other. They're just trying to shove cards down consumers throats any way they can and right now the easiest way to do that is by selling into the Windows market.

Does AMD even sell any ATI-branded consumer video cards anymore?

[bridgman]

How do you figure it would lose a bunch of business?.

Simple. If we expose info which allows our DRM to be compromised on Windows, we instantly lose most of our Windows business since one of the pre-requisites for that *is* a robust DRM implementation.

If we had an sure-fire way to open up HD decode without exposing DRM-related info we wouldn't be having this discussion. Remember that the two are intertwined in the standards and handled in the same block. One of the requirements is that you can't allow decoded images to be accessible *inside* the PC either...

[duby229]

I don't think Duby understands that the vast majority of AMD video chipset sales are to OEMs who don't give a rat's patoot about DRM one way or the other. They're just trying to shove cards down consumers throats any way they can and right now the easiest way to do that is by selling into the Windows market.

Does AMD even sell any ATI-branded consumer video cards anymore?

Yes AMD does. All AMD's video chipsets sold into the PC market are still under ATi's brand. And I understand perfetly well, but OEM's are not ultimately the consumer. If anybody is at risk here it is the OEM, and in the end they --must-- do what the consumer wants. It is ATi's duty to educate the consumer.

I understand perfectly well, and the truth is that ATi is prolly the only company in the world right now that has the power to kill off DRM completely and totally. And they arent doing it. It's a damn dirty shame.

But in the end, All I'm asking for is to keep it out of Linux in either the closed driver or the open driver. It doesnt belong here, it isnt welcome here.

If you wantr to continue selling DRM into the Windows arket then please do so, but keep it out of Linux it isnt welcome.

[bridgman]

I understand perfectly well, and the truth is that ATi is prolly the only company in the world right now that has the power to kill off DRM completely and totally. And they arent doing it. It's a damn dirty shame.

I have to ask. Why do you think ATI is the only company that can do it ? Why not Intel or NVidia, for example ?

If you wantr to continue selling DRM into the Windows arket then please do so, but keep it out of Linux it isnt welcome.

We have to include DRM in the decoder hardware for Windows, and until the Linux desktop market is big enough to justify Linux-specific chips that means the same hardware will be used by Linux customers. Along with the hardware comes the need to protect the DRM stuff and hence the decoder hardware... and that, in a nutshell, is the whole issue.

[duby229]

Simple. If we expose info which allows our DRM to be compromised on Windows, we instantly lose most of our Windows business since one of the pre-requisites for that *is* a robust DRM implementation.

If we had an sure-fire way to open up HD decode without exposing DRM-related info we wouldn't be having this discussion. Remember that the two are intertwined in the standards and handled in the same block. One of the requirements is that you can't allow decoded images to be accessible *inside* the PC either...

Dont expose that information then. It's that simple. But you can still allow us to use the hardwares decoding capabilities. It's not too much to ask for.

The fact is that I dont want to have anythng to do with DRM, if anything then you should give us the ability to completely disable and totally hide that hardware from the drivers so that there is zero chance that we can stumble upon it. That would be perfect, then we could have a video card that has the DRM hardware perfectly disabled, and there would be zero chance that whatecver your concerned with would happen.

Disable the hardware. Problem solved.

[duby229]

I have to ask. Why do you think ATI is the only company that can do it ? Why not Intel or NVidia, for example ?



This is the core issue. We have to include DRM in the decoder hardware for Windows, and until the Linux desktop market is big enough to justify Linux-specific chips that means the same hardware will be used by Linux customers, and along with the hardwrae comes the need to protect the DRM stuff and hence the decoder hardware.

That, in a nutshell, is the whole issue.

Becouse of the number of related markets, ATi is involved in. Almost all of them are DRM infected, and ATi has huge presence in all of them by disabling DRM across the board right now and demanding that the content industry drop support for all DRM mechanisms immediately, while also educating the public masses about what DRM is exactly, would effectively kill DRM within the year. The content industry would have no chioce but to comply.

I'm not asking for separate hardware, just that the Linux driver work just as well as the windows driver on the same hardware, with the DRM hardware disabled. By embracing the Free software community, that will be possible in the very near future becouse it will be cracked sooner or later, whether you like it or not.... HDCP is doomed to fail as is Macrovision, and every other restriction mechanism in place today. They will all be cracked.. When that happens your DRM implementation wont matter anymore, and you'll have wasted how many untold ours of man time. You should be helping the free software community develop these circumvention mechanisms as fast as you possibly can, becouse in the end it is for your own good.

[bridgman]

I agree it would be perfect if decode and DRM were different hardware but they're not, and they have to stay closely coupled in order to meet Windows DRM requirements. I don't think the market would accept the extra cost of implementing two decoders on each chip, one with DRM and one without, but that is the obvious answer.

There are other alternatives as well, like running accelerated decode on the shaders rather than on dedicated HW. That would allow you to stay completely DRM-free while offloading a lot of the processing to the GPU.

[duby229]

I agree it would be perfect if decode and DRM were different hardware but they're not, and they have to stay closely coupled in order to meet Windows DRM requirements. I don't think the market would accept the extra cost of implementing two decoders on each chip, one with DRM and one without, but that is the obvious answer.

There are other alternatives as well, like running accelerated decode on the shaders rather than on dedicated HW. That would allow you to stay completely DRM-free while offloading a lot of the processing to the GPU.

That would be perfectly acceptable. I could be perfectly happy with that. and after DRM is hacked I'll still be able to view all the same content as windows anyway. Yeah I could definitely be happy with that.

I know that the nvidia drivers use something called xv to decode video on the hardware... How would this relate to ATi hardware decoding video using the 3d shaders? And will the closed source drivers support xv?

[givemesugarr]

I think this is the fundeental issue, and thank you for bringing it up. Yes I think that AMD would be better off by not supporting DRM in any way shape or form on any product using any operating system period. ATi is large enough, and diverse enough with enough customers that if the Content industry wanted to sell there content then they would have no choice but to release it without restrictions.

If anyone is in a strong enough position to eliminate drm it is ATi. If they spent as much money and an power educating the public about DRM as they do supporting it, they could easily kill it within the next year. I understand that you dont represent ATi as a whole, just the open source documentation, so please dont consider this a personal attack on you. It isnt. I just feel that ATi as a whole should be attacking DRM with all of it's might and man power becouse DRM is the source of these problems. And ATi as a video card company is right smack dab in the middle of it.

Lets face it, if DRM didnt exist we wouldnt be having this conversation. there wouldnt be any risk of law suites. There wouldnt be any problem with decoding content. The only problem that exists is DRM. So lets fix the problem.


as i've said in the other post of the closed/mixed ati driver, if ati wouldn't support this protection stuff then all the oems would turn to another producer that support it and this means nvidia, which already has a long term support on linux and solaris and is in good shape also on windows, even if amd/ati is still leading windows hw. also if ati woulnd't provide certified windows pieces of silicon then windows might completely disable these boards in its systems, with vista it should be possible and quick to be done, and this would mean that amd/ati will be crushed by nvidia since almost 90% of pcs get out with vista preinstalled. also intel will not move a muscle on this since we all know of its behaviour towards amd, but this is another matter and we're not here to discuss about this. so, this means that if ati would not support drm and bd/right protection management then ati would go bankrupt and we all would need to migrate to nvidia, since nowadays ati boards don't perform at more than 80% of their capabilities (and 80% means for older chipsets with tested codebase). now, amd/ati says: we will not put at legal risk our stuff with other companies just because linux users (which still are less than 20% of total users around the world) with no revenue. since actual boards cannot have hw hd decoding capabilities for free movies without putting at risk the protection module at its base (the 2 features are inserted in the same box on the board) then the only way of releasing hw hd decoding is enabling it into fglrx, but for now fglrx needs to be performance tuned and bugfixed. after that they'd introduce uvd. maybe the introduction of this feature would be sped up because of the increasing number of users requiring it, but for having it at the same performance and completness as aiglx when it was released i'd better wait longer. now, i think that it's time to stop blaming amd/ati for supporting this privacy invasion of drm since nobody obliges you to use this stuff, even if someone still wants you to not be able to use at 100% your legally purchased hw.

[givemesugarr]

And that is how ATi has weakened there position. Becouse they actually believe that crap.

Monopolies are iilegal in most countries. ATi isnt going anywhere. Additionally they already have so much hardware saturated in the market that if the content industry wanted to sell content they would have no chioce but to fill ATi's wishes. I install cable for a living in my home town, and a see Tv's with ATi codecs all the time. PVR's with ATi tuners and chipsets. I see PC's and laptopswith ATi video cards, and XBOX 360's and Nintendo's with ATi graphics processors. The list goes on and on and on. If ATi boycotted DRM across the board on all of it's products they could kill DR in a year.

Of course it is clear that ATi is afraid, and weak. And it is entirely there own fault.

do you think that xbox would have chosen ati if it wouldn't support their drm requests?! i really don't think so.

[givemesugarr]

You think theyd be throwing away sales? How so?

If anything once they announced to the general public that they have eliminated a threat to them, they'd become hero's, and most folks would use there products exclusively. I personally beleive that it is ATi's duty.

That said I fully realize and appreciate that it will never happen. It's sad and shameful, but poor unfortunate folks actually believe that there is no other way. As such, all I'm askng for is to keep DRM out of Linux. It's in the hardware, and there is nothing that can be done about it, but keep it out of the drivers, and disable the infected hardware. If they want to use it in windows then so be it, but it isnt welcome in linux.

Dont use DRM as an excuse for crippling the open source drivers. if the hardware is capable of decoding h264 then the open source drivers should be able to take advantage of that capability, and using DRM as an excuse is not a good facet to get going on. As far as DRM'd content goes, it'll be hacked sooner or later and an OSS solution will be available. It's in this way that Linux --will-- be able to view and use --ALL-- the same content as Windows while using free and open source software to do it. It's going to happen whether ATi likes it or not, and they should be encouraging it and even helping it along.

it seems that you still haven't understood that exposing free h264 hw decoding would put at a too high risk the drm protection since they're integrated in the same component on the board. this would allow with very little rev-eng to put at use also the protected hw decoding. this is obviously unaceptable and would mean a very looooong way of problems to amd/ati. the real problem is with bd/hd direct hw decoding which is IMPOSSIBLE on linux until linus torwalds accepts drm code into kernel, and i don't see this happening, at least for this solar year. now, i hope that things are a little clearer.

[duby229]

as i've said in the other post of the closed/mixed ati driver, if ati wouldn't support this protection stuff then all the oems would turn to another producer that support it and this means nvidia, which already has a long term support on linux and solaris and is in good shape also on windows, even if amd/ati is still leading windows hw. also if ati woulnd't provide certified windows pieces of silicon then windows might completely disable these boards in its systems, with vista it should be possible and quick to be done, and this would mean that amd/ati will be crushed by nvidia since almost 90% of pcs get out with vista preinstalled. also intel will not move a muscle on this since we all know of its behaviour towards amd, but this is another matter and we're not here to discuss about this. so, this means that if ati would not support drm and bd/right protection management then ati would go bankrupt and we all would need to migrate to nvidia, since nowadays ati boards don't perform at more than 80% of their capabilities (and 80% means for older chipsets with tested codebase). now, amd/ati says: we will not put at legal risk our stuff with other companies just because linux users (which still are less than 20% of total users around the world) with no revenue. since actual boards cannot have hw hd decoding capabilities for free movies without putting at risk the protection module at its base (the 2 features are inserted in the same box on the board) then the only way of releasing hw hd decoding is enabling it into fglrx, but for now fglrx needs to be performance tuned and bugfixed. after that they'd introduce uvd. maybe the introduction of this feature would be sped up because of the increasing number of users requiring it, but for having it at the same performance and completness as aiglx when it was released i'd better wait longer. now, i think that it's time to stop blaming amd/ati for supporting this privacy invasion of drm since nobody obliges you to use this stuff. the problem is that there should be some invoice to the major producers of drm content to compensate the linux users that are forced to have bad drivers and less support just because this stuff is neededly installed. this is a problem as it is the fact that it's 1% possible to find a pc that hasn't a windows version preinstalled. this is the real monopoly that should be taken into court and that should have all the pc users around the world be compensated even the ones that continue to use windows because they've never had the possibility to know about other choices.

I disagree, as I've explained above. Your logic is flawed becouse your not taking into consideration the shear amount of hardware that ATi already has saturated in the market. Your also not considering ATi's diversity in other markets. If ATi pulled the plug on DRM across the board on all of it's current hardware in all of it's business for all of platforms... Everything... That would take a massive blow to the content industry, and ATi could demand that they drop DRM completely. This in combinaion with consumer education and the inevitable backlash that would couse, ATi would get everything they wanted, and if they wanted DRM out they would get it.

ATi is definately big enough to get what they want, they just clearly dont recognize it, and are putting themselves in this position. Effectively believing that they cant do anything about it. It's bullshit, but hey what can you do right? I mean all I'm asking for is a DRM free linux. Thas it. ATi can get rid if DRM completely if they wanted to, and are probably the only ones who could actually do it. But they wont becouse they are afraid and weak.

As long as I can have a DRM free linux I'll be perfectly happy. I'll remain outspoken about DRM throughout my life, but I'll be happy as long as I dont have to deal with it personally. The first time I try to play back some content that I bought and it tells me that I cant becouse DRM dictating what OS I can use and what player I can use, and what hardware I can use, I'm going to freak.

[duby229]

it seems that you still haven't understood that exposing free h264 hw decoding would put at a too high risk the drm protection since they're integrated in the same component on the board. this would allow with very little rev-eng to put at use also the protected hw decoding. this is obviously unaceptable and would mean a very looooong way of problems to amd/ati. the real problem is with bd/hd direct hw decoding which is IMPOSSIBLE on linux until linus torwalds accepts drm code into kernel, and i don't see this happening, at least for this solar year. now, i hope that things are a little clearer.

I understand perfectly well, but it'll never come to that. The DRM mechanisms that are currently being employed by BD and HDDVD will be hacked. It's inevitable, it's going to happen sooner rather then later. It's unavoidable, and anybody who thinks otherwise is fooling themselves. I still firmly believe that ATi should man up, and deal with it. Fight back and do it right, but if they wont then a decoder implemented using the 3d shaders might well be good enough in conjunction with the appropriate DRM hacks that are coming along.

[givemesugarr]

Becouse of the number of related markets, ATi is involved in. Almost all of them are DRM infected, and ATi has huge presence in all of them by disabling DRM across the board right now and demanding that the content industry drop support for all DRM mechanisms immediately, while also educating the public masses about what DRM is exactly, would effectively kill DRM within the year. The content industry would have no chioce but to comply.

I'm not asking for separate hardware, just that the Linux driver work just as well as the windows driver on the same hardware, with the DRM hardware disabled. By embracing the Free software community, that will be possible in the very near future becouse it will be cracked sooner or later, whether you like it or not.... HDCP is doomed to fail as is Macrovision, and every other restriction mechanism in place today. They will all be cracked.. When that happens your DRM implementation wont matter anymore, and you'll have wasted how many untold ours of man time. You should be helping the free software community develop these circumvention mechanisms as fast as you possibly can, becouse in the end it is for your own good.

cracked or rev-eng is not the same as spec release. the first 2 should be prohibited and is done by users, while the last thing is done by the producer and would break contracts rules and agreements. what do you think big ones do if ati would break their agreements?!
1. immediately break the engagement
2. would issue ati into court.
3. no other contractor would still want to have agreements with someone who has broke agreements before.

this wold mean ati to bankrupt and will mean that we'll have to switch to another brand.

[givemesugarr]

I understand perfectly well, but it'll never come to that. The DRM mechanisms that are currently being employed by BD and HDDVD will be hacked. It's inevitable, it's going to happen sooner rather then later. It's unavoidable, and anybody who thinks otherwise is fooling themselves. I still firmly believe that ATi should man up, and deal with it. Fight back and do it right, but if they wont then a decoder implemented using the 3d shaders might well be good enough in conjunction with the appropriate DRM hacks that are coming along.

no hacked stuff would go into the kernel and they'd be prohibited by law, as it is libdvdcss in usa and france, period.

[givemesugarr]

I disagree, as I've explained above. Your logic is flawed becouse your not taking into consideration the shear amount of hardware that ATi already has saturated in the market. Your also not considering ATi's diversity in other markets. If ATi pulled the plug on DRM across the board on all of it's current hardware in all of it's business for all of platforms... Everything... That would take a massive blow to the content industry, and ATi could demand that they drop DRM completely. This in combinaion with consumer education and the inevitable backlash that would couse, ATi would get everything they wanted, and if they wanted DRM out they would get it.

you seem to have missed that all this stuff already has drm. or should amd recall all these boards and remove drm from it?!



ATi is definately big enough to get what they want, they just clearly dont recognize it, and are putting themselves in this position. Effectively believing that they cant do anything about it. It's bullshit, but hey what can you do right? I mean all I'm asking for is a DRM free linux. Thas it. ATi can get rid if DRM completely if they wanted to, and are probably the only ones who could actually do it. But they wont becouse they are afraid and weak.

As long as I can have a DRM free linux I'll be perfectly happy. I'll remain outspoken about DRM throughout my life, but I'll be happy as long as I dont have to deal with it personally. The first time I try to play back some content that I bought and it tells me that I cant becouse DRM dictating what OS I use and what player I use, and what hardware I use, I'm going to freak.

ati is big because it has the customers to be so (oem's). if these customers were to fall then ati would die. period. also nobody would produce drm free stuff just to please some users from which they don't get much money.
you have now drm free linux, but you can only use 70% (and this percentage would go down with the years) of the hw capabilities.

[givemesugarr]

I have to ask. Why do you think ATI is the only company that can do it ? Why not Intel or NVidia, for example ?


for what i know intel uses drm in their hw but doesn't need to enable it. nvidia uses it and nobody complained about using their binary blob that uses drm. so if i were in ati i wouldn't take too much into consideration extremists as stallman. i do agree with some of stallman's statements about free software, but on other stuff i agree with linus. this leads me to the following statement:
"companies should be free to use protection stuff for their contents, but they do not ever interfere with whoever doesn't want to have their services provided." this leads to problems with hw producers that would need to satisfy both the parts. in this moment users tend to argue with amd/ati since it has now decided to communicate more with the community and for this reason the users externalize their convictions and frustration to amd. this thread has some good points on which users, hw industry and content industry could think on and if they really think good of users as they are continue to argue then they should sit around a table and decide for a better future in which both the needs (protection of contents) and freedom of users could coexist. amd has now moved more towards the community and i really hope that other manufacturers would do the same thing in the near future. nvidia also seem to be starting to walk the same path of amd and intel is still far away on it. maybe we will be lucky if we could have this wonderful world in let's say 2 or 3 years.

[bridgman]

I know that the nvidia drivers use something called xv to decode video on the hardware...

Xv is no problem. That's actually the "render" part, not decode, and that will be fully supported up to and including HD. There are no IP issues there, just a bunch of work.

The next step up from that is "XvMC", which is accelerated decode for MPEG2 -- again, it looks like we will be able to fully support that as well.

Once you get into HD decode, you go past what XvMC API can handle and you're getting into new APIs like VAAPI or extensions of XvMC. AFAIK nobody supports accelerated HD decode (by which I mean VC1 or AVC/H.264) on closed Linux drivers today, let alone open drivers. That might change over time and we're all working hard to make it possible.

[givemesugarr]

That would be perfectly acceptable. I could be perfectly happy with that. and after DRM is hacked I'll still be able to view all the same content as windows anyway. Yeah I could definitely be happy with that.

I know that the nvidia drivers use something called xv to decode video on the hardware... How would this relate to ATi hardware decoding video using the 3d shaders? And will the closed source drivers support xv?

i don't like at all the solution proposed of passing the decoding to shaders since it would just pass the ball from the processor to the gpu. it would be interesting to pass everything related to video to the gpu, but if there's hw that does decoding, then it's stupid to overload the gpu because of some drm stuff. it's an idiotic solution that won't do any good. think of it on a igp: this would kill the system.
amd also can use Xv to decode. Xv stands for X Video and it's an xorg solution for 3d acceleration. there is an advanced solution which is called x video motion compensation, that for i know is only available with intel boards (i currently don't know of nvidia boards but i'm not so informed on nvidia side). fglrx is still slow with Xv on some boards, and it doesn't work on others. on radeon driver xv is quite good but opengl doesn't work. since amd is concentrating to improve opengl (that works about the same in linux and windows) and which will progress into gallium 3d, it's obvious that xv is not well supported.

[duby229]

you seem to have missed that all this stuff already has drm. or should amd recall all these boards and remove drm from it?!




ati is big because it has the customers to be so (oem's). if these customers were to fall then ati would die. period. also nobody would produce drm free stuff just to please some users from which they don't get much money.
you have now drm free linux, but you can only use 70% (and this percentage would go down with the years) of the hw capabilities.

No just disable it in mass. I one fell swoop DRM gone.

If DRM stopped working for just 30% of all content the consumers would explode, and provided that they were educated to know that it was entirely DRM's fault, they would demand that DRM be eliminated. ATi would be in a position to demand what they wanted from the content industry. It's funny actually. The content industry has sowed the seeds of it's own destruction in DRM. If ATI did what it needs to do they could grow that seed to fruition.

[givemesugarr]

No just disable it in mass. I one fell swoop DRM gone.

If DRM stopped working for just 30% of all content the consumers would explode, and provided that they were educated to know that it was entirely DRM's fault, they would demand that DRM be eliminated. ATi would be in a position to demand what they wanted from the content industry. It's funny actually. The content industry has sowed the seeds of it's own destruction in DRM. If ATI did what it needs to do they could grow that seed to fruition.

this would happen in an utopian world. it's true that we live in the best of all possible worlds (i know that this seems strange but it has been stated by Gottfried Leibniz in his 1710 work) but this world is still not as we would all like. your statement is interesting but will never happen what you're saying. and on this is just a matter of being realistic. the companies have planted the seed of destruction in the ultra high prices. i'm sure that without drm and protection stuff they'd be able to propose the same content of today at less than 30% of actual price to final user and so the piracy wouln't have a real reason to exist with so low prices. this was demonstrated by a famous economist when he was speaking about tax revenue and tax evading. the laffer curve http://en.wikipedia.org/wiki/Laffer_curve was used to illustrate the concept of Taxable income elasticity, the idea that government can maximize tax revenue by setting tax rates at an optimum point and that neither a 0% tax rate nor a 100% tax rate will generate government revenue. this could be applied in the same to the content. i think that the content could be offered at lower price and with better income, and that would also bring down piracy. it would be really stupid to risk some months of prison for one movie when it could be easily bought at some 10 $. this is what i look for: discounted good stuff which often come without drm protection because producers doesn't feel that the content should be protected. (old movies and older music that are better than actual ones).

[SavageX]

Personally I guess the very reason to have a special (and costly) hardware unit for video decoding is DRM. My naive understanding leads me to believe that most video decoding steps can be done in the 3D shaders anyway and that only the need to keep the encryption chain intact "justifies" dedicated hardware.

Perhaps it's viable to in worst case not touch the UVD unit at all and do most stuff with a set of shaders anyway? This would also be rather flexible (yum yum, accelerated Theora and/or Dirac...) ;-)

Downside may be that lower-end parts may not have the required shader-power and that energy-efficiency may not be as great.

[givemesugarr]

Personally I guess the very reason to have a special (and costly) hardware unit for video decoding is DRM. My naive understanding leads me to believe that most video decoding steps can be done in the 3D shaders anyway and that only the need to keep the encryption chain intact "justifies" dedicated hardware.


this is not true. hw decoding may be done without drm and encryption support. the ati choice was to do both the decoding and protection in the same block since it should be less painful engineering it.


Perhaps it's viable to in worst case not touch the UVD unit at all and do most stuff with a set of shaders anyway? This would also be rather flexible (yum yum, accelerated Theora and/or Dirac...) ;-)

Downside may be that lower-end parts may not have the required shader-power and that energy-efficiency may not be as great.

doing the stuff in the shaders is the same as not having hw decode and for this reason adding that block would be meaningless. the purpose of hw decoding can be illustrated with the analog/digital andn digital/analog conversion.

when you transform the analog into digital you do some stuff on the signal and generate a train of impulses that you'll add to a carrier frequency. at the receiver side you'll have to recover the train of impulses and then apply a digital to analog conversion. if this conversion is done by software means it would take, let's say, 160 miliseconds. if this d/a conversion is done by a hw block this conversion could be done in the time of the signal passing through the block, let's suppose less than 100ms (remember that this time is very huge for this type of cenversion). then we have to think of another aspect: in the first type of conversion (sw one) we will need a powerful processor to do the conversion. the less powerful the processor the longer the time to convert the signal. in the second case instead we will not need a processor to elaborate the signal, but only a sync clock (that is present also in the first case).
the same procedure applies to hw decoding blocks. if you use them you'll have the following gains:
1. no central cpu stress
2. no gpu stress
3. no extra ram stress
4. only dma stress

without this you'll have this condition:
1. cpu or gpu stress (having a combined cpu/gpu work on decoding is still not done for what i know since the 2 types of processors are different and the process of using both would totally kill the system bus)
2. extra ram needed for computational purpose both on videocard and on system one
3. dma controller stress.

as you see there are many thing that would make hw video decoding to be inserted into the videocards.

[SavageX]

this is not true. hw decoding may be done without drm and encryption support. the ati choice was to do both the decoding and protection in the same block since it should be less painful engineering it.

Of course can HW decoding be done without DRM. What I'm saying is that if there weren't those hard "security" requirements the GPU developers might consider doing it all in the (now general purpose) shader core.



doing the stuff in the shaders is the same as not having hw decode and for this reason adding that block would be meaningless. the purpose of hw decoding can be illustrated with the analog/digital andn digital/analog conversion.
<snip>


The video decoding hardware is not a collection of passive elements. Your example doesn't apply IMO.

Dedicated hardware can of course be more (energy) efficient than a programmable shader engine, though.


2. extra ram needed for computational purpose both on videocard and on system one


I'd say there's plenty of it available. The gfx card needs to hold the input data, the shader programs and a buffer for the results. Nothing too worrying.


3. dma controller stress.


How that? Even with dedicated decoding hardware you need to get the input data in and the output data out.


as you see there are many thing that would make hw video decoding to be inserted into the videocards.

Sure, having dedicated HW is always nice. All I'm saying is that doing it with the 3D shaders may be an acceptable fallback which would still be way more efficient than doing it all on the CPU.

[givemesugarr]

Of course can HW decoding be done without DRM. What I'm saying is that if there weren't those hard "security" requirements the GPU developers might consider doing it all in the (now general purpose) shader core.

that won't be anymore hw decoding.


The video decoding hardware is not a collection of passive elements. Your example doesn't apply IMO.


neither digital/analog is even if the process may seem to.


I'd say there's plenty of it available. The gfx card needs to hold the input data, the shader programs and a buffer for the results. Nothing too worrying.

this is the problem with young people. they haven't seen what it means to not have enough ram to do what you want. and i assure you that physical ram isn't never enough. that's why you continue to use swap (very slow when compared to physical ram), because there's simply not enough ram. if you start to run some apps you'll see how faster the system ram would go up and fill.



How that? Even with dedicated decoding hardware you need to get the input data in and the output data out.

that's the point. the dma is always stressed but with hw decoding you won't stress other components as gpu/cpu system ram for more than the minimum required.


Sure, having dedicated HW is always nice. All I'm saying is that doing it with the 3D shaders may be an acceptable fallback which would still be way more efficient than doing it all on the CPU.

you're only moving the decoding from the cpu to the gpu. to do this you need to simulate a hw decoding unit on the shader engine. now this would mean another layer between the hw and the software parts. i do not agree with this solution since, in my opinion is just time losing one. devs would loose time to implement this solution that would not perform as the hw one, instead of focusing on developing code that would make the hw decode block function well. this method could be used for simulated hw decoding of new formats for older boards. otherwise i don't see any gain in using it.

[SavageX]

that won't be anymore hw decoding.


Aye.



this is the problem with young people. they haven't seen what it means to not have enough ram to do what you want. and i assure you that physical ram isn't never enough. that's why you continue to use swap (very slow when compared to physical ram), because there's simply not enough ram. if you start to run some apps you'll see how faster the system ram would go up and fill.


Whenever HD video decoding fails on PCs it's basically never because of memory constraints. Decoding video won't drive your system into swapping (as long as no mem leaks happen).

Oh, and thanks for calling me young.



you're only moving the decoding from the cpu to the gpu.


Aye. Personally I think that's what GPUs are made for ;)


to do this you need to simulate a hw decoding unit on the shader engine. now this would mean another layer between the hw and the software parts. i do not agree with this solution since, in my opinion is just time losing one. devs would loose time to implement this solution that would not perform as the hw one, instead of focusing on developing code that would make the hw decode block function well. this method could be used for simulated hw decoding of new formats for older boards. otherwise i don't see any gain in using it.

Nope, of course you wouldn't "simulate" the decoding hardware, you'd directly implement the codec decoding algorithms (or just bottleneck parts) for the stream processors (GPU shaders). That is write a MPEG-2 decoder, a MPEG-4 (ASP and AVC) decoder, ...

Downside is that the driver developers would have to directly mess with the video compression details, upside is the increased flexibility and the possibility to reuse this GPU-assisted decoding on other hardware, too (Nvidia or Intel).

edit: Well, or one would implement generic decoding building blocks... the DCT, MC - and perhaps codec specific helpers for bitstream unpacking etc. etc.

[Svartalf]

Aye.
Whenever HD video decoding fails on PCs it's basically never because of memory constraints. Decoding video won't drive your system into swapping (as long as no mem leaks happen).


The problem is... The card memory is a limited resource, typically, when compared to the memory of your system. You need to use that resource when you're doing this sort of thing. It's not that you couldn't do it, it's that you've got to take into account that someone only has 128Mb of card memory for these sorts of things. Please note: I'm not suggesting that this isn't a desirable thing to do- but if we can get dedicated hardware info instead, it'd be better.


Aye. Personally I think that's what GPUs are made for ;)


Heh...


Nope, of course you wouldn't "simulate" the decoding hardware, you'd directly implement the codec decoding algorithms (or just bottleneck parts) for the stream processors (GPU shaders). That is write a MPEG-2 decoder, a MPEG-4 (ASP and AVC) decoder, ...


Indeed. And it's something I think we should consider, really- but not our sole focus fort this problem we're seeing.


Downside is that the driver developers would have to directly mess with the video compression details, upside is the increased flexibility and the possibility to reuse this GPU-assisted decoding on other hardware, too (Nvidia or Intel).


Considering that SH showed that you could do generic GPU programming, I think you could make a case for doing things like what you're proposing on this instance. The big problem would be understanding how this stuff works- and you kind of need to to be able to drive the dedicated decode paths- it's largely blocks of the same nature as we're talking about and in order to really use them, in a making an API for them context, you need to understand at least a little something about those very details.

[givemesugarr]

The problem is... The card memory is a limited resource, typically, when compared to the memory of your system. You need to use that resource when you're doing this sort of thing. It's not that you couldn't do it, it's that you've got to take into account that someone only has 128Mb of card memory for these sorts of things. Please note: I'm not suggesting that this isn't a desirable thing to do- but if we can get dedicated hardware info instead, it'd be better.


this applies also to system memory. i appreciate diego petenò work on trying to fix a lot of shared memory stuff. if you follow a little his blog you'd understand about what this guy is trying to do and i completely agree with him on this part. using his ebuilds i've started to increase (by slow ammount for now) the speed of processes and to lower the needed memory. this happens because i use a lot of stuff that is based on similar libs (an example is amarok and kaffeine but there really are a lot more).



Indeed. And it's something I think we should consider, really- but not our sole focus fort this problem we're seeing.


i personally don't really like this solution. to me it seems like a workaround to load the video board instead of loading the core system and bypassing the hw decoding block. in my opinion this solution should only come out when everything in the driver work well and this would only be a cherry over a piece of cake.


Considering that SH showed that you could do generic GPU programming, I think you could make a case for doing things like what you're proposing on this instance. The big problem would be understanding how this stuff works- and you kind of need to to be able to drive the dedicated decode paths- it's largely blocks of the same nature as we're talking about and in order to really use them, in a making an API for them context, you need to understand at least a little something about those very details.

this could be simpler with gallium 3d for what i've understood of the explanations about it. before that generic gpu programming could be useful, but the hw are too much different to be able to use a lot of generic gpu programming.

[curaga]

I have a BIG question to bridgman:

How come Via has been able to give us a driver with HD decoding?

[givemesugarr]

I have a BIG question to bridgman:

How come Via has been able to give us a driver with HD decoding?

i'm sure that they have a different hw architecture for their boards. and you know well that via boards aren't as good as ati's, at least in my opinion.

[curaga]

Earlier in this thread bridgman said no company has done so.

Via is my favorite company, right after Intel. Their open source drivers are second best to Intel in Linuxland for features. After them is Matrox, but as their cards don't have hw for HD, they can't implement that.

Via's graphics are similar to Intel's; not awesome 3d game performance, only OK, but watching video and normal use, they rock.
I'd prefer a Via card to Ati any day.

[bridgman]

I'm not 100% sure, but AFAIK the Via chips only include HW for IDCT and MC, so only those portions of H.263/4 and VC1 are accelerated. There is a VLD extension but not sure if that is just the MPEG2-type VLD or the new stuff (CAV..whatever).

libv (one of the radeonhd developers) was also "the man" for the Unichrome project, so he'll likely know for sure.

So far it appears that we will also be able to expose the blocks which provide IDCT/MC functionality (and I think there's some VLD support there too) for open source drivers. It's the more advanced stuff in UVD that poses the IP challenge. We won't be sure about UVD for a few more months but unless we have a "eureka" moment it's going to have to stay closed.

Part of the confusion here may be that "HD Decoding" seems to mean different things to different people :

- "HD resolution" ?
- "partial but meaningful HW acceleration of video standards like H.264 and VC1" ?
- "full HW acceleration of those standards" ?

[curaga]

Intel is on the way for doing iDCT and MC too (vaapi).

The question is, why should I or any other guy, go buy an AMD card over any other, if you even with the new open strategy only provide something others have provided for some time.

[bridgman]

My thinking was that you would buy our products because they were best suited for your graphics needs.

If you want powerful 3d hardware *and* active support of open source driver development, we seem like a pretty good choice ;)

[Kano]

After 12 month waiting when you get much better cards for the same money ;)

[bridgman]

Are you saying "12 month delay" for powerful 3d hardware or for active support of open source driver development ?

[givemesugarr]

Earlier in this thread bridgman said no company has done so.

Via is my favorite company, right after Intel. Their open source drivers are second best to Intel in Linuxland for features. After them is Matrox, but as their cards don't have hw for HD, they can't implement that.

Via's graphics are similar to Intel's; not awesome 3d game performance, only OK, but watching video and normal use, they rock.
I'd prefer a Via card to Ati any day.

are there any via boards that aren't igps?!

[Kano]

bridgeman:

compared to the fglrx driver the oss driver at least improves faster. fglrx is downgrading like no working pointsprites support since new codebase, no real modeline support (still want to know which modelines and Xorg release was tested for last release notes, 7.1.1 segfaults). So 12 mouth is a friendly guess to have at least AIGLX + xv working with oss driver. Currently AIGLX only works with Xserver 1.3, when you use it with beryl + 7.1.1 then you get a white screen pretty soon. Also Xserver 1.4 support with new codebase is a joke when you need to start glxgears before running amdcccle or any other 3d app... ATI is completely unable to fix these tiny issues, so you need a new definition of high preformance I guess.

[Svartalf]

My thinking was that you would buy our products because they were best suited for your graphics needs.


Right now, not a single one of the normally used suppliers of GPU technology meets my needs appropriately. In some way, they all fall short. Even your employer, John. Yours is the one with the greatest promise- but you're NOT usable in the large right at the moment. That's just how it is.

It'll be vastly better eventually and would be the preeminent choice for everyone- but that's at least 6-12 months from now. Most of the frustration and ire you see in these forums directed to AMD/ATI is due to that fact- and that the general feeling is that this was something that probably ought to happened a bit sooner than it ended up happening. Right or wrong, that's the impression I suspect everyone has- I suspect things will get where people are believing what you're telling us here when the 3D info drop happens and we start seeing real 3D support out of the R500/R600 based devices.


If you want powerful 3d hardware *and* active support of open source driver development, we seem like a pretty good choice ;)

Heh...

Right now, Intel supports things slightly better on the open source front, unfortunately for AMD.

Unfortunately for them, only the GMA x3500 shows to be the first honestly usable, in the large, device they've fielded to date- all the others fall short. They are usable for Compiz if you're operating in the right memory profile, etc. but for games, they're realy subpar like most IGP offerings. It remains to be seen what they accomplish with Larabee- it may be that they make themselves a contender. It may serve to disappoint just like all the other past attempts IGP and discrete that Intel's fielded. And almost ran, but never quite enough for that generation. No telling at this point on them.

Your hardware's vastly superior to pretty much everyone else's except NVidia's offerings, and it's more of a subtlety between yours and theirs- with the overall edge going to AMD if you combine all the strengths shown on paper. Unfortunately, NVidia's drivers work better than yours in our space right at the moment and the Open Source answers aren't there enough yet.

NVidia...They're not open. In some ways, it places them dead last. (That may be one of the reasons for the rumblings of opening up at least some on the 3D support front from them...) But, unfortunately for all the other players in the game, they largely just work on Linux out of the box. And, work right on a broader range of applications than everything but certain FOSS supported devices.

Once we start seeing real 1.5 API support and some 2.X support on your stuff in the DRM or Gallium driver space, then things will definitely change in what I just stated. Then it will be a good choice in the long-term picture of things. But for now... <*sigh*>

[Svartalf]

are there any via boards that aren't igps?!

Not any more. They're fielding on-board devices for the server, low-end laptop, and embedded spaces from S3 these days. You could probably find a couple of discrete boards from them, but they're mostly eval parts so you can develop applications against the GPUs. Not to mention that they're just not in the same class as even Intel's GMA's for the large part. They're better than Intel's GMAs on the discrete front, but unless the IGP has a raftload of dedicated dual-port memory, it doesn't fare as well as Intel's offerings in this space, let alone AMD's or NVidia's...

[Raven3x7]

Not any more. They're fielding on-board devices for the server, low-end laptop, and embedded spaces from S3 these days. You could probably find a couple of discrete boards from them, but they're mostly eval parts so you can develop applications against the GPUs. Not to mention that they're just not in the same class as even Intel's GMA's for the large part. They're better than Intel's GMAs on the discrete front, but unless the IGP has a raftload of dedicated dual-port memory, it doesn't fare as well as Intel's offerings in this space, let alone AMD's or NVidia's...
Actually there are but they are sold as S3 chips and are very hard t get hold of. I dunno if they have the same level of linux support. www.s3graphics.com

[bridgman]

Thanks all. In case it helps, I was answering curaga's question which was essentially "where is the advantage if you're not the first to expose video acceleration". My answer was that we weren't trying to compete in the open source space by "opening more stuff than everyone else", just by having good hardware and making sure that we provide good and ongoing support to the open source driver dev community.

I think we will get to AIGLX and video a lot sooner than 12 months, but obviously it depends on how quickly the development community engages. Right now a very small number of X devs are doing all the hard work.

This is really an open source thread and my role is primarily open source so I'll just make quick comments on the fglrx side.

I have mentioned before that our focus for fglrx has historically been workstation users, who generally use a much more tightly constrained set of distros and care most about support on "the major distros that shipped a year ago". We have been gradually ramping up our consumer Linux focus recently, so you should see ongoing improvements there. Getting the Linux driver onto the new OpenGL code base was a huge step forward (even if there were a few missing bits) because it meant that work done for other OSes would also benefit Linux users. That, in turn, frees up a bit more of the Linux dev team's time to work on Linux-specific issues.

Kano, I can ask about 7.1.1 but I imagine the AIGLX testing would have focused on 7.2 and 7.3 xorg releases. Do you see a lot of need to support and maintain new features on the older xorg releases ?

[Svartalf]

Actually there are but they are sold as S3 chips and are very hard t get hold of. I dunno if they have the same level of linux support. www.s3graphics.com

Well... Most players in the low-end very cheap value space seem to be using cheap NVidia or AMD parts instead of S3's stuff. I've not seen a discrete S3 based board in at least a year or more. Of course, I've not been mucking about at a cheap parts wholesaler (throw a rock in Dallas, hit at least 1-3 of them... >;-) ), so I could be missing out on some more testing parts for stuff- food for thought and an excuse to hit some of my old haunts... Other than that possibility, I'm not aware of any consumer for S3's offerings than VIA themselves as IGPs on the stuff they field on the EPIA and other lines of motherboard chipsets. It might be a different story overseas, but without info from someplace like Taiwan or elsewhere, I can only go on what I'm seeing here in the States.

They do appear to have beta drivers for their latest Chrome boards available, though they're closed compared to the official VIA support on what we DO have.

[curaga]

Another question: since you will be exposing MC and iDCT, will you be doing so for all of your hardware that supports either?

Aka all cards from Rage II+dvd onwards.

I happen to own that card. When I first got it, I was like "this has mpeg1 and mpeg2 MC, cool. Is it supported? No." My first disappointment in Ati.

I know you are forced to look at new chips first, but I really hope you will also concentrate on older HW that hasn't had HW accel yet. There you would beat Nvidia, because their cards have had HW accel since Geforce 2, but their driver only supports XvMC from Geforce4 onwards.

[bridgman]

For anything earlier than Radeon I wasn't planning to publish documents but would try to provide info to developers who were working on something specific. Finding information will be tough though -- the Rage II is something like 8 generations old by now.

Do you think MC acceleration on the old cards will be any use these days, ie are developers going to spend the time to support it ? I doubt the hardware is fast enough to handle anything more than SD resolution.

[curaga]

It will still be of good use. For light media centers, such as Geexbox or a Mythtv frontend, they are used in older computers, with the cards that are in them.

So, any user who owns a card capable of MC would want to get a chance to use it. This is just how I see it, and I would love to get it to use too.
If it makes anything playable on a comp that wasn't playable before, it's worth it.

For an example, my Pentium 2 366Mhz box, with the said card (Rage II+dvd) can play dvd-resolution Xvid videos with Geexbox and Vidix Ati acceleration. Vidix however only accelerates the drawing part, not the decoding. And as such, the box can't play H.264. I have read somewhere that MC is about 20% of the decoding, so I believe using it might make this play H.264 in SD resolutions.

[bridgman]

Vidix however only accelerates the drawing part, not the decoding. And as such, the box can't play H.264. I have read somewhere that MC is about 20% of the decoding, so I believe using it might make this play H.264 in SD resolutions.

I'm pretty sure we're only talking about MPEG-2 acceleration for the older chips. MC for H.264 is quite a bit more complex than MC for MPEG-2 -- block size, motion vector resolution, number of reference frames, and interpolation between reference pixels are all different. H.264 MC is expensive for precisely that reason -- it does more complex processing than what was needed for MPEG2.

It's a fairly safe bet that the older MC hardware was designed for SD MPEG-2 only -- that's why we didn't see much interest in supporting that hardware today. We can try to dig up the HW info when we get to video in a couple of months but I wouldn't get my hopes up.

[curaga]

Ah. I was afraid it would be like that.

Anyway, thanks :)

[legume]

Hi

It's really cool to see AMD supporting oss and engaging users as in this thread.

One question I have is about h/w deinterlacing.

Do the r5xx,6xx chips have this capability and if so will it be possible to support/release docs for it?

Thanks.

[soundworks2]

I'm very nice surprised seeing posts with AMD person on phoronix, with lot of substance! I belive when peoples start speaking together, the will better undestend each other and they needs.

From my part I just like to add to the DRM discussion just one analogy. DRM is simpliefied for me discusion about encryption/decryption and certificates/keys management. It remebers me very strong on the discussion about Encryption with Wifi Drivers....

In my opinion, the company, which want keep secrets, they shoudn't put it in Drivers but put it in HW firmware ( or some special EPROM place which can't be readen directly.. )like it ends up on wifi HW. This way will also be easier for them to maintain it. Drivers for windows and Linux will do the same for DRM calling basicaly calling some functions provided by HW.

[butdie]

I don't even want any hardware with built-in DRM support.

all the discussion makes it clear to me, go Intel for video.

my old intel i830 onboard video can play aiglx well, while my much later ati card with 256MB dedicated vram is still struggling to play full screen video.

it's really nice to watch RMS's sign,"Don't buy from ATI, enemy of your feedom"

I reckon that CPUs will get fast enough to handle HD content in a couple of years without GPU acceleration. I can remember back in the late 90s/early 00s when you had to have GPU acceleration or a hardware mpeg2 card to watch DVDs. My old k6-2 500 with 128 Mb Ram and 16 Mb 3dfx card couldn't handle watching DVDs. Most modern computers can.

My c2d 1.6 gig laptop can handle 720p hd content without GPU acceleration on VLC media player so I reckon in a couple of years the debate will be obsolete. What does anyone else think?

[bridgman]

I don't even want any hardware with built-in DRM support.

all the discussion makes it clear to me, go Intel for video.

my old intel i830 onboard video can play aiglx well, while my much later ati card with 256MB dedicated vram is still struggling to play full screen video.

it's really nice to watch RMS's sign,"Don't buy from ATI, enemy of your feedom"

I don't think the video playback differences you are seeing have anything to do with the presence of DRM hardware. All of the graphics hardware vendors have the same DRM obligations, and we all have the same need for DRM hardware.

I think you're saying that you believe ATI/AMD somehow have more DRM hardware than other graphics vendors -- am I interpreting you correctly ?

[curaga]

Well, I'm also a lucky owner of i830, and know it only has Macrovision hardware for DRM. It's just not used.

I believe though that not every company puts DRM stuff in the cards. Via doesn't.

PS: I also believe it's great to be able to chat with an AMD person.

[bridgman]

Well, I'm also a lucky owner of i830, and know it only has Macrovision hardware for DRM.

I didn't think the 830 had video decode hardware (IDCT/MC etc). The DRM only comes along as video decoding hardware is added to the chips. Old ATI/AMD chips were the same way.

I believe though that not every company puts DRM stuff in the cards. Via doesn't.

Everyone does these days, even Via/S3 :

http://www.s3graphics.com/en/technology/chromotion/

Scroll to the bottom and note the encryption/decryption hardware in the lower left corner. That's all we're talking about -- on our parts or anyone elses.

[Svartalf]

Everyone does these days, even Via/S3 :

http://www.s3graphics.com/en/technology/chromotion/

Scroll to the bottom and note the encryption/decryption hardware in the lower left corner. That's all we're talking about -- on our parts or anyone elses.

That's because someone sold them on the "need" for that sort of thing. They think it's "valuable" and that they need to prevent people from getting the raw stream so they can copy it. Hate to disillusion them, so far, they're batting a thousand on keeping people out and all they're doing is making the clientelle much more angry with them. For both the MPAA and the RIAA (and their members)- they're making the problem worse. If you presume to think your customers are thieves and treat them as such, eventually they start acting the part or quit buying/using in general.

Biggest question for AMD would be how integrated is the decryption stage to the rest of the hardware assist engine on the video playback portions of the chips? If you've mashed them together, this would be an example of a multi-billion dollar industry, that honestly doesn't provide the main source of your revenue for that product lineup, telling a multi-trillion dollar industry what to do. Bass-ackwards, if you ask me.

[curaga]

i830 has only MC, and it's currently not supported on linux :(

Via didn't use to have that, must be the current trend.

[bridgman]

Biggest question for AMD would be how integrated is the decryption stage to the rest of the hardware assist engine on the video playback portions of the chips?

The integration is pretty tight for all the vendors -- it's how we get low CPU utilization and low power draw during video playback (yes, on that other operating system ;)). The question is to what extent we can expose one without the other. I'll know more once we get past 3d and shift focus to video acceleration.

If you've mashed them together, this would be an example of a multi-billion dollar industry, that honestly doesn't provide the main source of your revenue for that product lineup, telling a multi-trillion dollar industry what to do.

I'm pretty sure that the movie industry is *much* bigger than the GPU industry, although it is probably smaller than the PC industry as a whole. Let's see -- 2007 looks like $23B for DVD sales, $9.6B for box office sales (and probably $50B for popcorn and drinks ;)) so maybe $32B for movies, vs maybe $6-7B for graphics hardware ? The graphics $$ go up if you include boards built by third parties, but we only sell the chips so I would argue those revenues don't count.

Video playback may not be the largest "driver of sales" but providing protected video paths is a requirement for Vista, and Vista is a requirement for OEM sales, and OEM sales are a requirement for ongoing success in the market. The challenge is how best to meet the non-negotiable requirements of the Windows market while not inconveniencing the Linux market. I think we have a plan that can do both, but it sure isn't as easy as it was back in the R200 days.

[lucky_]

The challenge is how best to meet the non-negotiable requirements of the Windows market while not inconveniencing the Linux market. I think we have a plan that can do both, but it sure isn't as easy as it was back in the R200 days.
I don't think there will ever be a good way, if they fail this time it will be for windows seven.
Microsoft is known to put big efforts to make the hardware VISTA only.
Microsoft will ever play this game, no matter how they act with novell.

[SavageX]

Well, I consider it a sad fact that there is hardware DRM in today's graphic cards (all of them).

Having said that I don't actually care thaaaat much as long as I have the *choice* to not use it. The worst case would be the DRM being active all the time and "protecting" e.g. self-produced video (think Microsoft Zune, where *every* song gets squeezed into a DRM container). This, however, is not the case with the GPU DRM stuff and as long as it stays this unintrusive I can live with the DRM hardware units sitting in my computer, being busy with... nothing.

If future ATI GPUs are designed so the video processing functionality can be used without even touching the DRM stuff things are perhaps as good as they can (realistically) get.