No subject

Wed Sep 1 14:14:17 PDT 2010

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

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 th=

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.

More information about the mesa-dev mailing list