[wtallis]

> "But that's not because the algorithms are new and awesome, it's mostly just because the exact specs of the hardware are not happily shared."

No, that doesn't fully explain the situation. They're worried about far more than their competitor knowing how many ALUs are on their GPU. Graphics drivers have to solve several hard problems: optimizations for shader compilers, scheduling, and memory management, and that's before you even get into the graphics-specific stuff. In recent years, GPUs have been one of the most active areas of research into computer architectures. For you to suggest that a modern GPU and its drivers don's embody any hardcore CS research is just plain stupid - if GPUs were simple to build, then Intel would have shipped a good IGP by now.

[fghh45sdfhr3]

I not disagreeing that they do include core CS problems, I just don't believe their solutions to the core of those problems are that far ahead of academia.

In terms of the vendor specific features, sure, neither academia, not anyone else knows much about them. But in the fundamentals of scheduling, binning, etc, I don't think anyone is very far ahead of all of academia.

[wtallis]

Just because a grad student somewhere has discovered an algorithm doesn't mean their knowledge is on par with the company that knows when that algorithm is actually useful, and has shipped code using it. Writing a textbook on matrix decompositions and factorizations doesn't mean you would be able to create a Google-quality search engine given a large enough server farm and a few months to crawl the web. The state-of-the-art is far more than what's theoretically possible, and the really abstract stuff like proofs of bounds on the asymptotic running time of a solution to a problem have never been the kind of research that is patentable. Even if the equation is known in academia, if a company spent years and millions of dollars to find the right coefficients, then the company is ahead of academia in a non-trivial way. Reduction to practice matters.

[gbhn]

But that's the opponents' point -- the values of such coefficients make excellent trade secrets, but the fact that you can, for instance, invert a matrix, is poor material for a patent.

Personally, I think the limits of software patents should be to precise algorithms. This ends up protecting the fruits of laborious research which have found optimal solutions (in an engineering sense) to things like cryptography, or graphics, or video compression. The disclosure of these algorithms would indeed advance research and the useful arts, and the disclosure would be advantageous. Most software patents, though, are "a system for clicking on a button, but INNA FONE!!!" type of nonsense where disclosure does absolutely nothing, anyway. So sure, such posers ought to be able to patent the exact algorithm they use to click their button, if they want, but NOT to patent the idea of clicking a button, which is in effect what we have now.

This separation goes pretty far towards the concerns the OP wrote down, and is, I think, pretty intuitive to most programmers. It is also the closest to copyright, but without requiring the legal jangle of "well, you used the variable i, but I used j, so therefore my code is different!!!1!one!!" kind of nonsense that pure copyright might result in. Patenting a precise series of disclosed algorithmic steps is helpful, and is a bright line for the patent office, and easy to adjudicate as well. Patenting the notion that you can transmit particular kinds of data over a network, or have certain programs talk to other programs, is where the PTO went off the rails.