Hypothetical GPU

[Darkfire Fox]

Hello! This is my first post, and I must admit that Phoronix has been a blessing to me as a new Linux user. Keep up the good work!

My question is purely a hypothetical one, and involves GPUs and DRM. If this has already been covered, I apologize in advance.

Suppose some no-name silicon company (Darkfire Computers & Electronic Systems ) created a general-purpose vector processing unit that totally blew away anything nVidia, ATi, or Intel could create that generation, for a fraction of the cost. Suppose it was based on a MIPS-3D arcitecture and sported 80 MIPS cores, each containing 80 vector processing elements, for a grand total of 6400 SIMD cores. Suppose the engineers could get it to clock, on air, at 4Ghz per MIPS core, and this monster's compiler could keep all those cores fed with data at all times. Yes, this bad boy can play Crysis at 100fps on ultra-high quality.

Here is the interesting part. This heretofore no-name company has no intention of bowing to the false gods of RIAA and MPAA, and therefore signs absolutely no deals with them or anyone affiliated with them. This company, being crusaders for all things FOSS, release 100% of the programming documents for 2D rendering, 3D rendering, 4D physics, video decode, and general-purpose processing. This company was so generous, it also releases a cross-arcitecture C/C++ language emulator that allows x86_32 and x86_64 compiled binaries to run on this GP-GPU, under the GPLv3.

Here are my questions: what legal ramifications, if any, would this company face? What would its market be? Could there be any way to write drivers for Microsoft Windows or Apple OSX, which have married themselves to DRM? Would its marketshare be strictly limited to Linux and Unix systems? I'm very curious about all this. I just recently wiped Windows XP from my computer and now solely run Linux distros.

As you can probably tell, I made all that stuff up, so please forgive me if my fantasy GPU is a little absurd. I'd like to hear your responses. Cheers.

[deanjo]

Here are my questions: what legal ramifications, if any, would this company face?

None if they don't include content decryption. If they did they would be in violation of the DMCA act.

What would its market be?

Too small of one to survive.

Could there be any way to write drivers for Microsoft Windows or Apple OSX, which have married themselves to DRM?

Absolutely, driver models for both OS's are open for development and well documented. You just wouldn't have any DRM playback just like older video cards that do not have DRM protected content support still can be used in both OS's.

Would its marketshare be strictly limited to Linux and Unix systems?

Wouldn't need to be, but having no DRM playback would be a stroke in the minus column for other OS's.

[Ex-Cyber]

Here's what I expect would happen if you were lucky: you'd release your awesome GPU, then Intel, NVidia, or AMD would find some patent(s) that your design infringes and use that as leverage to buy out your company. Then, unless all your engineers quit in protest, the next chip would be a big-name product with all the bowing to MPAA that entails.

If you were unlucky, subtract the buyout part and they just sue you into oblivion.

That said, it might be worth doing anyway.

[bridgman]

You would have no problem writing drivers for Windows or any other OS. Don't underestimate the cost though... writing a driver stack which can run Crysis at 100FPS is a much bigger task than you might think.You would have a tough time getting certification though, since these days that requires a certain amount of content protection support (which in turn is significantly helped by on-board encryption and secure key management).

Without certification your OEM market would be nil other than as a compute card.

You might still have a valid Windows retail market, which is nothing to sneeze at but is not big enough to carry the costs of typical GPU development. If your development costs were significantly lower though, as a result of using standard technology, then you could have a viable business.

[Darkfire Fox]

Interesting... though it seems the DMCA throws a wrench into my plans for world domination...

Seriously, though, why are GPUs seemingly singled out by DRM, when anyone can write a library for content decryption on a traditional CPU purchased from Intel or AMD? Why aren't *they* being sued into oblivion for failing to protect Hollywood's cash machine? If some company created a general-purpose vector processing unit based upon a well-known arcitecture -- such as MIPS -- couldn't a standard player/decrypter be written for it?

*sigh* At least my fantasy GPU could get a sizable chunk of the workstation/server business market so long as they don't involve Hollywood movies, right?

As you guys can probably tell, I'm kinda new to this stuff, so if I'm missing something obvious, feel free to slap me.

Oh well, it's fun to dream. One can only hope the DMCA gets repealed someday.

[Ex-Cyber]

Interesting... though it seems the DMCA throws a wrench into my plans for world domination...

I don't see how. DMCA doesn't require you to implement access control measures, it just disallows you from providing ways to break them. Microsoft's signing requirements could be a problem, though.

Seriously, though, why are GPUs seemingly singled out by DRM, when anyone can write a library for content decryption on a traditional CPU purchased from Intel or AMD? Why aren't *they* being sued into oblivion for failing to protect Hollywood's cash machine? If some company created a general-purpose vector processing unit based upon a well-known arcitecture -- such as MIPS -- couldn't a standard player/decrypter be written for it?

