> I think we need to be sure we're not infringing on this patent. Until > we know one way or the other I'd prefer that we don't merge this > branch into master. In the mean time I'll see if I can learn more > about the situation and find a way to proceed.
For anyone interested in determining the applicability of the patent, the following may be of interest. Note that this is obviously not legal advice, and could merely serve as a starting point for a proper legal analysis. First, ARB_color_buffer_float (the only extension requiring significant work) doesn't actually require that floating point rendering is supported. Instead, as issue #22 in the spec says, it merely provides the ability to ask for them and check their availability, and provides the ability to disable clamping in several intermediate parts of the pipeline. Thus, it's likely that just ARB_color_buffer_float, which is most of the changes, doesn't infringe. Second, the distribution of only source code might be non-infringing, and there is precedent of projects doing this (freetype, ffmpeg, x264) and Intel lawyers agree on this point according to Eric Anholt. Also, from the first court decision, it appears that SGI (plaintiff) and the court agree that the patent doesn't cover software. >From >http://wi.findacase.com/research/wfrmDocViewer.aspx/xq/fac.%5CFDCT%5CWWI%5C2008%5C20080801_0000734.WWI.htm/qx << b. Graphics Hardware The parties are at odds over a major issue: whether the claims in issue are directed to a computer system operating on specialized rasterization hardware that allows for high speed, interactive rendering through a graphics pipeline. It was reasonable for the jury to find that it was. Plaintiff's expert, Dr. Stevenson, testified that the '327 patent is directed to "a special purpose hardware component designed and optimized specifically for high speed graphics processing." Trial Tr., dkt. #559, at 49. The specification makes it plain that the invention does not relate to software for graphics. As the inventors noted, such programs "are well known in the art." 327 pat., col. 1, ln. 13. The inventors explained that they had discovered "that it is now practical to implement some portions or even the entire rasterization process by hardware in a floating point format." Col. 2, lns. 54-57. (Emphasis added.) Even defendants' expert, Dr. Potel, agreed that the claims at issue in the '327 patent cover hardware. Trial Tr., dkt. #563 at 124. Claim 17 does not say in so many words that the method it discloses is a rasterization circuit operating on a floating point format, but that is what it describes. Reading the disputed claims as disclosing hardware is not reading a preferred embodiment in the claims; it is simply reading the claims as the person of ordinary skill would read a patent directed to special purpose hardware. >> I'm not sure if this actually has any legal force anywhere, but seems quite persuasive anyway, both due to SGI and the judge claiming this and for the reasoning itself that 'As the inventors noted, such programs "are well known in the art"', which makes sense, since it's actually easier to write a (sophisticated) software renderer with floating point sampling and rendering, than one without, since floating point is used internally anyway. Also, support for floating point rendering happens automatically as a byproduct of generic format support, and in fact softpipe already supported it with blending disabled, even though it wasn't usable from OpenGL due to the lack of code to convert GL_RGBA32F to PIPE_FORMAT_R32G32A32G32, and likewise for other enums. In fact, if you started from the final source code of the "floating" branch without version history and tried to remove features to avoid the patent, you might either not remove anything, just add a define or configure option, or remove a lot of code and functionality already present and shipped (such as code for handling floating point vertex buffers). This fact, along with the lack of claims of specific hardware implementation techniques, might give some weight to the patent being invalid as a whole due to the lack of any non-obvious innovation over prior art. On the other hand, ATI hasn't currently managed to persuade the court of this. Note that the S3TC patents look much stronger in comparison, since in that case both the format and algorithms are not as basic as this one. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