The CPU is probably already considered to be a lost cause, and they're just biding their time until they can declare "hardware acceleration" (i.e. encapsulation of the AACS decryption/decoding/HDCP encryption process somewhere that the CPU can't get at the intermediary frame) mandatory for HD playback. None of this will really affect anyone who downloads all their movies from torrent sites, but I'm sure the MPAA can find a way to spin it as a big success anyway.

[deanjo]

I don't see how. DMCA doesn't require you to implement access control measures, it just disallows you from providing ways to break them.
.

HDCP compliance is required to play HD protected content. That license can only be obtained if access control measures are implemented, leaving the only solution to be a product that violates the DMCA act. If your devices are not 100% HDCP compliant then your video quality is degraded by design. Yes there is software solutions out there to address this, however none of those solutions are "legal" in the States.

http://www.digital-cp.com/files/stat...ent_090608.pdf

[Ex-Cyber]

HDCP compliance is required to play HD protected content. That license can only be obtained if access control measures are implemented, leaving the only solution to be a product that violates the DMCA act.

Yes, assuming that protected HD playback is actually provided by the product. I thought the idea here was basically to just provide the silicon and let the user/community program it, much like a commodity CPU.

[_txf_]

Yes, assuming that protected HD playback is actually provided by the product. I thought the idea here was basically to just provide the silicon and let the user/community program it, much like a commodity CPU.

this already exists:

http://wiki.opengraphics.org./tiki-index.php

of course it isn't an uber gpu and it doesn't offer good value for money in terms of performance.

It is however freely programmable and upgradeable by nature due to the fpga. Dunno if they're going to offer a non programmable (and cheaper) asic version.

[bridgman]

Yes, assuming that protected HD playback is actually provided by the product. I thought the idea here was basically to just provide the silicon and let the user/community program it, much like a commodity CPU.

If you let the community do all the programming then you probably don't have a Windows market. There is no requirement to have any DRM stuff unless you are aiming at the larger market segments.

Seriously, though, why are GPUs seemingly singled out by DRM, when anyone can write a library for content decryption on a traditional CPU purchased from Intel or AMD? Why aren't *they* being sued into oblivion for failing to protect Hollywood's cash machine? If some company created a general-purpose vector processing unit based upon a well-known arcitecture -- such as MIPS -- couldn't a standard player/decrypter be written for it?

The DRM food chain works something like this :

- in order to write an application which plays HD-DVD or Blu-Ray and which is legal in all major markets you need an AACS license

- in order to get the license you need to make commitments about protecting the content which the license allows you to decrypt

- in order to have confidence that you can protect the content you need to have commitments from the graphics card vendor (since they provide the drivers which control outputs and which can confirm that an output is protected)

I think this is the relevent agreement. Take a look at Exhibit F part 2 : http://www.aacsla.com/support/AACS_I...rmt_080626.pdf

Back in the dark ages there was a standard API for protecting analog outputs (from Macrovision) but nothing for digital. Intel and Microsoft provided a standard solution for digital outputs -- HDCP for the actual link protection and COPP (XP) / PVP-OPM (Vista) to provide a secure API for controlling the outputs.

By providing a standard API for digital output protection and by requiring robustness commitments from the graphics card vendor as a condition of certification, it means that player app vendors just need to confirm that they have certified Windows drivers in order to have confidence in the video path from player to display connector. Having a certified Windows driver, in turn, becomes a pre-requisite for any hardware OEM aiming at the consumer (and, increasingly, business) markets.

If the player does everything in software then secure output protection is all you need, but if the graphics card is going to help with decoding and rendering then additional protection is required, and AFAIK that is where all the nasty on-chip DRM hardware comes in. For the hypothetical GPU, this means that if you don't offer video acceleration on the card (or if you limit the resolution to what AACS-LA calls a "contrained" image, ie 960x540) then you probably don't need much DRM support on the card to sell into the Windows market... but then you are probably limited to the workstation business and even that market is starting to expect video acceleration nowadays.

Anyways, bottom line here is that if you want to sell into the larger markets you need a legal BluRay playback solution, which in turn needs a licensed player vendor, and *they* in turn require a secure way of knowing that they are going to protected outputs and that any processing performed by the graphics card is sufficiently secure.

The risk comes from the hierarchy of legal agreements which provide end-to-end coverage from the original content providers through the player app, the OS, the drivers and the hardware. Everyone involved has to put a body part or two on the line in order to join the game, but if you don't do that then you can't sell the high volumes required to keep funding advances in GPU performance and capabilities.

It would be nice if we could separate out graphics and video processing, but unfortunately integrating everything on one chip gives the most cost-effective solution, and the graphics market has always been viciously cost-sensitive for the high volume deals.