DirectX vs OpenGL !!
Sylvain Mayer
Hi,
I wonder if someone could point out some differences between those
tools kits.
I'm interesting in graphics stuff (much more than sound, video, etc).
Which one should I use?
--
Sylvain Mayer
CAE Électronique Ltée, Montréal
mail: ma...@cae.ca
Duane Strong
Sylvain Mayer <ma...@cae.ca> wrote:
>I wonder if someone could point out some differences between those
>tools kits.
>I'm interesting in graphics stuff (much more than sound, video, etc).
>Which one should I use?
From what I can see DirectX (Direct3D specifically) is for game
developers where OpenGL is for CAD types. Direct3D emphasizes speed
over precision, whereas OpenGL will have perfectly meshing polygons
and a richer API at the expense of rendering speed. Also OpenGL is a
cross platform API, so if you were porting a CAD program from an SGI
or something you would be interested in it. It sounds like for your
needs DirectX would be the one.
Allen Akin
In article <4vatd3$5...@darkstar.ucsc.edu>,
Duane Strong <dst...@cats.ucsc.edu> wrote:
| ... Direct3D emphasizes speed
| over precision, whereas OpenGL will have perfectly meshing polygons
| and a richer API at the expense of rendering speed.
At SIGGRAPH SGI demonstrated a version of OpenGL with performance
that's comparable to Direct3D; even faster than Direct3D in some
cases. When that's released (current plans call for mid-September)
there shouldn't be any performance reasons to prefer one of the APIs
over the other.
Allen
Chris Marriott
In article <32187E...@cae.ca>, Sylvain Mayer <ma...@cae.ca> writes
>I wonder if someone could point out some differences between those
>tools kits.
>
>I'm interesting in graphics stuff (much more than sound, video, etc).
>Which one should I use?
They are completely different.
OpenGL is *the* industry standard 3D graphics rendering toolkit.
Originally developed by Silicon Graphics and now an "open standard".
OpenGL apps can be ported relatively easily across virtually the whole
range of Unix and NT workstations. OpenGL's emphasis is on accuracy, not
speed - ie it's meant for applications such as CAD, scientific data
rendering, and other such uses where you want every pixel to be exactly
"right".
DirectX - specifically in this case Direct3D - is totally different.
It's Windows-specific, and *speed* is its primary goal, with rendering
accuracy coming a fairly distant second place. The main use of DirectX
is for games.
Chris
--------------------------------------------------------------------------
Chris Marriott, Warrington, UK | Author of SkyMap v3 award-winning
ch...@chrism.demon.co.uk | shareware Win31/Win95 planetarium.
For full info, see http://www.execpc.com/~skymap
Author member of Association of Shareware Professionals (ASP)
--------------------------------------------------------------------------
Mark Segal
In article <UwCdWBB9...@chrism.demon.co.uk>, Chris Marriott
<ch...@chrism.demon.co.uk> writes:
...
|> range of Unix and NT workstations. OpenGL's emphasis is on accuracy, not
|> speed - ie it's meant for applications such as CAD, scientific data
|> rendering, and other such uses where you want every pixel to be exactly
|> "right".
...
Allen Akin already responded to a similar statement in a previous
post. But I'll respond too, since this unwarranted implication
that OpenGL compromises speed for 'accuracy' seems so prevelant.
In fact, OpenGL was very carefully designed so that it could be
implemented to achieve very high performance. And it's not so
much that OpenGL is 'accurate' (this is a pretty vague term in
this context), but that it has a rich set of general features
that can be combined in intuitive, independent ways to yield
a wide variety of drawing styles and effects. A well-designed
OpenGL implementation should run as fast as any other graphics
API. This is true even if the other graphics API provides far
fewer or more restricted features than OpenGL as long as only
the features of OpenGL that are present in the other API are
actually being used.
SGI demonstrated a fast PC implementation of OpenGL in their
booth at SIGGRAPH, running just as fast as Direct3D on similar
scenes. SGI hopes to release this implementation in September.
Mark
Chris Frazier
|> >I wonder if someone could point out some differences between those
|> >tools kits.
|> >
|> >I'm interesting in graphics stuff (much more than sound, video, etc).
|> >Which one should I use?
|>
|> They are completely different.
|>
|> OpenGL is *the* industry standard 3D graphics rendering toolkit.
|> Originally developed by Silicon Graphics and now an "open standard".
|> OpenGL apps can be ported relatively easily across virtually the whole
|> speed - ie it's meant for applications such as CAD, scientific data
|> rendering, and other such uses where you want every pixel to be exactly
|> "right".
Hmmm,
Where do people get this stuff about
accuracy? Admittedly some OpenGL machines are very accurate, but
that has little to do with OpenGL, per se.
Originally OpenGL had some floating point
computations in it and this bothered Intel and
Microsoft which originally were originally affected by
bad floating point performance on 486 CPU's,
Intel and Microsoft made a few comments about how
expensive the floating point computations were,
and how this was just a teeny bit
unnecessarily accurate.
SGI responded by saying that we had nothing to gain by getting
rid of the floating point stuff, so we didn't want to do
the work, but that it could be done and if Microsoft and Intel
wanted to do the work, we'd support it if it was done carefully.
Almost immediatedly Intel's floating point performance improved
and Microsoft decided not to work on getting rid of the floating
point requirements
Somehow the 'accuracy' characterization stayed in spite of
the fact that most of the world moved on past 486
capabilities.
ChrisF
Chris Marriott
In article <4vcsjk$g...@fido.asd.sgi.com>, Mark Segal
<se...@spud.asd.sgi.com> writes
>Allen Akin already responded to a similar statement in a previous
>post. But I'll respond too, since this unwarranted implication
>that OpenGL compromises speed for 'accuracy' seems so prevelant.
Mark - I didn't mean to imply that OpenGL can't be fast because it's
accurate; apologies to all at SGI if that's the way my message came
across. What I *meant* to say was rather the opposite - that Direct3D
*sacrifices* accurary for speed.
Lee Byung Uk
Allen Akin wrote:
> At SIGGRAPH SGI demonstrated a version of OpenGL with performance
> that's comparable to Direct3D; even faster than Direct3D in some
> cases. When that's released (current plans call for mid-September)
> there shouldn't be any performance reasons to prefer one of the APIs
> over the other.
>
> Allen
I'm very glad to hear that there gonna be a
good opengl libraries.
Anyway, if possible, could you explain about that
more precisely.
For my knowledge, the performance is dependent on whether there is
a mechnism to use the acceleration function supplied by
specific graphic card or not. That means to use full functions
of specific graphic card, the card vendor must supply according
drivers ( so called , 3D DDI ). And I think there is only few
vendors who is gonna support opengl.
In that respect, It is most probable that most the vendor will
support microsoft DirectX and that of RealityLab.
Do SGI announced something about that ??
Any comments will be appreciated !!
--
Lee Byung Uk [http://agent.isl.goldstar.co.kr]
Agent Group [mailto:bu...@mmedia.isl.goldstar.co.kr]
Multimedia Research Lab ~~~~~~~~~~~~~~~~~~~~
LG Electronics, Inc. ^^^^^^^^^^^^^^^^^^^^
Allen Akin
In article <321C21...@mmedia.isl.goldstar.co.kr>,
Lee Byung Uk <bu...@mmedia.isl.goldstar.co.kr> wrote:
| ... That means to use full functions
| of specific graphic card, the card vendor must supply according
That's correct; a driver is required to accelerate OpenGL for a
particular card.
| .... And I think there is only few
| vendors who is gonna support opengl.
Actually, I suspect most vendors support OpenGL. The cards based on
3DLabs' GLiNT and Permedia chips support OpenGL, as do cards from S3
(Virge/VX), Dynamic Pictures, AccelGraphics, Intergraph, Matrox,
Lockheed-Martin, Evans and Sutherland, Oki, and others that I can't
remember at the moment. You could check the PC 3D Graphics
Accelerators FAQ for more information. Its URL is
http://www.cs.columbia.edu/~bm/3dcards/3d-cards1.html
Allen
Juergen Fechter
ak...@tuolumne.asd.sgi.com (Allen Akin) writes:
Is the new fast OpenGL version for NT the same as OpenGL 1.1.
or another one.
And why is the performance so good, - because it use DirectX-calls?
I have in mind, that Microsoft said that a new version will
make use of the DirectX calls.
And if not, when will there be a faster version of OpenGL for lowcost
SGI-machines (Indy) available.
Juergen
>In article <4vatd3$5...@darkstar.ucsc.edu>,
>Duane Strong <dst...@cats.ucsc.edu> wrote:
>| ... Direct3D emphasizes speed
>| over precision, whereas OpenGL will have perfectly meshing polygons
>| and a richer API at the expense of rendering speed.
>At SIGGRAPH SGI demonstrated a version of OpenGL with performance
>that's comparable to Direct3D; even faster than Direct3D in some
>cases. When that's released (current plans call for mid-September)
>there shouldn't be any performance reasons to prefer one of the APIs
>over the other.
>Allen
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Juergen Fechter | Universitaet Tuebingen, WSI/GRIS |
| Office: [+49/0] (7071) 29-75464 | Auf der Morgenstelle 10, C9 |
| Fax: [+49/0] (7071) 29-5466 | D-72076 Tuebingen, Germany |
Stephen H. Wright
In article <4vb2j9$i...@fido.asd.sgi.com>, ak...@tuolumne.asd.sgi.com says...
>
>In article <4vatd3$5...@darkstar.ucsc.edu>,
>Duane Strong <dst...@cats.ucsc.edu> wrote:
>| ... Direct3D emphasizes speed
>| over precision, whereas OpenGL will have perfectly meshing polygons
>| and a richer API at the expense of rendering speed.
>
>At SIGGRAPH SGI demonstrated a version of OpenGL with performance
>that's comparable to Direct3D; even faster than Direct3D in some
>cases. When that's released (current plans call for mid-September)
>there shouldn't be any performance reasons to prefer one of the APIs
>over the other.
>
>Allen
Allen et al. -
Just to be clear, SGI announced CosmoGL, a new software-only OpenGL PC
implementation with a few extensions to support a fast "ramp-mode" rendering
path that competes with the fast Direct3D ramp mode rasterizer. This is,
vis-a-vis Direct3D, a dead-end for a number of reasons:
1) Most new PC boards support 16-bpp RGB pixel formats; the days of color-index
mode rendering into 8-bpp palletted pixel formats on PC's are waning. The
PC'97 specification actually *requires* 16-bpp except for small LCD displays.
2) It doesn't keep pace with CPU developments. For example, Microsoft has
already announced an MMX D3D driver. The parallel arithmetic capabilities of
the MMX instruction set make it possible to perform RGB software rasterization
as fast or faster than ramp-mode rasterization on a traditional Pentium.
3) It doesn't keep pace with hardware acceleration developments. Dozens of
vendors are supplying commodity 3D chips and boards to the PC market today, and
they're virtually all providing D3D and/or Microsoft OpenGL driver support. SGI
can not successfully evangelize that industry with a new 3D driver model to
support their implementation.
Vis-a-vis Microsoft OpenGL, I am extremely concerned that, in an effort to
establish OpenGL as a credible games 3D API, SGI may actually undercut OpenGL's
momentum in the PC market.
1) The announcement contributes to the misperception that Microsoft has a
poorly-performing implementation and that SGI had to jump in to solve this
problem. In fact, Microsoft's new 1.1 implementation is 2-4x faster than the
previous release, and we believe it's the fastest software implementation
available. SGI has said, as of last week, that they hadn't yet run any
SPEC/OPC viewperf benchmarks on CosmoGL; all we actually know is that their
ramp-mode fast-path is comparable to Direct3D.
2) It's a step backwards in that it's an OpenGL 1.0 implementation at a time
when we're urging ISV's to begin using the OpenGL 1.1 API. As Template
Graphics just posted, the 1.1 extensions (together with general performance
enhancements) are enabling 10-15x performance improvements in their Open
Inventor implementation. If their 1.1-based product runs at all on a 1.0
implementation, it will do so at tremendous performance penalties.
3) There is no hardware support story (just as with Direct3D). We successfully
launched a new OpenGL driver model for Windows last June, the "mini-client
driver model", which we believe enables competitive OpenGL support for the 3D
board industry. Even if CosmoGL were faster than Microsoft OpenGL when running
in software (which we doubt), it will not be faster than Microsoft OpenGL
running on the flood of cheap 3D hardware.
4) There are unresolved issues around how CosmoGL coexists with Microsoft
OpenGL on Windows platforms. For example, it would be unacceptable for a naive
user with a hardware accelerator to install an SGI 3D app from the web,
unknowingly pick up CosmoGL as part of this process, and be stuck with
software-rendering performance. It would be even worse if that resulted in
breaking hardware acceleration support for OpenGL-based applications.
Finally, I want to come back to the performance/precision trade-off issue,
since that's what started this thread. Leaving everything else aside, if SGI
did in fact deliver a floating-point, sub-pixel-precise, software ramp mode
renderer that was faster than the Direct3D fixed-point, pixel-precise, software
ramp mode renderer, that only means that there are still some optimizations
that could be made on the Direct3D side. It is conceivable that the pay-off
for these short-cuts is not significant (particularly for large triangle
benchmarks which are raster-bound), but it should be clear that, other things
being equal, you can get more performance by reducing precision.
Steve Wright
OpenGL Program Manager
Microsoft Corporation
Allen Akin
In article <4vt29j$v...@news.microsoft.com>,
Stephen H. Wright <swr...@microsoft.com> wrote:
|
| Just to be clear, SGI announced CosmoGL, a new software-only OpenGL PC
| implementation with a few extensions to support a fast "ramp-mode" rendering
That's partly correct. Cosmo OpenGL (briefly known as CosmoGL)
optimizes RGB as well as color-index (``ramp mode'') rendering. It
does have new extensions for color-index textures and color-index
materials. Perhaps more importantly, it also has extensions for fast
culling and for caching transformed vertices that are useful in both
RGB and color-index modes. The goal is to provide a fast
software-only implementation of OpenGL for many applications; it goes
well beyond D3D ramp-mode.
| ... This is,
| vis-a-vis Direct3D, a dead-end for a number of reasons:
It looks like you didn't know that Cosmo OpenGL provides much more
than D3D ramp mode; you might not have raised these particular
objections if you had. But I'll say a few words about each, just in
case.
| 1) Most new PC boards support 16-bpp RGB pixel formats; the days of color-index
| mode rendering into 8-bpp palletted pixel formats on PC's are waning. ...
I certainly hope so! I'm no fan of color-index mode.
However, a very large number of PCs in the installed base have
color-index displays, so performance for the color-index case is
interesting to a lot of people. It may be worth noting that
workstations have supported RGB displays for a long time, but
color-index is still used heavily in some applications. That's why
it's still a part of OpenGL.
| 2) It doesn't keep pace with CPU developments. [Specifically MMX]
There are tens of millions of machines in the field that don't support
MMX, so good performance for machines without MMX is interesting to a
lot of people. I agree that MMX is important for new machines.
| 3) It doesn't keep pace with hardware acceleration developments. Dozens of
| vendors are supplying commodity 3D chips and boards to the PC market today, and
| they're virtually all providing D3D and/or Microsoft OpenGL driver support. SGI
| can not successfully evangelize that industry with a new 3D driver model to
| support their implementation.
SGI's interest in this matter is ensuring that fast OpenGL
implementations are available on a wide range of PCs. Frankly, we'd
rather not have to develop and maintain OpenGL for PCs, so if
chip/board vendors can use Microsoft's implementation, and it's fast,
that's fine.
One of the technical problems with Microsoft's approach is that MS
encourages vendors to build layered implementations of OpenGL. Today
that means using the mini-client-driver (MCD), though Microsoft has
stated frequently that its plan is to layer OpenGL on D3D or the D3D
HAL. For hardware accelerators, these are all low-performance
solutions, because they add data buffering and reformatting steps as
well as state-management overhead. Only the installable client driver
(ICD) model makes sense for high-performance implementations. Several
graphics chip/board vendors already use Microsoft's ICD, and it would
be nice to see that solution supported more effectively. A fast
geometry-processing path, such as the one in Cosmo OpenGL, would help
vendors use Microsoft's ICD and wouldn't require SGI to promote a new
driver model.
| Vis-a-vis Microsoft OpenGL, I am extremely concerned that, in an effort to
| establish OpenGL as a credible games 3D API, SGI may actually undercut OpenGL's
| momentum in the PC market.
My personal opinion is that neither D3D or OpenGL has been proven as a
credible games API. There's significant doubt that any
general-purpose API is the right answer on machines without graphics
acceleration. However, both APIs provide device-independent access to
accelerator hardware, so in the long run both may be used by games on
accelerated machines.
| 1) The announcement contributes to the misperception that Microsoft has a
| poorly-performing implementation and that SGI had to jump in to solve this
| problem. ...
See the above comments about driver models.
See also Microsoft's own documentation and marketing material.
Quoting from the DirectX2 SDK Direct3D Overview, for example:
Direct3D is Microsoft's high-speed 3D software solution.
[Chapter 5, part A, page 4]
OpenGL is a precise 3D technology used for high-end CAD/CAM,
modeling and animation, simulations, scientific visualization,
and other exacting 3D-image rendering. [Chapter 5, part A,
page 6]
Can you blame anyone for concluding that Microsoft's OpenGL is the
wrong choice for performance-conscious developers?
| ... In fact, Microsoft's new 1.1 implementation is 2-4x faster than the
| previous release, and we believe it's the fastest software implementation
| available. ...
But not fast enough to compete with Direct3D?
I don't mean to be snide; this is a serious issue. Developers are
trying to choose an API, and they need comparisons between APIs, not
comparisons between current and previous releases of the same API.
Granted, there are lots of difficult problems to be solved before
meaningful comparisons can be made. That's one of the main reasons
why the Cosmo OpenGL demonstrations at SIGGRAPH were just simple ports
of existing D3D programs.
| ... SGI has said, as of last week, that they hadn't yet run any
| SPEC/OPC viewperf benchmarks on CosmoGL...
That's right. We still have some work to do. And even when we're
ready for the first release, Cosmo OpenGL probably won't be as fast as
Microsoft's OpenGL for some operations. For example, it's unlikely
we'll spend much time tuning antialiased lines in order to get a
comparable score on the CDRS benchmark; for the sort of applications
we have in mind, triangle performance is more important.
| 2) It's a step backwards in that it's an OpenGL 1.0 implementation...
Cosmo OpenGL is an OpenGL 1.1 implementation.
For compatibility, it also includes the extensions in Microsoft's
OpenGL implementation.
| 3) There is no hardware support story...
See above comments about driver models.
| 4) There are unresolved issues around how CosmoGL coexists with Microsoft
| OpenGL on Windows platforms....
Yes, this is a real concern for me, too. The best way to solve it is
to have Microsoft OpenGL blow the doors off all the alternatives,
including Cosmo OpenGL and Direct3D; then there won't be any need for
Cosmo OpenGL. We'd be interested in working with you to make this
happen, but it's important to move quickly; a lot of people are
waiting for a high-performance OpenGL on Windows95.
| Finally, I want to come back to the performance/precision trade-off issue,
| since that's what started this thread. Leaving everything else aside, if SGI
| did in fact deliver a floating-point, sub-pixel-precise, software ramp mode
| renderer that was faster than the Direct3D fixed-point, pixel-precise, software
| ramp mode renderer, that only means that there are still some optimizations
| that could be made on the Direct3D side....
Hmm. It's risky to make categorical statements like that. For
example, careful overlap of floating-point and integer code can yield
much better performance than either pure floating-point or pure
integer code. Sometimes extra precision is free.
More food for thought: Have you looked at the OpenGL conformance
tests? An implementation can be conformant without offering subpixel
precision, as long as it doesn't cause cracks or overlaps between
adjacent polygons. It happens that Cosmo OpenGL does provide subpixel
precision for vertex positions, but if there were a really substantial
performance benefit to be gained from relaxing that guarantee, it
would be OK to do so. (I've noticed that D3D people often overstate
the requirements for OpenGL conformance.)
Again, what SGI wants to do with Cosmo OpenGL is guarantee the wide
availability of first-rate OpenGL implementations on Windows 95, for
machines with and without graphics accelerators. It would be fine if
those implementations come from Microsoft rather than SGI. John
Schimpf and I will get back to you offline.
Allen
Hock San Lee
In article <4vtf5p$8...@fido.asd.sgi.com>, ak...@tuolumne.asd.sgi.com
says...
>
>That's partly correct. Cosmo OpenGL (briefly known as CosmoGL)
>optimizes RGB as well as color-index (``ramp mode'') rendering. It
>does have new extensions for color-index textures and color-index
>materials. Perhaps more importantly, it also has extensions for fast
>culling and for caching transformed vertices that are useful in both
>RGB and color-index modes. The goal is to provide a fast
>software-only implementation of OpenGL for many applications; it goes
>well beyond D3D ramp-mode.
It is easy for SGI to claim that Cosmo OpenGL optimizes this and that, and
that it will be faster than other implementations. For now, if you are
interested in public benchmark results, check out
http://www.specbench.org/gpc/opc.static/index.html. If you have an Indy,
I encourage you to download viewperf and run its results against the
published Microsoft software OpenGL 1.1 implementation. FYI, SGI has not
been willing to share Indy viewperf results publicly.
As for Cosmo OpenGL extensions, you need to be aware of some caveats:
1. Extensions may not be supported by hardware implementations.
2. Some extension may have serious memory footprint. The amount of memory
required to cache tens of thousands of transformed vertices cannot be
ignored on existing PCs.
>There are tens of millions of machines in the field that don't support
>MMX, so good performance for machines without MMX is interesting to a
>lot of people. I agree that MMX is important for new machines.
Do you have a release plan for MMX support?
>One of the technical problems with Microsoft's approach is that MS
>encourages vendors to build layered implementations of OpenGL. Today
>that means using the mini-client-driver (MCD), though Microsoft has
>stated frequently that its plan is to layer OpenGL on D3D or the D3D
>HAL. For hardware accelerators, these are all low-performance
>solutions, because they add data buffering and reformatting steps as
>well as state-management overhead.
We promote MCD for rasterization hardware. The claim about its
sub-optimal approach/performance is completely baseless. The target of
MCD (<$500 graphics board) is commodity 3D hardware in the same class as
SGI entry level Indy. It is not targeted at hardware with geometry
engines. Based on our measurements, a P6/200 with Matrox Millennium can
process over 100K 50-pixel, z buffered, shaded triangles. This number
compares favorably against some SGI entry systems.
>Only the installable client driver
>(ICD) model makes sense for high-performance implementations. Several
>graphics chip/board vendors already use Microsoft's ICD, and it would
>be nice to see that solution supported more effectively. A fast
>geometry-processing path, such as the one in Cosmo OpenGL, would help
>vendors use Microsoft's ICD and wouldn't require SGI to promote a new
>driver model.
Based on our experience, a well written MCD can outperform an average ICD.
The investment on a good ICD implementation is so huge that it presents a
significant barrier to entry for most commodity hardware vendors.
Microsoft invests in MCD technology to make high performance OpenGL
hardware available to commodity PC. For instance, the sample MCD has
about ~10K lines of optimized code provided by Microsoft while the sample
ICD has about 75K lines of un-optimized code provided by SGI. The next
version of MCD will target geometry hardware. The development time for a
well written MCD is generally fewer than 6 months as compared to many
years of development required to write a good ICD.
>Cosmo OpenGL is an OpenGL 1.1 implementation.
>
>For compatibility, it also includes the extensions in Microsoft's
>OpenGL implementation.
I am pretty sure that it does not support the Microsoft's outline font
extension. So the above statement is incorrect.
>Yes, this is a real concern for me, too. The best way to solve it is
>to have Microsoft OpenGL blow the doors off all the alternatives,
>including Cosmo OpenGL and Direct3D; then there won't be any need for
>Cosmo OpenGL. We'd be interested in working with you to make this
>happen, but it's important to move quickly; a lot of people are
>waiting for a high-performance OpenGL on Windows95.
We'd rather not have to respond to many of your public claims. These
unsubstantaited (Cosmo OpenGL) claims only confuse developers.
>Again, what SGI wants to do with Cosmo OpenGL is guarantee the wide
>availability of first-rate OpenGL implementations on Windows 95, for
>machines with and without graphics accelerators. It would be fine if
>those implementations come from Microsoft rather than SGI. John
>Schimpf and I will get back to you offline.
We already have first-rate OpenGL software/hardware implementations on our
platform based on current benchmarks. I am looking forward to seeing the
benchmark results of this "first-rate" Cosmo OpenGL.
Hock San Lee
Microsoft
Stephen H. Wright
Allen et al. -
In article <4vtf5p$8...@fido.asd.sgi.com>, ak...@tuolumne.asd.sgi.com says...
>
>In article <4vt29j$v...@news.microsoft.com>,
>Stephen H. Wright <swr...@microsoft.com> wrote:
>|
>| Just to be clear, SGI announced CosmoGL, a new software-only OpenGL PC
>| implementation with a few extensions to support a fast "ramp-mode" rendering
>| path that competes with the fast Direct3D ramp mode rasterizer. ...
>
>That's partly correct. Cosmo OpenGL (briefly known as CosmoGL)
>optimizes RGB as well as color-index (``ramp mode'') rendering. It
>does have new extensions for color-index textures and color-index
>materials. Perhaps more importantly, it also has extensions for fast
>culling and for caching transformed vertices that are useful in both
>RGB and color-index modes. The goal is to provide a fast
>software-only implementation of OpenGL for many applications; it goes
>well beyond D3D ramp-mode.
>
I think one problem here is that "optimized" is a relative term. SGI has told
me that the focus has been on extensions for ramp mode and relatively few
selected fast paths to support selected applications. I question, based on
that, that any significant work has yet been done to the RGB paths.
>| ... This is,
>| vis-a-vis Direct3D, a dead-end for a number of reasons:
>
>It looks like you didn't know that Cosmo OpenGL provides much more
>than D3D ramp mode; you might not have raised these particular
>objections if you had. But I'll say a few words about each, just in
>case.
>
>| 1) Most new PC boards support 16-bpp RGB pixel formats; the days of
color-index
>| mode rendering into 8-bpp palletted pixel formats on PC's are waning. ...
>
>I certainly hope so! I'm no fan of color-index mode.
>
>However, a very large number of PCs in the installed base have
>color-index displays, so performance for the color-index case is
>interesting to a lot of people. It may be worth noting that
>workstations have supported RGB displays for a long time, but
>color-index is still used heavily in some applications. That's why
>it's still a part of OpenGL.
>
My own experience in the workstation world (11 years with Apollo and HP) is
that the prolonged legacy support issues you describe are going to be much less
of an issue in the PC marketplace. A workstation user who had to justify a
$10-20K upgrade from an unaccelerated 8-plane color system to an accelerated
24-plane color system on a UNIX workstation would end up living with
unaccelerated 8-plane color graphics for a long time. The reality was that
many engineers worked with 8-plane systems because it was just too expensive to
give every desktop good RGB color. In the PC market today you can get a 16bpp
RGB upgrade for under $200, a 24bpp RGB upgrade for under $500, and excellent
3D acceleration for under $2500.
In the commodity arena, we expect a very rapid turnover away from 8bpp
graphics. In the professional 3D arena, our installed base is already on 24bpp
hardware.
The best argument I've heard for continuing to support ramp mode is that the
*high-end* PC boards with overlay planes will need 8bpp modes for rendering
into the overlay planes. It's not clear to me, thinking about this, that they
need ramp mode (as against 233 RGB), but in any case this high-end requirement
doesn't fit into the Cosmo space at all, since Cosmo's primary focus is on a
software implementation.
>| 2) It doesn't keep pace with CPU developments. [Specifically MMX]
>
>There are tens of millions of machines in the field that don't support
>MMX, so good performance for machines without MMX is interesting to a
>lot of people. I agree that MMX is important for new machines.
>
MMX was an example and I don't think you're appreciating the abstraction, so
I'll try to put it another way: Microsoft is in the business of providing
software for PC's and it has the processes, partnerships and infrastructure for
tracking IHV and CPU initiatives and responding to them aggressively. SGI isn't
in that business and lacks the structure to keep pace. As a technology
demonstration, Cosmo GL makes very interesting points about the appropriateness
of OpenGL for consumer 3D applications. As a product, it's a support,
marketing and developer relations burden for SGI.
>| 3) It doesn't keep pace with hardware acceleration developments. Dozens of
>| vendors are supplying commodity 3D chips and boards to the PC market today,
and
>| they're virtually all providing D3D and/or Microsoft OpenGL driver support.
SGI
>| can not successfully evangelize that industry with a new 3D driver model to
>| support their implementation.
>
>SGI's interest in this matter is ensuring that fast OpenGL
>implementations are available on a wide range of PCs. Frankly, we'd
>rather not have to develop and maintain OpenGL for PCs, so if
>chip/board vendors can use Microsoft's implementation, and it's fast,
>that's fine.
>
This gets back to what I just said; this is not a business SGI wants to be in.
Unfortunately, SGI is going to be pulled into this business, in spite of the
fact that chip/board vendors *do* use Microsoft's implementation, in spite of
the fact that it's fast in software, and in spite of the fact that it's faster
in hardware than SGI's own workstation implementations in the same price class.
(See
for the latest SPEC/OPC results.)
>One of the technical problems with Microsoft's approach is that MS
>encourages vendors to build layered implementations of OpenGL. Today
>that means using the mini-client-driver (MCD), though Microsoft has
>stated frequently that its plan is to layer OpenGL on D3D or the D3D
>HAL. For hardware accelerators, these are all low-performance
>solutions, because they add data buffering and reformatting steps as
>well as state-management overhead. Only the installable client driver
>(ICD) model makes sense for high-performance implementations. Several
>graphics chip/board vendors already use Microsoft's ICD, and it would
>be nice to see that solution supported more effectively. A fast
>geometry-processing path, such as the one in Cosmo OpenGL, would help
>vendors use Microsoft's ICD and wouldn't require SGI to promote a new
>driver model.
This is just wrong. When we held a public review of the MCD model in June --
for about 100 representatives of about 50 different IHV's -- we explained that
the D3D HAL layering would only make sense for 3D hardware almost exclusively
targetted at the consumer D3D market, and that IHV's anticipating some
professional 3D use should provide MCD drivers or ICD drivers. The overhead
issues you list are not an issue with either MCD or ICD drivers.
When it comes to ICD versus MCD, we are telling our IHV's to use ICD's only if
they have considerably geometry pipeline expertise and intellectual property,
and/or if they have implemented the geometry pipeline in hardware. Microsoft's
own software implementation has also been optimized for geometry processing,
and IHV's that use the MCD model automatically pick up the benefits of that
tuning. It's *not*, contrary to your assertion, helpful to ICD developers,
most of whom have already spent man-years tuning their front end.
Finally, one note on the rumors that 3DLabs may provide driver support for
Cosmo GL. Whether or not this is true, it's worth noting that 3DLabs already
provides Microsoft OpenGL ICD drivers for their hardware. There would be no
added value to having Cosmo GL with 3DLabs drivers on PC's.
>
>| Vis-a-vis Microsoft OpenGL, I am extremely concerned that, in an effort to
>| establish OpenGL as a credible games 3D API, SGI may actually undercut
OpenGL's
>| momentum in the PC market.
>
>My personal opinion is that neither D3D or OpenGL has been proven as a
>credible games API. There's significant doubt that any
>general-purpose API is the right answer on machines without graphics
>acceleration. However, both APIs provide device-independent access to
>accelerator hardware, so in the long run both may be used by games on
>accelerated machines.
>
>| 1) The announcement contributes to the misperception that Microsoft has a
>| poorly-performing implementation and that SGI had to jump in to solve this
>| problem. ...
>
>See the above comments about driver models.
>
Aside from the fact that those comments were technically inaccurate, this
response evades the point. In the context of a software implementation, any
issues you may have with our driver models are irrelevant. In the context of
support for hardware acceleration, even if our models were flawed, they're
better than not having any hardware support story at all.
>See also Microsoft's own documentation and marketing material.
>Quoting from the DirectX2 SDK Direct3D Overview, for example:
>
> Direct3D is Microsoft's high-speed 3D software solution.
> [Chapter 5, part A, page 4]
>
> OpenGL is a precise 3D technology used for high-end CAD/CAM,
> modeling and animation, simulations, scientific visualization,
> and other exacting 3D-image rendering. [Chapter 5, part A,
> page 6]
>
>Can you blame anyone for concluding that Microsoft's OpenGL is the
>wrong choice for performance-conscious developers?
>
If Microsoft is offering confusing or inaccurate positioning materials, we need
to fix them, and that's one of my jobs. I'd hate to think that this is an
invitation for SGI to reinforce the misperceptions I'm trying to deal with.
>| ... In fact, Microsoft's new 1.1 implementation is 2-4x faster than
the
>| previous release, and we believe it's the fastest software implementation
>| available. ...
>
>But not fast enough to compete with Direct3D?
In the RGB rendering arena, we are fast enough for some consumer and games
apps. It depends a lot on the scene content. The OpenGL fill rate is slightly
faster than D3D's (we don't know exactly why), but the D3D triangle setup time
is a lot less than the OpenGL triangle setup time (this is where not doing
subpixel precision is a big win.) So scenes with large triangles would render
about as fast; scenes with small triangles would lag.
However, RGB mode is substantially slower than Direct3D ramp mode. We have
*not* done a lot of work with OpenGL color index mode. My sense is that if
we did, we would end up with a relatively similar situation vis-a-vis Direct3D
ramp mode.
I also suspect that this is the case with the Cosmo GL implementation. Most of
the sample D3D apps are fill-rate gated, so that it's relatively easy to
implement an OpenGL renderer that runs competitively on those sample programs.
Real game applications tend to have smaller triangles and setup rate begins to
gate the rendering. I would be surprised if a any conformant OpenGL
implementation could approach the D3D ramp mode setup rate.
Having said all this, I have to add that Microsoft's OpenGL is not trying to
"compete" with Direct3D in that sense. We really believe that it's appropriate
to provide different API's for different markets. Which segues right into:
>I don't mean to be snide; this is a serious issue. Developers are
>trying to choose an API, and they need comparisons between APIs, not
What we've been saying is: use Direct3D for games and consumer-oriented
software; use OpenGL for professional 3D software; use either one for business
or productivity 3D software (e.g., VRML viewers). If anyone is getting a
different message, please let me know so that I can try to fix that.
>comparisons between current and previous releases of the same API.
Because of the misperception that Microsoft's OpenGL software implementation is
slow, we've needed to spend a lot of bandwidth addressing that comparison.
(And now, unfortunately, I'm going to have to start spending time addressing
the comparison between Microsoft's OpenGL and SGI's Cosmo GL.)
>Granted, there are lots of difficult problems to be solved before
>meaningful comparisons can be made. That's one of the main reasons
>why the Cosmo OpenGL demonstrations at SIGGRAPH were just simple ports
>of existing D3D programs.
>
>| ... SGI has said, as of last week, that they hadn't yet run any
>| SPEC/OPC viewperf benchmarks on CosmoGL...
>
>That's right. We still have some work to do. And even when we're
>ready for the first release, Cosmo OpenGL probably won't be as fast as
>Microsoft's OpenGL for some operations. For example, it's unlikely
>we'll spend much time tuning antialiased lines in order to get a
>comparable score on the CDRS benchmark; for the sort of applications
>we have in mind, triangle performance is more important.
>
Can the OPC interest you in producing a viewperf dataset for that sort of
application?
>| 2) It's a step backwards in that it's an OpenGL 1.0 implementation...
>
>Cosmo OpenGL is an OpenGL 1.1 implementation.
>
>For compatibility, it also includes the extensions in Microsoft's
>OpenGL implementation.
>
Well, that's news, and good news. (Will you keep pace with our future
extensions? ;-) )
>| 3) There is no hardware support story...
>
>See above comments about driver models.
>
This is that evasion again. SGI doesn't have a story and Microsoft does. Even
if it wasn't as good a story as SGI would like to see -- and I believe it's a
lot better than you understood it to be -- it's a lot better story than SGI's.
>| 4) There are unresolved issues around how CosmoGL coexists with Microsoft
>| OpenGL on Windows platforms....
>
>Yes, this is a real concern for me, too. The best way to solve it is
>to have Microsoft OpenGL blow the doors off all the alternatives,
>including Cosmo OpenGL and Direct3D; then there won't be any need for
>Cosmo OpenGL. We'd be interested in working with you to make this
>happen, but it's important to move quickly; a lot of people are
>waiting for a high-performance OpenGL on Windows95.
>
There's no point in waiting. The libraries for OpenGL 1.1 on Windows95 are
freely available from:
ftp://ftp.microsoft.com/Softlib/MSLFILES
get Opengl95.exe
These libraries have been distributed to all our major OEM's and will start
appearing on new machines with pre-installed Windows95 this fall. These
libraries have all of our performance tuning work. They support drivers for
hardware acceleration from IHV's such as 3DLabs and AccelGraphics that have
written drivers for Windows95.
Our goal is not to "blow the doors off of Direct3D", however, and if that's
SGI's standard for whether or not to make a product of Cosmo GL, SGI will have
to solve the coexistence issues some other way. If SGI wants a version of
OpenGL which will compete with Direct3D, that's their business. My concern,
again, is that they are, in *many* ways, undermining Microsoft's own OpenGL
program in the process.
>| Finally, I want to come back to the performance/precision trade-off issue,
>| since that's what started this thread. Leaving everything else aside, if
SGI
>| did in fact deliver a floating-point, sub-pixel-precise, software ramp mode
>| renderer that was faster than the Direct3D fixed-point, pixel-precise,
software
>| ramp mode renderer, that only means that there are still some optimizations
>| that could be made on the Direct3D side....
>
>Hmm. It's risky to make categorical statements like that. For
>example, careful overlap of floating-point and integer code can yield
>much better performance than either pure floating-point or pure
>integer code. Sometimes extra precision is free.
>
Well then, not to be categorical, I can tell you this much: one of our best
engineers has very carefully hand-crafted triangle setup Pentium assembler code
for our OpenGL pipeline. The Direct3D triangle setup, which was also very
carefully crafted by another top-knotch engineer, is substantially faster.
There is simply less vertex state to compute, less to put over the bus, and
what there is to compute is easier to compute given the precision trade-offs.
>More food for thought: Have you looked at the OpenGL conformance
>tests? An implementation can be conformant without offering subpixel
>precision, as long as it doesn't cause cracks or overlaps between
>adjacent polygons. It happens that Cosmo OpenGL does provide subpixel
>precision for vertex positions, but if there were a really substantial
>performance benefit to be gained from relaxing that guarantee, it
>would be OK to do so. (I've noticed that D3D people often overstate
>the requirements for OpenGL conformance.)
>
This is an interesting point, but it raises some hairy technical and marketing
issues:
1) Do any of us -- OpenGL licensees, ISV's, end-users, IHV's -- really want to
promote a low-precision mode for OpenGL to compete with other API's like
Direct3D or RenderWare?
2) Does this direction make any sense if pervasive 3D hardware is going to make
subpixel correct rendering available without the software performance hit? I
personally would rather push for higher quality to take best advantage of
hardware.
2) Re cracking: all OpenGL hardware for the PC platform supports subpixel
precision because we've evangelized that for over two years. Rendering which
goes partly down the software and partly down the hardware paths will probably
end up with cracks if the software doesn't operate at the same level as the
hardware.
>Again, what SGI wants to do with Cosmo OpenGL is guarantee the wide
>availability of first-rate OpenGL implementations on Windows 95, for
>machines with and without graphics accelerators. It would be fine if
>those implementations come from Microsoft rather than SGI. John
>Schimpf and I will get back to you offline.
>
>Allen
I already had expected to discuss this offline with John, and I look forward
to our getting together again, but I also don't want to leave this usegroup
without a clear sense of why we think this is a bad idea that end-users should
steer clear from, and why we think our implementation is a lot stronger than
you give us credit for having.
At the same time, I do want to say I understand why SGI has invested in this
effort. We have a complicated business relationship with SGI, working together
in some areas and competing intensely in others, and I don't want this exchange
to come across to readers of the usegroup as a manic struggle.
The bottom line for us is that we have and will continue to offer an
industry-leading OpenGL implementation. If CosmoGL turns out to have even
better caching and culling capabilities than those we added, for example, we'll
be glad to take a look and try adding them to our pipeline. We're all in favor
of working together to make OpenGL better. But our goal there will not be to
compete with Direct3D; nor will our efforts to improve Direct3D be directed at
competing with OpenGL.
Allen Akin
In article <4vvf27$u...@news.microsoft.com>,
Hock San Lee <ho...@microsoft.com> wrote:
|
| It is easy for SGI to claim that Cosmo OpenGL optimizes this and that, and
It's not our goal to make Microsoft's OpenGL look bad. We're just
interested in having an OpenGL that's as fast or faster than Direct3D,
because higher-level software needs that. If Microsoft provides such
an OpenGL implementation, that's fine by us; then there would be no
need for Cosmo OpenGL.
If you have benchmark results that show that your latest release of
OpenGL is as fast or faster than Direct3D, please let us know!
| ...
| 2. Some extension may have serious memory footprint. The amount of memory
| required to cache tens of thousands of transformed vertices cannot be
| ignored on existing PCs.
Presumably the same concern applies to execute buffers in Direct3D.
From reading your comment, people might assume that all the
performance enhancement extensions in Cosmo OpenGL require caching of
huge numbers of vertices. This isn't true, though.
| >There are tens of millions of machines in the field that don't support
| >MMX, so good performance for machines without MMX is interesting to a
| >lot of people. I agree that MMX is important for new machines.
|
| Do you have a release plan for MMX support?
It's third priority, following support for existing machines and
machines with accelerators. If your previous statements that
accelerators are becoming ubiquitous are correct, that should be the
right order.
| We promote MCD for rasterization hardware. The claim about its
| sub-optimal approach/performance is completely baseless. ...
Adding a new layer of function calls and forcing data to be batched
and reformatted in a way that isn't guaranteed to match the hardware
usually results in suboptimal performance. I think most people would
agree that the concern isn't ``completely baseless.''
This is not to say that MCD is a bad thing; it provides an easy,
cost-effective solution for vendors of rasterization-only hardware who
don't need peak performance for OpenGL. It's also likely to be much
faster than layering OpenGL on D3D. It's just not the right solution
for vendors who want absolutely maximum performance, whether or not
their cards include geometry processors.
| Based on our experience, a well written MCD can outperform an average ICD.
I guess it's usually true that well-written software can outperform
average software. :-)
| The investment on a good ICD implementation is so huge that it presents a
| significant barrier to entry for most commodity hardware vendors.
Yes, this is true.
One way to reduce the implementation cost is to create a new, simpler
device interface, as you've done with MCD. Another way is to provide
a much better baseline implementation for ICD. The latter approach
offers the potential for better performance and more support for
innovative features on a wider range of hardware.
| >For compatibility, it also includes the extensions in Microsoft's
| >OpenGL implementation.
|
| I am pretty sure that it does not support the Microsoft's outline font
| extension. So the above statement is incorrect.
Well, so far you and Steve have made incorrect statements about Cosmo
OpenGL's optimizations for RGB rendering, about its conformance with
OpenGL 1.1, and about its need for a new device driver model. Could
you at least ask the people doing the work whether it includes that
extension before reaching a conclusion? I'll be frank; I'm just
kibitzing on this project, and I don't know the answer.
| We'd rather not have to respond to many of your public claims...
I'm really puzzled as to why Steve posted his previous message
publically rather than conducting a discussion offline. Because the
original posting was public, I replied in public. But as I said in my
previous message, we'd be happy to discuss things with you face to
face. All we're looking for is an OpenGL implementation that's as
fast as D3D, and widely available.
Regarding performance claims, what I've said is that we've
demonstrated Cosmo OpenGL applications that are straightforward ports
of Direct3D Immediate Mode applications, using same-sized textures,
windows, etc. to make the comparison as fair as possible. Anyone who
attended SIGGRAPH could see for themselves that the Cosmo OpenGL
performance was as good as or slightly better than the Direct3D
performance. This is something that I've claimed is possible for a
long time, based on technical considerations alone. At SIGGRAPH we
just showed the first existence proof.
| ... These
| unsubstantaited (Cosmo OpenGL) claims only confuse developers.
The mispositioning of Direct3D and OpenGL (such as in the DirectX
documentation I quoted in my previous note) has already confused
developers. Cosmo OpenGL is helping to correct that.
| We already have first-rate OpenGL software/hardware implementations on our
| platform based on current benchmarks.
Your Viewperf numbers are dramatically better than previous releases,
and it's clear that you've put a lot of work into the code. I don't
intend to disparage that. If your code is as fast or faster than
Direct3D, then just let us know.
I'm going on vacation for ten days, so if you post a followup, I'll be
unable to reply. You can get in touch with John Schimpf or Kurt
Akeley, though.
Allen
Allen Akin
In article <4vvlc1$t...@news.microsoft.com>,
Stephen H. Wright <swr...@microsoft.com> wrote:
|
| I think one problem here is that "optimized" is a relative term. SGI has told
| me that the focus has been on extensions for ramp mode and relatively few
| selected fast paths to support selected applications. I question, based on
| that, that any significant work has yet been done to the RGB paths.
The geometry-path work benefits both RGB and color-index rendering.
Considerable work has also been expended on RGB rasterization.
| [with regard to 8-bit color index rendering:]
| My own experience in the workstation world (11 years with Apollo and HP) is
| that the prolonged legacy support issues you describe are going to be much less
| of an issue in the PC marketplace...
I hope you're correct.
One counter-trend that I've noticed is that some people building
applications with D3D are using ramp mode in order to maximize
performance. Since this affects the applications in more ways than
just changing pixel depth, it may create a new set of legacy support
issues.
| The best argument I've heard for continuing to support ramp mode is that the
| *high-end* PC boards with overlay planes will need 8bpp modes for rendering
| into the overlay planes. It's not clear to me, thinking about this, that they
| need ramp mode (as against 233 RGB)...
Some use colormap animation, unfortunately. With luck, fewer will do
so in the PC space.
| ... Microsoft is in the business of providing
| software for PC's and it has the processes, partnerships and infrastructure for
| tracking IHV and CPU initiatives and responding to them aggressively. SGI isn't
| in that business and lacks the structure to keep pace. As a technology
| demonstration, Cosmo GL makes very interesting points about the appropriateness
| of OpenGL for consumer 3D applications. As a product, it's a support,
| marketing and developer relations burden for SGI.
Fully understood, believe me. :-)
| Unfortunately, SGI is going to be pulled into this business, ...
It seems necessary, if we're to ensure that a competitive OpenGL is
available. If there's a viable alternative, let's talk about it.
| ... in spite of
| the fact that it's fast in software, ...
I realize you're in a difficult position with respect to Direct3D, but
for people who are choosing an API, ``fast in software'' isn't a
strong enough claim. ``Fast relative to Direct3D'' is the interesting
issue.
| .... and in spite of the fact that it's faster
| in hardware than SGI's own workstation implementations in the same price class.
This is quite debatable, as you know. But rather than get into that
debate, I'll simply ask: How much faster could it be?
| ... When we held a public review of the MCD model in June --
| for about 100 representatives of about 50 different IHV's -- we explained that
| the D3D HAL layering would only make sense for 3D hardware almost exclusively
| targetted at the consumer D3D market, and that IHV's anticipating some
| professional 3D use should provide MCD drivers or ICD drivers. ...
You might want to update your documentation and web pages to reflect
this new position.
| ... The overhead
| issues you list are not an issue with either MCD or ICD drivers.
I agree that they're not an issue for ICD drivers, and that's
precisely the point I wanted to make in my previous note.
As for MCD, implementing any interface layer adds overhead to
low-level APIs. Could you explain how you completely avoid the cost
of data reformatting and driver-layer procedure calls in the MCD case?
| ... Microsoft's
| own software implementation has also been optimized for geometry processing,
| and IHV's that use the MCD model automatically pick up the benefits of that
| tuning. It's *not*, contrary to your assertion, helpful to ICD developers,
| most of whom have already spent man-years tuning their front end.
Not sure I follow you here. If developers are interested in using the
ICD model for a new accelerator, why is it not helpful to provide them
with optimized geometry processing code?
| >| 1) The announcement contributes to the misperception that Microsoft has a
| >| poorly-performing implementation and that SGI had to jump in to solve this
| >| problem. ...
| >
| >See the above comments about driver models.
| >
|
| Aside from the fact that those comments were technically inaccurate, ...
You haven't made your technical case yet, so I'll stand by the
original comments. Adding a mandatory interface layer adds overhead.
This can be substantial in a high-performance machine.
| If Microsoft is offering confusing or inaccurate positioning materials, we need
| to fix them, and that's one of my jobs. I'd hate to think that this is an
| invitation for SGI to reinforce the misperceptions I'm trying to deal with.
Eliminating the mis-positioning of OpenGL would make everyones' lives
easier, I think.
| ... I would be surprised if a any conformant OpenGL
| implementation could approach the D3D ramp mode setup rate.
Why? I've been hearing this sort of comment for the last year or
more, but never been given a convincing explanation. All the
technical considerations of which I'm aware argue against it.
| >I don't mean to be snide; this is a serious issue. Developers are
| >trying to choose an API, and they need comparisons between APIs, not
|
| What we've been saying is: use Direct3D for games and consumer-oriented
| software; use OpenGL for professional 3D software; use either one for business
| or productivity 3D software (e.g., VRML viewers). If anyone is getting a
| different message, please let me know so that I can try to fix that.
If it's possible to build an OpenGL that approaches Direct3D in
performance and in ease of hardware support, it would seem that the
main reasons for this distinction are business issues, particularly
API control. That's the underlying concern you might eventually have
to address.
| > ... For example, it's unlikely
| >we'll spend much time tuning antialiased lines in order to get a
| >comparable score on the CDRS benchmark; for the sort of applications
| >we have in mind, triangle performance is more important.
| >
|
| Can the OPC interest you in producing a viewperf dataset for that sort of
| application?
I hope so. I'm the wrong person to ask, though.
| ...(Will you keep pace with our future
| extensions? ;-) )
If Cosmo OpenGL is widely used, you might have to keep pace with ours. :-)
| This is that evasion again. SGI doesn't have a story and Microsoft does. Even
| if it wasn't as good a story as SGI would like to see -- and I believe it's a
| lot better than you understood it to be -- it's a lot better story than SGI's.
Vendors who want high-performance OpenGL will be able to build ICDs
based on Cosmo OpenGL code, if they so choose. (Cosmo OpenGL can make
that process much easier than it is today.) Those who don't care about
high-performance OpenGL can use MCD or even the D3D HAL
implementation. The Cosmo OpenGL ``product'' only needs to run on
software-only systems. Seems to me that SGI's ``story'' is pretty
simple, and plays together with Microsoft's.
| Our goal is not to "blow the doors off of Direct3D", however, and if that's
| SGI's standard for whether or not to make a product of Cosmo GL, SGI will have
| to solve the coexistence issues some other way. If SGI wants a version of
| OpenGL which will compete with Direct3D, that's their business. My concern,
| again, is that they are, in *many* ways, undermining Microsoft's own OpenGL
| program in the process.
As I mentioned to Hock, I'm puzzled that you want to talk about this
stuff in public. But since you do...
By far the greatest issue undermining Microsoft's own OpenGL effort is
Microsoft's support for Direct3D, and Microsoft's positioning of
Direct3D vs. OpenGL. SGI's efforts with Cosmo OpenGL are trivial in
comparison.
| Well then, not to be categorical, I can tell you this much: one of our best
| engineers has very carefully hand-crafted triangle setup Pentium assembler code
| for our OpenGL pipeline. The Direct3D triangle setup, which was also very
| carefully crafted by another top-knotch engineer, is substantially faster.
| There is simply less vertex state to compute, less to put over the bus, and
| what there is to compute is easier to compute given the precision trade-offs.
I don't doubt your word, but again, why is it so? (For comparable
rendering operations, of course.) To my knowledge, no one has ever
given a solid technical reason for this sort of statement.
| 1) Do any of us -- OpenGL licensees, ISV's, end-users, IHV's -- really want to
| promote a low-precision mode for OpenGL to compete with other API's like
| Direct3D or RenderWare?
Several of the early hardware implementations of OpenGL didn't have
subpixel vertex positioning. Did anyone notice?
| 2) Does this direction make any sense if pervasive 3D hardware is going to make
| subpixel correct rendering available without the software performance hit? I
| personally would rather push for higher quality to take best advantage of
| hardware.
Agreed; there's little reason to compromise quality in the future.
| I already had expected to discuss this offline with John, and I look forward
| to our getting together again, but I also don't want to leave this usegroup
| without a clear sense of why we think this is a bad idea that end-users should
| steer clear from, and why we think our implementation is a lot stronger than
| you give us credit for having.
Understood. By the way, I want to state again that SGI has no
objection to a strong OpenGL implementation from Microsoft. The issue
for us is not performance of one OpenGL implementation with respect to
another; it's performance of OpenGL with respect to Direct3D.
| At the same time, I do want to say I understand why SGI has invested in this
| effort. We have a complicated business relationship with SGI, working together
| in some areas and competing intensely in others, and I don't want this exchange
| to come across to readers of the usegroup as a manic struggle.
|
| The bottom line for us is that we have and will continue to offer an
| industry-leading OpenGL implementation. If CosmoGL turns out to have even
| better caching and culling capabilities than those we added, for example, we'll
| be glad to take a look and try adding them to our pipeline. We're all in favor
| of working together to make OpenGL better. ...
Well said.
| ... But our goal there will not be to
| compete with Direct3D; nor will our efforts to improve Direct3D be directed at
| competing with OpenGL.
And I understand why you must say this, even though OpenGL and
Direct3D Immediate Mode are competing intensely with one another in
the minds of both hardware and applications developers.
I'll be on vacation for ten days, and I won't be able to reply during
that time. I'll look forward to the results of your discussions with
John when I return.
Thanks,
Allen
Jon Leech
In article <4vvlc1$t...@news.microsoft.com>,>[much snipped]
>We're all in favor
>of working together to make OpenGL better. But our goal there will not be to
>compete with Direct3D; nor will our efforts to improve Direct3D be directed at
>competing with OpenGL.
>
>Steve Wright
>OpenGL Program Manager
>Microsoft Corporation
I'm a bit confused by the use of "we" and "our" above. When you state
this, are you speaking on behalf of the Direct3D group at Microsoft as well
as the OpenGL group?
Followups to c.g.api.opengl only.
Jon
__@/
Juergen Fechter
I have some basic questions about OpenGL 1.1 and (later) Direct3D
on NT 4.0:
1.) Will they take use of a multiprocessor board (e.g. 2-4 Pentium Pro with MMX support) and speed up the rendering/geometry performance.
Is the architecture of these subsystems on NT 4.0 designed for multithreaded execution?
Is a distribution of parts of the graphic pipeline possible?
2.) Will Direct3D use something like display lists?
Juergen
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Juergen Fechter | Universitaet Tuebingen, WSI/GRIS |
| Office: [+49/0] (7071) 29-75464 | Auf der Morgenstelle 10, C9 |
| Fax: [+49/0] (7071) 29-5466 | D-72076 Tuebingen, Germany |
|---------------------------------------------------------------------------|
| email: Juergen...@uni-tuebingen.de |
| WWW: http://www.gris.uni-tuebingen.de |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stephen H. Wright
In article <322460...@parc.xerox.com>, eho...@parc.xerox.com says...
>
>Stephen H. Wright wrote:
>> ...
>> 3) There is no hardware support story (just as with Direct3D). We
successfully
>> launched a new OpenGL driver model for Windows last June, the "mini-client
>> driver model", which we believe enables competitive OpenGL support for the
3D
>> board industry. Even if CosmoGL were faster than Microsoft OpenGL when
running
>> in software (which we doubt), it will not be faster than Microsoft OpenGL
>> running on the flood of cheap 3D hardware.
>
>Hello Steve,
>
>Can you update us on the current availablity of OGL 1.1 drivers? Should
>I be able to download compliant drivers from Microsoft or from card
>vendors?
>
>Eric Hoppe
>Visualization Team
>Xerox PARC
Eric -
Very few OpenGL vendors ask Microsoft to redistribute their drivers today. You
should contact your vendor. I believe that most vendors today have only
recently released OpenGL 1.0 drivers for NT 4.0, and that the 1.1 drivers may
not be available right away.
Eric Hoppe
Stephen H. Wright wrote:
> ...
> launched a new OpenGL driver model for Windows last June, the "mini-client
> driver model", which we believe enables competitive OpenGL support for the 3D
> board industry. Even if CosmoGL were faster than Microsoft OpenGL when running
> in software (which we doubt), it will not be faster than Microsoft OpenGL
> running on the flood of cheap 3D hardware.
Brian Hook
Stephen H. Wright wrote:
> Real game applications tend to have smaller triangles and setup rate begins to
> gate the rendering. I would be surprised if a any conformant OpenGL
> implementation could approach the D3D ramp mode setup rate.
One comment: Real game applications tend to have LARGER triangles and are generally
very fill intensive. CAD applications tend to have smaller triangles and are setup
intensive. Look at the average size of a polygon in a game such as Quake or Descent
or Terra Nova or Longbow -- terrain and walls.
Brian
Stephen H. Wright
In article <3224B8...@asd.sgi.com>, bh...@asd.sgi.com says...
>
>Stephen H. Wright wrote:
>> Real game applications tend to have smaller triangles and setup rate begins
to
>> gate the rendering. I would be surprised if a any conformant OpenGL
>> implementation could approach the D3D ramp mode setup rate.
>
generally
>very fill intensive. CAD applications tend to have smaller triangles and are
setup
>intensive. Look at the average size of a polygon in a game such as Quake or
Descent
>or Terra Nova or Longbow -- terrain and walls.
>
>Brian
Brian -
I should clarify this. Real games today tend to use larger triangles and
texturing because commodity 3D accelerators are still coming on line today.
Designers that Microsoft has talked to, however, consistently convey their need
to be able to use much smaller triangles with hardware that can handle textured
fills.
As this hardware becomes pervasive, I expect to see triangle setup dominate
rendering for new games. There's a really interesting question posed by the
development of hardware with triangle setup capabilities like the Permedia NT
from 3DLabs. As and when *that* class of hardware becomes pervasive, I would
expect it to significantly level the playing field between *all* the 3D API's
when it comes to rasterization performance.
Stephen H. Wright
Juergen -
In article <5014l7$7...@newsserv.zdv.uni-tuebingen.de>,
fec...@janosch.uni-tuebingen.de says...
>
>I have some basic questions about OpenGL 1.1 and (later) Direct3D
>on NT 4.0:
>
>1.) Will they take use of a multiprocessor board (e.g. 2-4 Pentium Pro with
MMX support) and speed up the rendering/geometry performance.
>Is the architecture of these subsystems on NT 4.0 designed for multithreaded
execution?
>Is a distribution of parts of the graphic pipeline possible?
>
Intergraph OEM's NT with multi-processor systems and has implemented a
multi-threaded driver for their hardware, and gets a pretty good boost from
having at least a second processor in on the rendering. Other vendors I've
talked with have been looking at ways of distributing the pipeline between
processors, but I don't believe any of them are close to market yet.
>2.) Will Direct3D use something like display lists?
>
Direct3D has the ability to put vertex data into execute buffers and send them
to the hardware like a display list. The buffer is not stored on the device,
today, however, and does have to go back across the bus each time.
>
>Juergen
>
>--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>| Juergen Fechter | Universitaet Tuebingen, WSI/GRIS |
>| Office: [+49/0] (7071) 29-75464 | Auf der Morgenstelle 10, C9 |
>| Fax: [+49/0] (7071) 29-5466 | D-72076 Tuebingen, Germany |
>|---------------------------------------------------------------------------|
>| email: Juergen...@uni-tuebingen.de |
>| WWW: http://www.gris.uni-tuebingen.de |
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Wright
Stephen H. Wright
Allen -
Several things you and I and Hock San Lee are going back and forth about appear
to have to do with conflicting stories Microsoft has been getting from SGI --
including exchanges with you as well as more "official" meetings -- about
what's being done with Cosmo. Since you're only involved in what you describe
as the role of "kibitzing", perhaps we should agree to set all of those aside
until SGI has more concrete technical information to disclose publically.
That still leaves a few issues I need to address here, and in your latest
response to Hock (which I'll post separately), so:
In article <500gq6$k...@fido.asd.sgi.com>, ak...@tuolumne.asd.sgi.com says...
>
>In article <4vvlc1$t...@news.microsoft.com>,
>Stephen H. Wright <swr...@microsoft.com> wrote:
>
>One counter-trend that I've noticed is that some people building
>applications with D3D are using ramp mode in order to maximize
>performance. Since this affects the applications in more ways than
>just changing pixel depth, it may create a new set of legacy support
>issues.
>
If you could pass ISV information along to me, I'd appreciate it. My
recommendation is that anyone doing Direct3D development with ramp mode also
support RGB mode, given that future processors (e.g., MMX) will be faster at
RGB than ramp mode, and given that almost all the hardware accelerators are
RGB-only. It's a headache incorporating support for both, but it will help
smooth the transition.
>| Unfortunately, SGI is going to be pulled into this business, ...
>
>It seems necessary, if we're to ensure that a competitive OpenGL is
>available. If there's a viable alternative, let's talk about it.
>
I think the problem here may be your concept of "viable" and "competitive." We
think we're providing an extremely competitive OpenGL for the Windows
platforms. We *have* talked about that, but talking hasn't yet changed SGI's
plans. My sense is that you want OpenGL to be a competitive, if not the
leading, 3D API for games as well as professional 3D (as in your remarks about
wanting Microsoft's OpenGL to blow the doors off Direct3D).
>| ... in spite
of
>| the fact that it's fast in software, ...
>
>I realize you're in a difficult position with respect to Direct3D, but
>for people who are choosing an API, ``fast in software'' isn't a
>strong enough claim. ``Fast relative to Direct3D'' is the interesting
>issue.
>
>| .... and in spite of the fact that it's
faster
>| in hardware than SGI's own workstation implementations in the same price
class.
>
>This is quite debatable, as you know. But rather than get into that
>debate, I'll simply ask: How much faster could it be?
>
You missed my point, so let me try to state it again more directly. Microsoft
is offering a premiere OpenGL implementation across its entire product line.
We offer:
+ Industry leading software performance
+ A rich and rapidly expanding IHV market of hardware accelerators and OEM's
+ Multiprocessor and RISC support
+ A growing family of ISV's in many professional 3D markets
In spite of all that, SGI is offering a new implementation which will
undoubtedly have industry leading color index mode performance, but whose
performance is apparently otherwise untested. There is no accelerator or RISC
story in place, and there are no ISV's signed up.
What doesn't Microsoft offer that justifies this? A ramp mode implementation
to "blow the doors" off Direct3D.
>| ... When we held a public review of the MCD model in June
--
>| for about 100 representatives of about 50 different IHV's -- we explained
that
>| the D3D HAL layering would only make sense for 3D hardware almost
exclusively
>| targetted at the consumer D3D market, and that IHV's anticipating some
>| professional 3D use should provide MCD drivers or ICD drivers. ...
>
>You might want to update your documentation and web pages to reflect
>this new position.
>
I definitely would like to do so, and it will help me if you and any other
readers forward me (as you did yesterday) specific misinformation that I need
to deal with.
>| ... The overhead
>| issues you list are not an issue with either MCD or ICD drivers.
>
>I agree that they're not an issue for ICD drivers, and that's
>precisely the point I wanted to make in my previous note.
>
>As for MCD, implementing any interface layer adds overhead to
>low-level APIs. Could you explain how you completely avoid the cost
>of data reformatting and driver-layer procedure calls in the MCD case?
The MCD interface exposes the OpenGL rasterization pipeline. This maps fairly
well to current hardware (most of which was inspired by either OpenGL or the
3DDDI interface); it also maps directly to the 1.1 API. I'm not sure how well
you understand the ICD and MCD models, and the other readers here probably
could use some clarification even if you do not.
The ICD (installeable client driver) model was the original driver model we
supported for 3D hardware. It is optimal for hardware which supports the
entire OpenGL pipeline; in that case the driver is called almost directly by
the application through an escape mechanism; the driver takes the call
parameters and sends them to the hardware with whatever reformatting the
hardware may require (presumeably very little).
Even full pipeline hardware often fails to support some rendering states,
however, so that the driver also has to track those states and supply software
emulation code to render to the frame buffer. That's why we have to supply any
ICD vendor with a full software library. Currently we give them a
minimally tuned version of what SGI gives us as a sample implementation.
The MCD (mini-client driver) model is a new model which today addresses
primarily the needs of rasterization-level hardware, with an update planned for
the next year that will support hardware that does lighting and transforms as
well. It exposes the rasterization pipeline to the hardware, calling through
the same escape mechanism used for ICD's to a driver which plucks data out of
the transformed, lit, vertex data structure and puts it into the hardware.
If hardware does not perform lighting and transforms, an ICD implementation
will have to include a software implementation of that part of the pipeline.
Assuming their software implementation were every bit as good as ours, they
would end up with the same overhead using either the MCD or ICD driver: a call
through the escape mechanism, software lighting and transforms, and handing off
data to the hardware. They could presumably get a slight edge by basing their
data structures on whatever would make the hardware hand-off as fast as
possible, but this is probably insignificant compared with all the overhead of
the top part of the pipeline.
I think the problem here is that you're thinking of the MCD as a translation
and reformatting layer; it's neither. The actual driver does no more or less
than the ICD with regard to reformatting data for the hardware. It is invoked
with no more or less overhead than the ICD through the escape mechanism. The
layer of code we supply which drives the MCD is just our own optimized front
end, the likes of which would be required internally to the ICD for that same
piece of hardware.
If this isn't clear, it might help to review the materials from the MCD design
review that we gave to SGI last June.
>| ...
Microsoft's
>| own software implementation has also been optimized for geometry processing,
>| and IHV's that use the MCD model automatically pick up the benefits of that
>| tuning. It's *not*, contrary to your assertion, helpful to ICD developers,
>| most of whom have already spent man-years tuning their front end.
>
>Not sure I follow you here. If developers are interested in using the
>ICD model for a new accelerator, why is it not helpful to provide them
>with optimized geometry processing code?
>
Because they've spent even more time tuning their front end than we have. They
think it's faster than ours, and they're probably right!
For developers without this expertise, a new ICD kit would indeed improve what
they can get from an ICD, since our new front end is a lot better than the
sample code SGI made available. The question is why make such a developer go
through the pain of incorporating 70K or so lines of software implementation in
an ICD when they can get all the benefits of the new front end through the MCD
and spend their time coding the 7-15K lines of code required to actually touch
their hardware?
>| >| 1) The announcement contributes to the misperception that Microsoft has a
>| >| poorly-performing implementation and that SGI had to jump in to solve
this
>| >| problem. ...
>| >
>| >See the above comments about driver models.
>| >
>|
>| Aside from the fact that those comments were technically inaccurate, ...
>
>You haven't made your technical case yet, so I'll stand by the
>original comments. Adding a mandatory interface layer adds overhead.
>This can be substantial in a high-performance machine.
On the contrary, I made the case and you ignored it. Here are your original
"comments about driver models", which said that you were concerned with plans
to implement an OpenGL to Direct3D layer:
>One of the technical problems with Microsoft's approach is that MS
>encourages vendors to build layered implementations of OpenGL. Today
>that means using the mini-client-driver (MCD), though Microsoft has
>stated frequently that its plan is to layer OpenGL on D3D or the D3D
>HAL. For hardware accelerators, these are all low-performance
>solutions, because they add data buffering and reformatting steps as
>well as state-management overhead. Only the installable client driver
>(ICD) model makes sense for high-performance implementations. Several
>graphics chip/board vendors already use Microsoft's ICD, and it would
>be nice to see that solution supported more effectively. A fast
>geometry-processing path, such as the one in Cosmo OpenGL, would help
>vendors use Microsoft's ICD and wouldn't require SGI to promote a new
>driver model.
To which I responded yesterday, saying that these were old plans and that we
now expect most OpenGL support to occur through a new, simplified client driver
model:
>This is just wrong. When we held a public review of the MCD model in June --
>for about 100 representatives of about 50 different IHV's -- we explained that
>the D3D HAL layering would only make sense for 3D hardware almost exclusively
>targetted at the consumer D3D market, and that IHV's anticipating some
>professional 3D use should provide MCD drivers or ICD drivers. The overhead
>issues you list are not an issue with either MCD or ICD drivers.
>
>When it comes to ICD versus MCD, we are telling our IHV's to use ICD's only if
>they have considerably geometry pipeline expertise and intellectual property,
>and/or if they have implemented the geometry pipeline in hardware.
>Microsoft's own software implementation has also been optimized for geometry
>processing, and IHV's that use the MCD model automatically pick up the
>benefits of that tuning. It's *not*, contrary to your assertion, helpful to
>ICD developers, most of whom have already spent man-years tuning their front
>end.
You raised a new issue in your most recent posting, concerned that the MCD
interface would also require data reformatting a la a Direct3D layer. Perhaps
that's the same issue in your mind; if so, I hope it's settled now.
>| ... I would be surprised if a any conformant OpenGL
>| implementation could approach the D3D ramp mode setup rate.
>
>Why? I've been hearing this sort of comment for the last year or
>more, but never been given a convincing explanation. All the
>technical considerations of which I'm aware argue against it.
>
That's silly. As I wrote about the RGB triangle setup:
>"There is simply less vertex state to compute [that's not a precision issue,
>just a Direct3D versus OpenGL state issue], less to put over the bus, and what
>there is easier to compute given the precision trade-offs."
If you don't like an explanation, please refer to it and say why it's not
"convincing". Don't pretend it hasn't been given.
>| >I don't mean to be snide; this is a serious issue. Developers are
>| >trying to choose an API, and they need comparisons between APIs, not
>|
>| What we've been saying is: use Direct3D for games and consumer-oriented
>| software; use OpenGL for professional 3D software; use either one for
business
>| or productivity 3D software (e.g., VRML viewers). If anyone is getting a
>| different message, please let me know so that I can try to fix that.
>
>If it's possible to build an OpenGL that approaches Direct3D in
>performance and in ease of hardware support, it would seem that the
>main reasons for this distinction are business issues, particularly
>API control. That's the underlying concern you might eventually have
>to address.
>
I've got some very strong personal feelings about these issues, and I don't
think I have the authority within Microsoft to be addressing them as a
Microsoft representative, so I'm going to put that hat off for a moment and
simply speak personally for a minute.
I think *both* SGI and Microsoft have some very sensitive business issues as
well as technical concerns around these issues. I've been around long enough
to have had to deal with lots of 3D API's (who else here remembers the NCAR
libraries?!), and we both understand that technical excellence doesn't always
(or perhaps even often) "win". (As an ex-Apollo employee, the word "UNIX"
comes to mind.) In the 3D arena, the argument could be made that it was purely
business considerations -- like the fact that Microsoft joined the ARB -- that
carried the day for OpenGL over PEX.
I don't regard "business issues" as an epithet. My personal technical belief is
that OpenGL, properly extended, could be used for games. My personal business
conviction, having lived through the glory days of GKS, PHIGS, and PEX, is that
no one should put all their eggs in one 3D API.
I don't believe API control is as big an issue as you appear to believe. For
one thing, I'm pretty happy with the amount of influence Microsoft has over
OpenGL. The argument could be made that of the seven permanent ARB members -
SGI, Evans and Sutherland, Digital Equipment, IBM, Intergraph, Intel, and
Microsoft -- that six of them have substantial interests in Microsoft operating
systems, that only five have substantial interests in UNIX operating systems,
and that only one has substantial interests in SGI operating systems. SGI is
(currently) the technology leader, but Microsoft carries a lot of weight.
>| ...(Will you keep pace with our future
>| extensions? ;-) )
>
>If Cosmo OpenGL is widely used, you might have to keep pace with ours. :-)
>
That's ok. We'll just ask for them under the terms of our license agreement.
:-))!
>| This is that evasion again. SGI doesn't have a story and Microsoft does.
Even
>| if it wasn't as good a story as SGI would like to see -- and I believe it's
a
>| lot better than you understood it to be -- it's a lot better story than
SGI's.
>
>Vendors who want high-performance OpenGL will be able to build ICDs
>based on Cosmo OpenGL code, if they so choose. (Cosmo OpenGL can make
>that process much easier than it is today.) Those who don't care about
>high-performance OpenGL can use MCD or even the D3D HAL
>implementation. The Cosmo OpenGL ``product'' only needs to run on
>software-only systems. Seems to me that SGI's ``story'' is pretty
>simple, and plays together with Microsoft's.
>
If you want to give the Cosmo code to IHV's to improve their ICD's on our
platform, that's great. (My sense is that most of the ICD vendors today
already have "crown jewels" they won't part with or replace, and that the
potential MCD vendors today can't afford to get into ICD development at all,
with either our code or yours, but I could easily be wrong.) The problem is
that it's still not a hardware support story for Cosmo's software libraries,
and the Cosmo libraries don't have access to the OS-mediated escape mechanism
that provides access to the ICD or MCD.
The SGI story, then, is that there's a library which runs really fast in
software ramp mode (for which there are currently relatively few applications),
which may or may not outperform the Microsoft software implementation, but
which can't take advantage of any 3D hardware, from low-end S3 Virge cards to
Intergraph RealiZm machines.
>By far the greatest issue undermining Microsoft's own OpenGL effort is
>Microsoft's support for Direct3D, and Microsoft's positioning of
>Direct3D vs. OpenGL. SGI's efforts with Cosmo OpenGL are trivial in
>comparison.
>
I agree that Microsoft has not been consistently clear about the positioning of
OpenGL and Direct3D, but I think we've been pretty clear -- with a couple of
notable exceptions -- about OpenGL as the API for professional 3D applications.
What concerns me is that the confusion around Cosmo -- for example:
+ Is it a product or a technology demonstration?
+ Does it support hardware acceleration?
+ Is it faster than the Microsoft OpenGL?
+ Can it coexist with Microsoft OpenGL on the same system?
+ If so, what happens to hardware acceleration?
+ Does it support metafiling and printing like Microsoft OpenGL?
...
-- that confusion has the potential to undermine Microsoft's positioning of
OpenGL as an API for professional 3D. If SGI announces that this was a
technology demonstration and that they are making their new pipeline code
available to all OpenGL licensees, that's one thing. If they continue to
position it as a product on our platform, I foresee no end of positioning
problems.
>| 1) Do any of us -- OpenGL licensees, ISV's, end-users, IHV's -- really want
to
>| promote a low-precision mode for OpenGL to compete with other API's like
>| Direct3D or RenderWare?
>
>Several of the early hardware implementations of OpenGL didn't have
>subpixel vertex positioning. Did anyone notice?
>
I wasn't doing GL then. I *have* noticed more obvious z-buffering artifacts
with low-precision VRML viewers than with OpenGL-based viewers, but there could
be other issues there. It's an interesting general question, so I'll ask it
again:
Do any of us -- OpenGL licensees, ISV's, end-users, IHV's -- really want to
promote a low-precision mode for OpenGL to compete with other API's like
Direct3D or RenderWare? I'm asking this seriously!
Mark Kilgard
In article <502il7$f...@news.microsoft.com>, swr...@microsoft.com (Stephen H.
Wright) writes:
|>
|> >2.) Will Direct3D use something like display lists?
|>
|> Direct3D has the ability to put vertex data into execute buffers and send
|> them
|> to the hardware like a display list. The buffer is not stored on the device,
|> |> today, however, and does have to go back across the bus each time.
Does any hardware actually work as you describe?
There are a number of problems with the Direct3D hardware you describe:
o Direct3D's execute buffer protocol is exposed to the application
(indeed, application supposed to use C macros to write into the buffer)
meaning that a graphics hardware accelerated for Direct3D is forced
to implement this same protocol. Unfortunately, the protocol as
defined is not particularly well suited for hardware decoding. There
are things like bit-fields that would be slow to decode.
o Sure, you could "send the buffer to the hardware like a display list",
but if the application modifies the buffer again, you'd have to resend
the entire execute buffer to the hardware since the execute buffer
could have arbitarily changed.
Since execute buffers are rather coarse-grain objects, they are large
enough that minor edits requiring a full download would be really
expensive.
o Because Direct3D's vertex list in its execute buffer is accessed by
indices, the hardware has to maintain the entire vertex list downloaded
in the hardware. This could be fairly large.
o Direct3D's execute buffers don't all good pipelined parallelism between
the host CPU and the graphics hardware. While the host is updating an
execute buffer, it cannot be being executed by the graphics hardware.
Fast graphics hardware would end up being stalled while the CPU is
filling the next buffer.
o The lack of pipelined parallelism also will create latency that could
otherwise be hidden with the host CPU and graphics hardware acting as
a pipeline. Poor latency is what all gamers hate.
Honestly, I'd guess that the decoding of Direct3D's execute buffers is doomed
to be always done on the machine's host CPU. This likewise dooms Direct3D
to be limited to the host CPU's speed with little chance to offload substantial
work to the graphics hardware. Direct3D is a very short-sighted design.
If you know of any graphics hardware vendors that are actually trying to
design hardware that directly executes a Direct3D execute buffer, I'd be
interested in hearing about it. So far claims of such hardware that executes
Direct3D execute buffers directly have all been conjecture from software
people without a lot of graphics hardware design experience as far as I can tell.
Since this is an OpenGL newsgroup, not a Direct3D newsgroup, I feel obligated
to say something about OpenGL. Err, OpenGL has none of the problems
described above.
- Mark
Stephen H. Wright
Allen -
As I wrote in my other response to you today, I'm going to steer clear of the
instances where we seem to have received conflicting message about what Cosmo
is or isn't, does or doesn't. That leaves ...
In article <500bh6$7...@fido.asd.sgi.com>, ak...@tuolumne.asd.sgi.com says...
>
>In article <4vvf27$u...@news.microsoft.com>,
>Hock San Lee <ho...@microsoft.com> wrote:
>
>If you have benchmark results that show that your latest release of
>OpenGL is as fast or faster than Direct3D, please let us know!
As I wrote yesterday, in RGB mode OpenGL is slightly faster in triangle fill
and quite a bit slower in triangle setup. If you think your RGB
pipeline is as fast or faster than Direct3D, please let *us* know!
We don't have a zippy ramp mode implementation in our OpenGL, but don't
consider that to be very important, given the direction that hardware is going.
>
>| ...
>| 2. Some extension may have serious memory footprint. The amount of memory
>| required to cache tens of thousands of transformed vertices cannot be
>| ignored on existing PCs.
>
>Presumably the same concern applies to execute buffers in Direct3D.
>
>From reading your comment, people might assume that all the
>performance enhancement extensions in Cosmo OpenGL require caching of
>huge numbers of vertices. This isn't true, though.
>
Hmmm. The way I read it was that at least *one* of the performance enhancement
extensions cached a lot of vertex data. Does it? If so, Hock's question
raises a classic trade-off issue, and asks whether you need to have an extra
Meg or so of memory on hand to get that performance benefit.
>
>| We promote MCD for rasterization hardware. The claim about its
>| sub-optimal approach/performance is completely baseless. ...
>
>Adding a new layer of function calls and forcing data to be batched
>and reformatted in a way that isn't guaranteed to match the hardware
>usually results in suboptimal performance. I think most people would
>agree that the concern isn't ``completely baseless.''
>
>This is not to say that MCD is a bad thing; it provides an easy,
>cost-effective solution for vendors of rasterization-only hardware who
>don't need peak performance for OpenGL. It's also likely to be much
>faster than layering OpenGL on D3D. It's just not the right solution
>for vendors who want absolutely maximum performance, whether or not
>their cards include geometry processors.
>
I disagree. See my other post for the details, but the gist is that if your
hardware doesn't support lighting and transforms, you'll get as much
performance out of the MCD as you would out of an ICD based on our own
front-end code. Of course, if you have access to even better front-end code,
you could do better.
>| Based on our experience, a well written MCD can outperform an average ICD.
>
>I guess it's usually true that well-written software can outperform
>average software. :-)
>
The issue here is that very few driver writers have the expertise to write an
excellent ICD. Apart from the mediocre SGI sample implementation they usually
start with, it's a much bigger, hairier job than a traditional "touch the
hardware" driver. That same engineer *could* produce a well written MCD.
>| The investment on a good ICD implementation is so huge that it presents a
>| significant barrier to entry for most commodity hardware vendors.
>
>Yes, this is true.
>
>One way to reduce the implementation cost is to create a new, simpler
>device interface, as you've done with MCD. Another way is to provide
>a much better baseline implementation for ICD. The latter approach
>offers the potential for better performance and more support for
>innovative features on a wider range of hardware.
My sense of the market today is that most people making cards for $1K and up
are using ICD's and already have front-end technology that they consider to be
"crown jewels". When they license our ICD kit, all they take is the escape
mechanism interface layer that we use to call them from our OpenGL
implementation.
A few do not appear to have well-optimized drivers, and could probably get an
enormous step up the curve by adopting an MCD. If they do not have a good
front end, they could do no better with an ICD unless they got better front-end
code from a third party.
Finally, there are a horde of commodity 3D vendors who need to get quick OpenGL
support, who don't have OpenGL expertise, and for whom the MCD is an
overwhelmingly better choice. They,too, couldn't do any better with an ICD
from us unless someone else gave them a different front end.
If SGI were to distribute their Cosmo front end to this market, and if it were
better than our front end, then indeed those IHV's interested in the work would
find a leg up implementing ICD's based on the Cosmo front end. However, if it
really *were* better than our front end, we'd probably want to pick it up too,
or integrate it with our own improvements. Then the MCD vendors would get all
the benefits for free without the headache of writing an ICD.
>
>| We'd rather not have to respond to many of your public claims...
>
>I'm really puzzled as to why Steve posted his previous message
>publically rather than conducting a discussion offline. Because the
>original posting was public, I replied in public. But as I said in my
>previous message, we'd be happy to discuss things with you face to
>face. All we're looking for is an OpenGL implementation that's as
>fast as D3D, and widely available.
>
This is a knotty one. We've discussed this offline directly with SGI and in
forums such as the ARB, and we'll continue to do so. It hasn't yet changed
anything, and I think part of the problem is that SGI is not just concerned
with having a "high-performance OpenGL on Window95"; rather, this translates
into specifically "blow the doors off" Direct3D. Frankly, having a world-class
ramp mode implementation in OpenGL strikes me as something like having a
world-class musketeer squad involved in Operation Desert Storm.
(BTW, when Hock said he didn't want to respond to SGI claims, I think what he
meant was not that he didn't want to discuss them here or any other forum, but
that we don't want our product strategy to be pressured or manipulated by
unsubstantiated claims.)
>Regarding performance claims, what I've said is that we've
>demonstrated Cosmo OpenGL applications that are straightforward ports
>of Direct3D Immediate Mode applications, using same-sized textures,
>windows, etc. to make the comparison as fair as possible. Anyone who
>attended SIGGRAPH could see for themselves that the Cosmo OpenGL
>performance was as good as or slightly better than the Direct3D
>performance. This is something that I've claimed is possible for a
>long time, based on technical considerations alone. At SIGGRAPH we
>just showed the first existence proof.
I mentioned yesterday that this was not suprising, based on the RGB comparisons
we've made, with, however, the big caveat that your sense of the comparison may
be biased by having used samples with relatively large triangles. Do you have
both fill rate and triangle setup data (like the d3dtest output)?
In any case, *I*'ve been saying for a long time (trading chest-beating for
chest-beating!) that software performance tuning is of limited value with
pervasive hardware acceleration coming along. We've been seeing the existence
proof for that, now, too. The tuning you've done to the front end of the
pipeline is potentially leveragable (as was ours) if you have a hardware driver
story.
As I understand it though, your story is to give the code to IHV's for ICD's.
As I've already suggested, most of the people who could actually use a better
front end don't have the expertise and business focus to do the job, and the
MCD model gives them our good front end for free. So unless yours is even
better, it's not going to do anyone any good; and if it is, you'll need to give
it to us so the MCD IHV's can benefit.
Have a good vacation!
Richard S. Wright Jr.
Stephen,
I have a question/suggestion about this:
> >See also Microsoft's own documentation and marketing material.
> >Quoting from the DirectX2 SDK Direct3D Overview, for example:
> >
> > Direct3D is Microsoft's high-speed 3D software solution.
> > [Chapter 5, part A, page 4]
> >
> > OpenGL is a precise 3D technology used for high-end CAD/CAM,
> > modeling and animation, simulations, scientific visualization,
> > and other exacting 3D-image rendering. [Chapter 5, part A,
> > page 6]
> >
> >Can you blame anyone for concluding that Microsoft's OpenGL is the
> >wrong choice for performance-conscious developers?
> >
>
> If Microsoft is offering confusing or inaccurate positioning materials, we need
> to fix them, and that's one of my jobs. I'd hate to think that this is an
> invitation for SGI to reinforce the misperceptions I'm trying to deal with.
>
I've been watching very closely the development of OpenGL on Windows for some time now. In all honesty, it wasn't
until Siggraph this year that you could find hardly a mention of OpenGL at the Microsoft Web site. Further, the
BIG announcement of the OEM refresh of Windows95 had over a dozen bullets of new enhancements and tunnings.
OpenGL was (at least from my perspective) painfully missing from this list.
Believe me when I say that I want OpenGL to be successful on Windows. I don't work for Microsoft or SGI - all I'm
interested in is promoting OpenGL. I don't mean to be sarcastic, but I find the phrasing of the OpenGL
positioning "OpenGL is a precise 3D technology..." to be a bit patronizing. This is just my two cents worth, but
what "I" might say is:
Direct3D is Microsoft's 3DAPI for lowend consumer applications and games that require high speed animations, but
don't require high visual fidelity.
OpenGL is a full featured profesional API for high quality 3D applications that in addition to performance, also
need high visual fidelity and a wide range of capabilities.
I won't get into this "OpenGL should be as fast as Direct3D" bit for the time being. But the misconceptions are
there, and I don't beleive SGI has contributed all that much until lately (there was one really racey post about
Microsoft making OpenGL look bad). Articles in MSJ and PC magazine have fueled this fire more than these
discussions ever could (not THAT many people are following this newsgroup). I realize that Microsoft can't
control what Jeff Prosise or anyone else has to say, but "Microsoft" could step up to the plate from time to
time.
Further, you have to admit OpenGL on NT 3.5 and 3.51 was pretty darn slow. You can't blame anyone for the
negative momentum that has created. That said, I practicaly jumped up and shouted when I started using OpenGL
under NT 4.0! The problem is again that darn momentum, and it will take some time before people start to realize
that OpenGL isn't just for "Precise" rendering, but also for developers who need a "full featured" API and not
necessarily at the expense of speed. If you throw RGB mode at Direct3D is slows to a crawl. As you've hinted at,
depending on the geometry it's not always clear who would have the faster frame rate.
In high school, I learned the difference between "connotation" and "denotation". Microsoft's marketing people are
not oblivious to this and have been making good use of it. If you can't see this then I might suggest that you
are thinking too much like an engineer instead of a manager in charge of promoting a technology.
What do I think is going to happen? As far as that "high-end CAD/CAM" stuff that gets tacked on the end of
OpenGL, they said the same thing about the 386, 486, pentium, PPro.... Everyone is worried about Direct3D
eclipsing OpenGL. The only way this will happen is if Direct3D gets all the features and capabilities of OpenGL
over the years and "stays" faster under Windows. Within a few years we are going to have commodity hardware that
will do 30fps with 100,000 polygons and to remain competitive vendors are going to have to resort to something
other than framerate to differentiate their products. Comparing Direct3D and OpenGL is in some ways like
comparing cooperative and preimptive multitasking. Windows 3.1 ruled for a while while OS/2 languished, now
Windows 95/NT are emerging as heirs apparent. Don't forget the difference between the battle and the war (this is
I know obvious to you, but I say this for the benefit of others).
Richard
head...@passport.ca
In <4vt29j$v...@news.microsoft.com>, swr...@microsoft.com (Stephen H. Wright) writes:
>In article <4vb2j9$i...@fido.asd.sgi.com>, ak...@tuolumne.asd.sgi.com says...
>>
>>In article <4vatd3$5...@darkstar.ucsc.edu>,
>>Duane Strong <dst...@cats.ucsc.edu> wrote:
>>| ... Direct3D emphasizes speed
>>| over precision, whereas OpenGL will have perfectly meshing polygons
>>| and a richer API at the expense of rendering speed.
>>
>>At SIGGRAPH SGI demonstrated a version of OpenGL with performance
>>that's comparable to Direct3D; even faster than Direct3D in some
>>cases. When that's released (current plans call for mid-September)
>>there shouldn't be any performance reasons to prefer one of the APIs
>>over the other.
>>
>>Allen
>
>Allen et al. -
>
[ long post deleted ]
Sounding a bit defensive, aren't we Steve? I think what SGI did was quite
understandable -- MS has been promoting DirectX 3D APIs as being intrinsically
superior in performance to OpenGL for games. SGI burst that bubble by providing
an implementation of OpenGL that delivers comparable performance to the
Direct3D API.
It seems to me that MS can't stand to see an important API that it doesn't
control. Failing aquiring control, they provide a competing API, and try to
drive the original one into obscurity. All SGI is doing is countering that strategy.
There's no need to sound petulant over tactics which your company uses at
the drop of a hat.
Hock San Lee
In article <504mp1$n...@nntp.sierra.net>, Kend...@scitechsoft.com says...
>
>ho...@microsoft.com (Hock San Lee) wrote:
>
>>>There are tens of millions of machines in the field that don't support
>>>MMX, so good performance for machines without MMX is interesting to a
>>>lot of people. I agree that MMX is important for new machines.
>
>>Do you have a release plan for MMX support?
>
>Penitum architecture. It certainly is interesting, however for mainstream
>applications I don't believe the interest is going to peak until about
>12-18 months from now, and even then only a small percentage of the market
>is going to be exposed to it.
>
>Will it be interesting for commodity 3D? Not likely in the near future,
>because Intel currently plans to ship it in Pentium 200 and Pentium Pro 200
>CPU's. How many commodity 3D gamers do you think will be rushing out to
>purchase a brand new Pentium 200 just so that they can get MMX support?
>Surely purchasing a $250 3DFx Vodoo or Rendition Verite is a more cost
>effective solution in the short term?
The point here is that Direct3D will support MMX. If Cosmo OpenGL does not support
it, SGI will take a lot of heat from their (game) ISVs. If you look around, all other
game APIs will be supporting MMX. This is important to game ISVs who are choosing
between APIs. I claim that any game API that ignores MMX is doomed.
>>Based on our experience, a well written MCD can outperform an average ICD.
>>The investment on a good ICD implementation is so huge that it presents a
>>significant barrier to entry for most commodity hardware vendors.
>>Microsoft invests in MCD technology to make high performance OpenGL
>>hardware available to commodity PC. For instance, the sample MCD has
>>about ~10K lines of optimized code provided by Microsoft while the sample
>>ICD has about 75K lines of un-optimized code provided by SGI.
>
>Well this is very easily solveable. Why doesn't Microsoft make available to
>OpenGL hardware vendors for the PC the 75K of 'highly optimised' and Intel
>targetted code that it has in it's current OpenGL libraries? Surely
>Microsoft could make available a new ICD kit for WinTel hardware vendors
>that is not just a copy of the SGI sample source code (which we all know is
>intended as a porting tool, not as a high performance reference
>implementation for all machines).
>
>An MCD solution is a cost effective solution for commodity 3D vendors, but
>a highly optimised ICD sample implementation from Microsoft for vendors
>wanting all out performance with OpenGL would probably go a *lot* farther.
There are many things that MCD does not support today. An example is feedback and
selection mode. Another example is evaluator. By providing default support for these
features, we believe IHVs can focus their efforts in providing an optimal driver that
is relevant to their hardware and most applications. MCD drivers will also inherit
any further performance gains that we do in the front end.
The 75K lines of code is not "free". Even though OpenGL 1.1 was approved last
December, I doubt you are going to see many OpenGL 1.1 implementations this year.
The ones that you will see are likely based on MCD because the development cycle is a
lot faster.
Today, our Millennium MCD driver is blowing away entry Indy's in triangle benchmarks,
even with a "translation layer" objected so frequently by some SGI engineers. (Here
is a challenge to SGI, produce better entry Indy viewperf numbers than our published
software numbers ;-)).
If we think releasing a fast ICDs will benefit our platform, we would have done so
already. Our ICD vendors already have optimal code from many years of development to
benefit from our optimization. This code will more than likely confuses our commodity
IHVs and will actually cost us in driver quality and timeliness.
There are a lot of other issues. But we do similar thing in GDI vs DDI.
>>The next
>>version of MCD will target geometry hardware. The development time for a
>>well written MCD is generally fewer than 6 months as compared to many
>>years of development required to write a good ICD.
>
>Dooh. Surely the above statement must make you realise that *you* can cut
>the development time in half for a hardware vendor wishing to build a high
>performance ICD by providing them with optimised sources, not just SGI
>sources? Extending the MCD architecture to support geometry acceleration is
>likely to be an extercise in futility I would think. OpenGL was designed
>from the start to be an API that translates almost directly to hardware
>calls on systems with full geometry acceleration.
See above comments.
>>We'd rather not have to respond to many of your public claims. These
>>unsubstantaited (Cosmo OpenGL) claims only confuse developers.
>
>You know, the whole market confusion has stemmed from Microsoft's own
>indecisiveness about just what is the 3D API of choice on the WinTel
>platform. For some strange reason you guys seem to think that high end CAD,
>visualisation and medical imaging applications don't require the same sort
>of performance that interactive 3D gaming titles do. WAKE UP! These
>applications have been demanding more and more performance since the dawn
>of 3D.
>
>As Allen has pointed out, you guys need to look into your own marketing and
>promitional material for Direct3D; that is why developers are confused
>about how OpenGL fits into the picture.
As Steve Wright has responded, send him the relevant info and he will try to fix them.
>>We already have first-rate OpenGL software/hardware implementations on our
>>platform based on current benchmarks.
>
>Many of us want a really good, fast OpenGL for the WinTel architecture. The
>previous implementation was lacking in performance, and I certainly hope
>that the new version is as fast you claim. As Allen said, if you can get
>OpenGL running as fast or faster than Direct3D, everyone in this newsgroup
>would be happy as pie.
I can assure you that we now have really good OpenGL implementations on Windows NT.
See http://www.specbench.org/gpc/opc.static/index.html. They will only get better.
As we said in other posts, many game APIs have fast ramp mode and do not do full
sub-pixel corrections. If they start doing the same sub-pixel corrections that most
OpenGL implementations do today, their performance will not be better.
Hock San Lee
Microsoft
Michael I. Gold
ho...@microsoft.com (Hock San Lee) writes:
| Today, our Millennium MCD driver is blowing away entry Indy's in
| triangle benchmarks, even with a "translation layer" objected so
| frequently by some SGI engineers. (Here is a challenge to SGI,
| produce better entry Indy viewperf numbers than our published software
| numbers ;-)).
I liken this argument to the old magician's trick of distracting the
audience with the right hand while doing the dirty work with the left
hand.
I cannot comment on Indy viewperf numbers since I have never seen them
(nor looked for them). If this was even relevant to the discussion, I
might point out the you mentioned the entry-level Indy, and there are
several different configurations with dramatically different levels of
performance.
But the real point here, despite your attempted slight-of-hand, is how
Microsoft's OpenGL compares with Direct3D. As far as anyone can tell,
even your latest, greatest, fastest OpenGL 1.1 falls short of Direct3D
performance.
So, how does your OpenGL compare with Direct3D on the Millennium MCD
driver?
--
Michael I. Gold http://reality.sgi.com/employees/gold 415/933-1709
Silicon Graphics Computer Systems go...@sgi.com
And my mama cried, "Nanook a no no! Don't be a naughty eskimo! Save your
money, don't go to the show!" Well I turned around and I said, "Ho! Ho!"
Peter Shenkin
In article <504pmq$o...@nntp.sierra.net>,
Kendall Bennett <Kend...@scitechsoft.com> wrote:
>CosmoGL and Microsoft OpenGL do not have to compete against each other.
>They can be completely complimentary....
The way this discussion has been going, it is highly unlikely that
they will ever be complimentary. They might, however, be complementary.
;-),
-P.
--
********************* (Note new snail-mail address.) **********************
* Peter S. Shenkin, Chemistry, Columbia U., 3000 Broadway, Mail Code 3153,*
** NY, NY 10027; she...@columbia.edu; (212)854-5143; FAX: 678-9039 ***
MacroModel WWW page: http://www.cc.columbia.edu/cu/chemistry/mmod/mmod.html
Hock San Lee
In article <504pmq$o...@nntp.sierra.net>, Kend...@scitechsoft.com says...
>
>swr...@microsoft.com (Stephen H. Wright) wrote:
>
>>I also suspect that this is the case with the Cosmo GL implementation. Most of
>>the sample D3D apps are fill-rate gated, so that it's relatively easy to
>>implement an OpenGL renderer that runs competitively on those sample programs.
>>Real game applications tend to have smaller triangles and setup rate begins to
>>gate the rendering. I would be surprised if a any conformant OpenGL
>>implementation could approach the D3D ramp mode setup rate.
>
>is the whole problem; Microsoft does not appear to be interested in adding
>the necessary software rendering fast paths to their OpenGL implementation
>that *will* make it competetive with Direct3D. Why?
>
>All you need to do is figure out what makes Direct3D fast. What corners did
>they have to cut in order to bring the performance of the rendering up to
>speed? Once you know that, add a fast path to your OpenGL that will cut the
>same corners, if necessary adding a new GL_HINT to enable these that game
>developers can use.
We have decided to optimize RGBA mode in Windows NT 4.0 and the results show.
There are many other areas we can improve but Color Index mode and sub-pixel
elimination is low on our list. We are deploying our resource based on our
projection that most hardware are RGB based, not color index based. Note that
by cutting corners, you are more than likely to produce a non-conformant
OpenGL implementation.
My point is that most of our OpenGL ISVs are professional based. They want fast
RGBA mode, not CI mode. They want precise sub-pixel correction, not artifacts.
No one has the resource to optimize *all* cases, not even Cosmo OpenGL. Cosmo
OpenGL may be faster than our implementation in some cases, but it is highly
unlikely that they will be faster than our implementation when running OpenGL
benchmarks that reflect professional application usage today.
>>Our goal is not to "blow the doors off of Direct3D", however, and if that's
>>SGI's standard for whether or not to make a product of Cosmo GL, SGI will have
>>to solve the coexistence issues some other way. If SGI wants a version of
>>OpenGL which will compete with Direct3D, that's their business. My concern,
>>again, is that they are, in *many* ways, undermining Microsoft's own OpenGL
>>program in the process.
>
>So what exactly *is* Microsoft's OpenGL program? Surely Microsoft's primary
>goal for OpenGL would be to make it as fast as possible on Microsoft
>operating systems? Surely a goal of attaining the same performance levels
>as Direct3D (and surpassing it for hardware based systems) is a good goal,
>is it not? Perhaps you can explain to me exactly *why* it is a bad thing
>for OpenGL to run as fast or faster than Direct3D?
According to our feedback, OpenGL is as fast as Direct3D when running on
accelerated hardware based systems. If you are complaining about our software
Color Index mode performance, please see the comments above. Most OpenGL
applications on NT today use RGBA mode, not CI mode.
>>Well then, not to be categorical, I can tell you this much: one of our best
>>engineers has very carefully hand-crafted triangle setup Pentium assembler code
>>for our OpenGL pipeline. The Direct3D triangle setup, which was also very
>>carefully crafted by another top-knotch engineer, is substantially faster.
>>There is simply less vertex state to compute, less to put over the bus, and
>>what there is to compute is easier to compute given the precision trade-offs.
>
>Well if it is so difficult, then how come SGI has been able to implement a
>version of OpenGL in software that *does* run as fast as the Direct3D
>software rasteriser?
>
>The whole point of this discussion is that SGI is basically proving a lot
>of the misperceptions that Microsoft has been publicly proclaiming about
>OpenGL and Dircet3D to be false. No-one likes egg on their face, and if
>CosmoGL proves that OpenGL can be as fast as Direct3D in software,
>Microsoft has a lot of egg on it's face.
Steve's point was that given the same precision requirement, the two APIs will
indeed perform comparably in RGBA mode.
Hock San Lee
Microsoft
Michael I. Gold
swr...@microsoft.com (Stephen H. Wright) writes:
| We don't have a zippy ramp mode implementation in our OpenGL, but don't
| consider that to be very important, given the direction that hardware is
| going.
One might argue that the lack of hardware acceleration for ramp mode make
a good software implementation even more important. If ramp mode has no
useful purpose, then the Direct3D team has wasted a lot of effort in
optimizing that path! Despite the fact that hardware acceleration for
both RGB and ramp modes of OpenGL has existed for years, a lot of application
developers have chosen to use color index mode, for various reasons.
| This is a knotty one. We've discussed this offline directly with SGI and in
| forums such as the ARB, and we'll continue to do so. It hasn't yet changed
| anything, and I think part of the problem is that SGI is not just concerned
| with having a "high-performance OpenGL on Window95"; rather, this translates
| into specifically "blow the doors off" Direct3D. Frankly, having a world-class
| ramp mode implementation in OpenGL strikes me as something like having a
| world-class musketeer squad involved in Operation Desert Storm.
And would you say the same about ramp mode in Direct3D? For the upteenth
time, Cosmo OpenGL has fast RGB paths too.
| (BTW, when Hock said he didn't want to respond to SGI claims, I think what he
| meant was not that he didn't want to discuss them here or any other forum, but
| that we don't want our product strategy to be pressured or manipulated by
| unsubstantiated claims.)
(don't worry, they will be substantiated soon enough! ;-)
| In any case, *I*'ve been saying for a long time (trading chest-beating for
| chest-beating!) that software performance tuning is of limited value with
| pervasive hardware acceleration coming along. We've been seeing the existence
| proof for that, now, too. The tuning you've done to the front end of the
| pipeline is potentially leveragable (as was ours) if you have a hardware
| driver story.
If, as you said in an earlier post, hardware acceleration will equalize
performance between competing 3D API's, it is less clear why Microsoft
feels compelled to offer competing 3D API's. Certainly not for performance.
And you deny that your motivation is to retain a controlling interest in a
proprietary API. Please help me understand.
Ben Cheatham
Hock San Lee wrote:
>
>
> >But the real point here, despite your attempted slight-of-hand, is how
> >Microsoft's OpenGL compares with Direct3D. As far as anyone can tell,
> >even your latest, greatest, fastest OpenGL 1.1 falls short of Direct3D
> >performance.
>
> they are comparable. Note that this is not an apple-to-apple comparison
> and "comparable" is as best as I can put it.
>
> >So, how does your OpenGL compare with Direct3D on the Millennium MCD
> >driver?
>
> are basically identical in performance.
>
It is great to hear this. Now, why then does MicroSoft insist on
promoting Direct3D (over OpenGL) for games development? From what
you just stated, I'd say MicroSoft could save themselves some work
and promote one API, and make the decision of API choice easy for
any independent developer.
--Ben
-----------------------------------------------------------
Ben Cheatham - Advanced Systems Division, Silicon Graphics
-----------------------------------------------------------
Jon Leech
In article <5051fe$8...@news.microsoft.com>,
>it, SGI will take a lot of heat from their (game) ISVs. If you look around, all other
>game APIs will be supporting MMX. This is important to game ISVs who are choosing
>between APIs. I claim that any game API that ignores MMX is doomed.
Perhaps I am being pedantic, but I believe you meant to say "any
IMPLEMENTATION OF A game API that ignores MMX is doomed" Or do you feel
presence or absence of MMX should manifest itself in the API proper?
Followups to c.g.api.misc.
Jon
__@/
PS Please keep lines well below 80 characters.
Kendall Bennett
swr...@microsoft.com (Stephen H. Wright) wrote:
>If Microsoft is offering confusing or inaccurate positioning materials, we need
>to fix them, and that's one of my jobs. I'd hate to think that this is an
>invitation for SGI to reinforce the misperceptions I'm trying to deal with.
OpenGL is OpenGL, regardless of who actually implemented it. That is the
whole beauty of an Open API archiecture. Hence it does not matter if people
are writing OpenGL code using CosmoGL or Microsoft's OpenGL; at the end of
the day the source code they use is identical and is fully portable between
one or the other.
Surely you realise that having alternative implementations of OpenGL
available is not necessarily a bad thing? Consider that code written to
CosmoGL will port directly to Microsoft OpenGL with no changes. For a
Direct3D title, the entire thing would need to be completely re-written to
support OpenGL. Not only that but an OpenGL title is likely to run a hell
of a lot faster on a system with full geometry acceleration than a Direct3D
title (imagine running games on a high end Integraph system!).
>I also suspect that this is the case with the Cosmo GL implementation. Most of
>the sample D3D apps are fill-rate gated, so that it's relatively easy to
>implement an OpenGL renderer that runs competitively on those sample programs.
>Real game applications tend to have smaller triangles and setup rate begins to
>gate the rendering. I would be surprised if a any conformant OpenGL
>implementation could approach the D3D ramp mode setup rate.
Bull. If you implement the appropriate fast paths, it will be as fast. That
is the whole problem; Microsoft does not appear to be interested in adding
the necessary software rendering fast paths to their OpenGL implementation
that *will* make it competetive with Direct3D. Why?
All you need to do is figure out what makes Direct3D fast. What corners did
they have to cut in order to bring the performance of the rendering up to
speed? Once you know that, add a fast path to your OpenGL that will cut the
same corners, if necessary adding a new GL_HINT to enable these that game
developers can use.
>>comparisons between current and previous releases of the same API.
>Because of the misperception that Microsoft's OpenGL software implementation is
>slow, we've needed to spend a lot of bandwidth addressing that comparison.
>(And now, unfortunately, I'm going to have to start spending time addressing
>the comparison between Microsoft's OpenGL and SGI's Cosmo GL.)
CosmoGL and Microsoft OpenGL do not have to compete against each other.
They can be completely complimentary, and provide the user with a solution
that gives them the maximum performance on their system. They can try one
or the other, and use whatever gives them the best performance with their
applications. You can't do this with Direct3D.
>Our goal is not to "blow the doors off of Direct3D", however, and if that's
>SGI's standard for whether or not to make a product of Cosmo GL, SGI will have
>to solve the coexistence issues some other way. If SGI wants a version of
>OpenGL which will compete with Direct3D, that's their business. My concern,
>again, is that they are, in *many* ways, undermining Microsoft's own OpenGL
>program in the process.
So what exactly *is* Microsoft's OpenGL program? Surely Microsoft's primary
goal for OpenGL would be to make it as fast as possible on Microsoft
operating systems? Surely a goal of attaining the same performance levels
as Direct3D (and surpassing it for hardware based systems) is a good goal,
is it not? Perhaps you can explain to me exactly *why* it is a bad thing
for OpenGL to run as fast or faster than Direct3D?
>Well then, not to be categorical, I can tell you this much: one of our best
>engineers has very carefully hand-crafted triangle setup Pentium assembler code
>for our OpenGL pipeline. The Direct3D triangle setup, which was also very
>carefully crafted by another top-knotch engineer, is substantially faster.
>There is simply less vertex state to compute, less to put over the bus, and
>what there is to compute is easier to compute given the precision trade-offs.
Well if it is so difficult, then how come SGI has been able to implement a
version of OpenGL in software that *does* run as fast as the Direct3D
software rasteriser?
The whole point of this discussion is that SGI is basically proving a lot
of the misperceptions that Microsoft has been publicly proclaiming about
OpenGL and Dircet3D to be false. No-one likes egg on their face, and if
CosmoGL proves that OpenGL can be as fast as Direct3D in software,
Microsoft has a lot of egg on it's face.
Regards,
+--------------------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+--------------------------------------------------------------------------+
| Kendall Bennett, Software Engineer | Email: Kend...@scitechsoft.com |
| SciTech Software USA | Fax : (916) 894 9069 |
| 5 Governors Lane, Suite D | ftp : ftp.scitechsoft.com |
| Chico, CA 95926, USA | www : http://www.scitechsoft.com |
+--------------------------------------------------------------------------+
Jeff Millar
m...@woodsy.asd.sgi.com (Mark Kilgard) wrote:
>In article <502il7$f...@news.microsoft.com>, swr...@microsoft.com (Stephen H.
>Wright) writes:
<...lotsa good stuff clipped...>
>Honestly, I'd guess that the decoding of Direct3D's execute buffers is doomed
>to be always done on the machine's host CPU. This likewise dooms Direct3D
>to be limited to the host CPU's speed with little chance to offload substantial
>work to the graphics hardware. Direct3D is a very short-sighted design.
Looking forward a few years to when symmetric multiprocessing
proliferates (quad pentium pro on a single die, for example), just one
of those processors can handle the execute buffer software thread with
ease. Estimates show that vertix calculations for high fidelity
texture mapped triangle scenes require 20-50 MIPS sustained.
What's difficult in hardware today becomes feasible in software
tomorrow, the impossible takes a little longer.
<...more clipping...>
jeff millar
Kendall Bennett
ho...@microsoft.com (Hock San Lee) wrote:
>>There are tens of millions of machines in the field that don't support
>>MMX, so good performance for machines without MMX is interesting to a
>>lot of people. I agree that MMX is important for new machines.
>Do you have a release plan for MMX support?
In my view MMX support is just a bunch of useful instructions added to the
Penitum architecture. It certainly is interesting, however for mainstream
applications I don't believe the interest is going to peak until about
12-18 months from now, and even then only a small percentage of the market
is going to be exposed to it.
Will it be interesting for commodity 3D? Not likely in the near future,
because Intel currently plans to ship it in Pentium 200 and Pentium Pro 200
CPU's. How many commodity 3D gamers do you think will be rushing out to
purchase a brand new Pentium 200 just so that they can get MMX support?
Surely purchasing a $250 3DFx Vodoo or Rendition Verite is a more cost
effective solution in the short term?
>Based on our experience, a well written MCD can outperform an average ICD.
>The investment on a good ICD implementation is so huge that it presents a
>significant barrier to entry for most commodity hardware vendors.
>Microsoft invests in MCD technology to make high performance OpenGL
>hardware available to commodity PC. For instance, the sample MCD has
>about ~10K lines of optimized code provided by Microsoft while the sample
>ICD has about 75K lines of un-optimized code provided by SGI.
Well this is very easily solveable. Why doesn't Microsoft make available to
OpenGL hardware vendors for the PC the 75K of 'highly optimised' and Intel
targetted code that it has in it's current OpenGL libraries? Surely
Microsoft could make available a new ICD kit for WinTel hardware vendors
that is not just a copy of the SGI sample source code (which we all know is
intended as a porting tool, not as a high performance reference
implementation for all machines).
An MCD solution is a cost effective solution for commodity 3D vendors, but
a highly optimised ICD sample implementation from Microsoft for vendors
wanting all out performance with OpenGL would probably go a *lot* farther.
>The next
>version of MCD will target geometry hardware. The development time for a
>well written MCD is generally fewer than 6 months as compared to many
>years of development required to write a good ICD.
Dooh. Surely the above statement must make you realise that *you* can cut
the development time in half for a hardware vendor wishing to build a high
performance ICD by providing them with optimised sources, not just SGI
sources? Extending the MCD architecture to support geometry acceleration is
likely to be an extercise in futility I would think. OpenGL was designed
from the start to be an API that translates almost directly to hardware
calls on systems with full geometry acceleration.
>We'd rather not have to respond to many of your public claims. These
>unsubstantaited (Cosmo OpenGL) claims only confuse developers.
You know, the whole market confusion has stemmed from Microsoft's own
indecisiveness about just what is the 3D API of choice on the WinTel
platform. For some strange reason you guys seem to think that high end CAD,
visualisation and medical imaging applications don't require the same sort
of performance that interactive 3D gaming titles do. WAKE UP! These
applications have been demanding more and more performance since the dawn
of 3D.
As Allen has pointed out, you guys need to look into your own marketing and
promitional material for Direct3D; that is why developers are confused
about how OpenGL fits into the picture.
>We already have first-rate OpenGL software/hardware implementations on our
>platform based on current benchmarks.
Many of us want a really good, fast OpenGL for the WinTel architecture. The
previous implementation was lacking in performance, and I certainly hope
that the new version is as fast you claim. As Allen said, if you can get
OpenGL running as fast or faster than Direct3D, everyone in this newsgroup
would be happy as pie.
Regards,
Michael I. Gold
swr...@microsoft.com (Stephen H. Wright) writes:
| I think the problem here may be your concept of "viable" and "competitive."
| We think we're providing an extremely competitive OpenGL for the Windows
| platforms. We *have* talked about that, but talking hasn't yet changed SGI's
| plans. My sense is that you want OpenGL to be a competitive, if not the
| leading, 3D API for games as well as professional 3D (as in your remarks about
| wanting Microsoft's OpenGL to blow the doors off Direct3D).
Certainly, the developer community can benefit from having a single high-
performance, portable API. The position from Microsoft seems to remain,
"use OpenGL for precision/portability, and use Direct3D for performance."
I believe one API can address both concerns.
| You missed my point, so let me try to state it again more directly. Microsoft
| is offering a premiere OpenGL implementation across its entire product line.
| We offer:
|
| + Industry leading software performance
| + A rich and rapidly expanding IHV market of hardware accelerators and OEM's
| + Multiprocessor and RISC support
| + A growing family of ISV's in many professional 3D markets
I applaud the efforts of the Microsoft OpenGL team. The new release is quite
improved over the previous version. I would argue that it can be better still.
| In spite of all that, SGI is offering a new implementation which will
| undoubtedly have industry leading color index mode performance, but whose
| performance is apparently otherwise untested. There is no accelerator or RISC
| story in place, and there are no ISV's signed up.
Not to beat a dead horse, but as long as you post this kind of misinformation,
I will feel compelled to respond. Cosmo OpenGL has optimized RGB paths as well
as Color Index paths. You seem willing enough to accept that the latter is
true without benchmarks, but at the same time refuse to believe the former.
If you base this on the SIGGRAPH demo, let me just say that we chose to
demonstrate Cosmo vs. Direct3D in ramp mode because to show the same
comparison in RGB mode would have more heavily favored OpenGL, and given MS
the ability to argue "Foul! Direct3D's strength is ramp mode!" So we showed
Direct3D in its best light, and beat it.
| I've got some very strong personal feelings about these issues, and I don't
| think I have the authority within Microsoft to be addressing them as a
| Microsoft representative, so I'm going to put that hat off for a moment and
| simply speak personally for a minute.
|
| I don't believe API control is as big an issue as you appear to believe. For
| one thing, I'm pretty happy with the amount of influence Microsoft has over
| OpenGL. The argument could be made that of the seven permanent ARB members -
| SGI, Evans and Sutherland, Digital Equipment, IBM, Intergraph, Intel, and
| Microsoft -- that six of them have substantial interests in Microsoft
| operating systems, that only five have substantial interests in UNIX
| operating systems, and that only one has substantial interests in SGI
| operating systems. SGI is (currently) the technology leader, but Microsoft
| carries a lot of weight.
Unfortunately your position as marketing manager for *both* OpenGL and
Direct3D compromises your ability to remain objective. It is quite plain
to see that Microsoft benefits from promoting yet another proprietary API -
once written for Direct3D, and application is more difficult, and thus less
likely to be ported to a competing platform.
| >| ...(Will you keep pace with our future
| >| extensions? ;-) )
| >
| >If Cosmo OpenGL is widely used, you might have to keep pace with ours. :-)
|
| That's ok. We'll just ask for them under the terms of our license agreement.
| :-))!
And we'll be happy to provide them.
| The SGI story, then, is that there's a library which runs really fast in
| software ramp mode (for which there are currently relatively few applications),
| which may or may not outperform the Microsoft software implementation, but
| which can't take advantage of any 3D hardware, from low-end S3 Virge cards to
| Intergraph RealiZm machines.
The SGI story is that there's a library which runs really fast in
software ramp mode AND software RGB mode, which is still important to a
very large audience of end users.
| I agree that Microsoft has not been consistently clear about the positioning
| of OpenGL and Direct3D, but I think we've been pretty clear -- with a couple
| of notable exceptions -- about OpenGL as the API for professional 3D
| applications.
This entire thread began with a confused developer trying to decide which API
would be best for his needs. The Microsoft position on this seems murky at
best.
| Do any of us -- OpenGL licensees, ISV's, end-users, IHV's -- really want to
| promote a low-precision mode for OpenGL to compete with other API's like
| Direct3D or RenderWare? I'm asking this seriously!
First of all, a "low-precision mode" for OpenGL is not necessary to make it
competitive with Direct3D. That's the message we delivered at SIGGRAPH. In
any case, unifying behind a single API would certainly reduce the amount of
work for Microsoft, which now has two completely independent API's to support,
as well as for IHV's and application developers. Secondly, if a "low-precision"
mode offers a significant performance advantage, then doesn't it only make
sense to persue this rather than create a whole new API?
Hock San Lee
In article <5053mk$t...@fido.asd.sgi.com>, go...@puck.asd.sgi.com says...
>
>ho...@microsoft.com (Hock San Lee) writes:
>
>| Today, our Millennium MCD driver is blowing away entry Indy's in
>| triangle benchmarks, even with a "translation layer" objected so
>| frequently by some SGI engineers. (Here is a challenge to SGI,
>| produce better entry Indy viewperf numbers than our published software
>| numbers ;-)).
>
>audience with the right hand while doing the dirty work with the left
>hand.
Since SGI is complaining loudly about our OpenGL performance, I think it
is only fair that you take a closer look at your own implementation. If
Indy is faster than our software implemention on benchmarks, then your
complain will be more legitimate.
>I cannot comment on Indy viewperf numbers since I have never seen them
>(nor looked for them). If this was even relevant to the discussion, I
>might point out the you mentioned the entry-level Indy, and there are
>several different configurations with dramatically different levels of
>performance.
Any entry-level Indy will be more expensive than the $3K DELL machine that
we published numbers on. Pick a $6K Indy and give us some CDRS, DX, DRV,
AW, LIGHT viewperf numbers.
>But the real point here, despite your attempted slight-of-hand, is how
>Microsoft's OpenGL compares with Direct3D. As far as anyone can tell,
>even your latest, greatest, fastest OpenGL 1.1 falls short of Direct3D
>performance.
Have you done any benchmark? Our internal RGBA measurement shows that
they are comparable. Note that this is not an apple-to-apple comparison
and "comparable" is as best as I can put it.
>So, how does your OpenGL compare with Direct3D on the Millennium MCD
>driver?
Based on feedback from one IHV, their OpenGL driver and Direct3D driver
are basically identical in performance.
I have spent enough time on this thread and hope that it has clarified
things for some of you. I don't think there is any more I can add to this
discussion so I will stop here.
Hock San Lee
Microsoft
Michael I. Gold
ho...@microsoft.com (Hock San Lee) writes:
| Since SGI is complaining loudly about our OpenGL performance, I think it
| is only fair that you take a closer look at your own implementation. If
| Indy is faster than our software implemention on benchmarks, then your
| complain will be more legitimate.
It would be easier if you clarified what you meant by "entry Indy".
As I said there are many configurations, some of which are several
years old. Comparing your current implementation against our old
implementation is hardly interesting. In any case, this is irrelevant
to the discussion.
| Any entry-level Indy will be more expensive than the $3K DELL machine that
| we published numbers on. Pick a $6K Indy and give us some CDRS, DX, DRV,
| AW, LIGHT viewperf numbers.
*Yawn*
We're talking about comparing performance between two API's on a
single box, which has nothing to do with price/performance. More
slight-of-hand, ehh?
| Have you done any benchmark? Our internal RGBA measurement shows that
| they are comparable. Note that this is not an apple-to-apple comparison
| and "comparable" is as best as I can put it.
So then I repeat my question - why two API's if performance is
comparable? Why confuse the developer base?
| I have spent enough time on this thread and hope that it has clarified
| things for some of you. I don't think there is any more I can add to this
| discussion so I will stop here.
I'll believe it when I see it.
Mark Kilgard
In article <5051fe$8...@news.microsoft.com>, ho...@microsoft.com (Hock San Lee)
writes:
|>
|> support
|> it, SGI will take a lot of heat from their (game) ISVs. If you look around,
|> all other
|> game APIs will be supporting MMX. This is important to game ISVs who are
|> choosing
|> between APIs. I claim that any game API that ignores MMX is doomed.
Wait a minute. Let's get the facts straight:
o Direct3D doesn't support MMX now.
o CosmoGL doesn't support MMX now.
o Microsoft claims they will support MMX for Direct3D in the future.
o SGI says CosmoGL will support MMX in the future if it makes sense.
I'm not sure what point you are making here. It sounds like everybody
is in the same boat.
Before Direct3D supports MMX, it seems like actually supporting NT
might be a higher priority. This is definitely an area where OpenGL is
far superior to Direct3D. Not only is OpenGL available for _both_
Windows 95 and NT today, you can get it for the Mac, OS/2, Linux,
and all major X workstations.
- Mark
head...@passport.ca
>Before Direct3D supports MMX, it seems like actually supporting NT
>might be a higher priority. This is definitely an area where OpenGL is
>far superior to Direct3D. Not only is OpenGL available for _both_
>Windows 95 and NT today, you can get it for the Mac, OS/2, Linux,
>and all major X workstations.
Mark,
It is this very wide availability and portability of the API that makes it
inferior in Microsoft's eyes. That they can't change it at will and control
it irks them considerably -- as demonstrated by the significant amounts
of cash they spend developing and promoting a competing API. An API
which has now been demonstrated (in spite of MS claims to the contrary)
to have no intrinsic performance benefit over OpenGL.
They must be pissed.
(And then there's this Talisman thing -- how the heck they're ever going to
effeciently (or otherwise) implement any _existing_ 3D api (including D3D) on that
hardware is quite an interesting question, don't you think? I'd bet money that
they'll invent yet another API for it. (Or hack D3D beyond recognizability --
amounts to the same thing really.))
Jon Leech
In article <DwxLu...@passport.ca>, <head...@passport.ca> wrote:
> (And then there's this Talisman thing -- how the heck they're ever going
>to effeciently (or otherwise) implement any _existing_ 3D api (including
>D3D) on that hardware is quite an interesting question, don't you think? I'd
>bet money that they'll invent yet another API for it. (Or hack D3D beyond
>recognizability -- amounts to the same thing really.))
APIs have to change to support new capabilities. You can't fault someone
for wanting to exploit the unique features of their hardware. Thus the
dozens of RealityEngine-specific OpenGL extensions from SGI, for example.
If I were to be concerned about any aspect of Talisman, it would be that
Microsoft may be able to use its con$iderable clout to standardize a
specific approach to image based rendering that may prove inferior in the
long run. Given their historical tendency to set and control standards, it
seems pretty likely they'll try. The field seems immature for this, though.
Followups to c.g.api.misc only.
Jon
__@/
Paul Miller
ho...@microsoft.com (Hock San Lee) writes:
>Today, our Millennium MCD driver is blowing away entry Indy's in triangle benchmarks,
>even with a "translation layer" objected so frequently by some SGI engineers. (Here
>is a challenge to SGI, produce better entry Indy viewperf numbers than our published
>software numbers ;-)).
Maybe that's because the Indy has no hardware acceleration for 3D
operations and the Millennium I believe at least does some setup in
hardware? Also, what systems are you comparing against? An entry 150Mhz
R4K Indy against a 200Mhz PPro isn't a fair comparison.
I'll tell you one thing though - I bet that Indy can fill pixels a hell
of a lot faster than that Millenium.
--
Paul Miller | pa...@elastic.avid.com
SGI Software Engineer | Opinions expressed here are my own.
Elastic Reality - a division of Avid Technology, Inc.
Kendall Bennett
swr...@microsoft.com (Stephen H. Wright) wrote:
>As I wrote yesterday, in RGB mode OpenGL is slightly faster in triangle fill
>and quite a bit slower in triangle setup. If you think your RGB
>pipeline is as fast or faster than Direct3D, please let *us* know!
I think that is what Allen has being trying to tell you; ComsoGL is not
just fast in ramp mode, but in RGB modes as well.
>We don't have a zippy ramp mode implementation in our OpenGL, but don't
>consider that to be very important, given the direction that hardware is going.
Ramp modes are very important for games implemented to run on software only
systems, and lets face it, software only 3D is going to be the choice for
over 40 million consumers this Christmas. Hardware 3D is an option, but you
are not likely to sell 40 million accelerators this Christmas (check the
analysts figures for this one, and they always overstate the figures).
BTW, if ramp mode is not very important, why is it that Direct3D puts such
an emphasis on ramp modes, and that all the Direct3D demos all run be
default in ramp mode since it is faster than RGB modes? Simple; it is
vitally imporant for systems withour any hardware 3D acceleration, and the
Direct3D folks know that this is important. You OpenGL folks need to wake
up and realise that it is also.
>My sense of the market today is that most people making cards for $1K and up
>are using ICD's and already have front-end technology that they consider to be
>"crown jewels". When they license our ICD kit, all they take is the escape
>mechanism interface layer that we use to call them from our OpenGL
>implementation.
One question. The escape model that is used to get from the user
application into the OpenGL drivers is a slow path for getting things done
very quickly. Obviously the escape mechanism is required if you are
implementing OpenGL over a network, but have you guys considered having the
OpenGL drivers run in user space if the display is running on the local
machine? That way you can avoid the escape mechanism entirely and have all
the rendering code (and hardware code; all I/O can be memory mapped and if
anything is I/O mapped, it is *is* possible to enable I/O for user space
code under NT) running directly in a user space DLL. Given that there is no
ring transition switching going on for all the calls, this would make a big
difference to the overall performance.
Note that I don't know the internals of your OpenGL implementation (for all
I know you may already do this ;-). But I do know that some vendors in the
workstation market take this approach when running on a local machine to
increase the performance.
>I mentioned yesterday that this was not suprising, based on the RGB comparisons
>we've made, with, however, the big caveat that your sense of the comparison may
>be biased by having used samples with relatively large triangles. Do you have
>both fill rate and triangle setup data (like the d3dtest output)?
As Brian Hook mentioned previously, real games in the real world actually
use rather large triangles for the exact reason that you state; setup time
is a significant overhead when rendering in software. Take a close look at
games like Quake and Duke 3D, and see how large the polygons are in those
games. In fact if you have access to the test version of Quake, you can
turn off the texture mapping and can see exactly how coarse the world
polygons really are (amazing what good textures can do eh ;-).
Also note that most of the commodity 3D accelerators currently shipping
(ATI 3D Rage, S3 Virge (yech), NVidia) are actually slower at rendering
small triangles in hardware than in software; another reason why real games
use larger polygons with detail textures.
>In any case, *I*'ve been saying for a long time (trading chest-beating for
>chest-beating!) that software performance tuning is of limited value with
>pervasive hardware acceleration coming along. We've been seeing the existence
>proof for that, now, too. The tuning you've done to the front end of the
>pipeline is potentially leveragable (as was ours) if you have a hardware driver
>story.
I will get up and beat my chest madly and tell you that software rendering
performance is *vitally* important to enabling the 3D hardware market. Fast
software rendering is what will get the consumers wanting more out of 3D
games, and eventually decide to make the upgrade to a 3D hardware
accelerator. However they need to get a taste of what they are missing
before they will do this, and fast software 3D titles is what is going to
do that (and already is). Do you think games like Quake and Duke Nukem 3D
would be successful if they were based on hardware acceleration only? Sure
they would be complelling games, but no-one would buy them because no-one
would have the hardware to run them.
Regards,
+--------------------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+--------------------------------------------------------------------------+
| Kendall Bennett | Email: Kend...@scitechsoft.com |
| Director of Engineering | Phone: (916) 894 8400 |
| SciTech Software, Inc. | Fax : (916) 894 9069 |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+--------------------------------------------------------------------------+
Kendall Bennett
swr...@microsoft.com (Stephen H. Wright) wrote:
>I think the problem here may be your concept of "viable" and "competitive." We
>think we're providing an extremely competitive OpenGL for the Windows
>platforms. We *have* talked about that, but talking hasn't yet changed SGI's
>plans. My sense is that you want OpenGL to be a competitive, if not the
>leading, 3D API for games as well as professional 3D (as in your remarks about
>wanting Microsoft's OpenGL to blow the doors off Direct3D).
Exactly! What is so bad about promoting OpenGL as the leading 3D API for
games and professional 3D? If it can be done (and SGI is intent of showing
you that it can) then you should embrace this wholly and run with it. A
single, pervasive 3D API of choice is exactly what the industry needs.
>Do any of us -- OpenGL licensees, ISV's, end-users, IHV's -- really want to
>promote a low-precision mode for OpenGL to compete with other API's like
>Direct3D or RenderWare? I'm asking this seriously!
Yes! The key is that it is a 'low precision mode', not a low precision
implementation. Only applications that wish to trade precision for
performance will get the benefits, and those applications will be games and
possibly VRML type applications.
One thing needs to be clear; Low Precision is necessary to ensure high
performance on softare only based systems, but a different API is not.
Stephen H. Wright
In *many* articles *many* people say ...
> ... [everything deleted for the moment]
I've really stirred up a hornet's nest with this one! And some of you know
from past experience that I sometimes enjoy doing that just to get feedback,
even if it's angry and hostile.
I'm looking at about a dozen postings and can't possibly respond to them all,
now, particularly if they keep coming through. I'm going to make a couple of
general statements here and try to respond to the more frequently repeated
arguments later today or over the weekend. If it keeps pouring in, I'll just
have to agree to let you swamp me! (It looks like Hock is getting burned out,
too!)
1) I'm really intrigued by responses from (non-SGI) folks who imply they'd
rather just use OpenGL for games development on the Windows platforms -- or who
at least think having a different API for games development is a really bad
idea. If any readers would prefer using OpenGL for games development, I'd like
to hear from them, through email (and here if you care to vent publically).
And I'd like to hear the reasons.
2) I'm also hearing a lot of anger and upset from people who think Microsoft
has relegated OpenGL to the back burner. This feedback falls into two
categories: feedback that we shouldn't even have D3D for the games market (and
my first bullet addresses that class); and feedback that the positioning is
confusing and creates the impression that we don't really even want OpenGL for
the professional 3D market.
I'm very interested in that side of things, too. I've worked very hard to
evangelize OpenGL for CAD, animation, modeling, visualization, simulation,
etc., both internally and externally. I would appreciate, now or in the
future, your letting me know (include email so I'll see it even if I'm out of
the office for a few days), instances where this message is getting muddied or
contradicted.
Thanks, and keep the letters coming!
Kyle Lussier
I am *very* happy with OpenGL for Windows 95/NT. It works
reliably, provides decent high-quality speed (which will be
improved with new hardware significantly), and gets
the job done.
A low-precision high-quality mode would be great,
*IF* it works completely within the normal API set
and is just a mode switch as opposed to a new
method of interfacing it. I.e., let us build our models
in high quality RGB and then change a mode setting
to access the fast mode. This would be ideal for
the type of application work I am doing. Additionally,
an ultra-high quality mode that implements some
ray-tracing and radiosity type features, all within
the same level of expertise.
OpenGL will succeed where Direct-3D fails if it
follows a scalable graphics methodology.
I.e.
Working Graphics --> Quality Graphics -->
Presentation Graphics.
This methodology is inherently tied to speed,
so the argument turns into the problem of
providing scalable frame rates tied to quality.
Solve this problem and OpenGL will remain
a powerful API for a long time.
Regards,
Kyle Lussier
Particle SMV Research Thrust
National Science Foundation ERC Affiliate
http://inside.net/silicon_softworks
Stephen H. Wright <swr...@microsoft.com> wrote in article
<502t9i$m...@news.microsoft.com>...
> Allen -
...
Brian Hook
> Looking forward a few years to when symmetric multiprocessing
> proliferates (quad pentium pro on a single die, for example), just one
> of those processors can handle the execute buffer software thread with
> ease. Estimates show that vertix calculations for high fidelity
> texture mapped triangle scenes require 20-50 MIPS sustained.
Good point, the NeXTDimension comes to mind.
Brian Hook
Stephen H. Wright wrote:
> 1) I'm really intrigued by responses from (non-SGI) folks who imply they'd
> rather just use OpenGL for games development on the Windows platforms -- or who
> at least think having a different API for games development is a really bad
> idea. If any readers would prefer using OpenGL for games development, I'd like
> to hear from them, through email (and here if you care to vent publically).
> And I'd like to hear the reasons.
Reasons to use OpenGL as a game development API:
1. Far more pervasive than D3D; in theory you can do game development on the same
system as your tools
2. HUGE installed base of experienced users, toolkits, software libraries, and
documentation.
3. Robust, proven API design.
4. Industry consortium controlled.
Reasons NOT to use OpenGL as a game development API:
1. Sucky software only implementations (so far) compared to doing your own rasterizer.
2. Stigma attached to OpenGL because of slow NT implementations and Unix background,
and the conventional wisdom that it's slow ("Anything written for Unix has to be slow").
One thing people aren't seeing is that many developers want a 3D API only because of the
hardware abstraction capabilities; id Software has stated that the D3D version of Quake
will NOT use the software rasterizer.
A generalized software renderer will ALWAYS be slower than a well written hardcoded
software renderer (e.g. Quake uses a piecewise linear, 8-bit, affine texture mapper that
doesn't support clamping and uses non-power-of-2 textures, with Z-buffering or with
Z-writes only). Abrash has gotten this rasterizer down to something like 6 or 7
clocks/pixel, which is pretty damn good.
I think a lot of the reason people are looking at D3D seriously is because it was
"Designed for Games", when in fact it's not that superior to OpenGL (if at all). I have
never seen a technical document that describes, lucidly, the performance advantages of
D3D over OpenGL. D3D has a lot of weight simply because it ISN'T OpenGL! Talk about an
easy battle to wage if that's all you need.
I think Servan or Doug should probably write up a technical paper along the lines of
Segal's paper on the design of the OpenGL API.
Brian
Kendall Bennett
>I should clarify this. Real games today tend to use larger triangles and
>texturing because commodity 3D accelerators are still coming on line today.
>Designers that Microsoft has talked to, however, consistently convey their need
>to be able to use much smaller triangles with hardware that can handle textured
>fills.
This is true, but also bear in mind that current commodity 3D solutions
that are shipping are very slow at rendering in hardware. Michael Abrash
told me privately that their softare rendering code in Quake is
significantly faster than the S3 Virge accelerator.
As things progress, the hardware will get better and faster. Hardware that
does not have full triangle setup on board and takes floating point
vertices is always going to be slower for this kind of thing. The Rendition
Verite, 3DFx Vodoo and the Permedia/Glint Delta chipsets all provide this
important feature.
>As this hardware becomes pervasive, I expect to see triangle setup dominate
>rendering for new games. There's a really interesting question posed by the
>development of hardware with triangle setup capabilities like the Permedia NT
>from 3DLabs. As and when *that* class of hardware becomes pervasive, I would
>expect it to significantly level the playing field between *all* the 3D API's
>when it comes to rasterization performance.
Entirely true. With a 3D rasteriser such as a 3DFx Vodoo or Rendition
Verite, no doubt you will find that Direct3D and OpenGL will possibly
perform at almost exactly the same level.
When the next level of 3D accelerators hit the consumer marketplace with
full geometry acceleration, you will find that OpenGL will suddenly leap
ahead of Direct3D and will be a much higher performance API for this type
of hardware. Considering how quickly the graphics hardware industry is
moving, I would suspect we will see this type of hardware at consumer
prices a lot quicker than many would imagine.
Kyle Lussier
> Vis-a-vis Microsoft OpenGL, I am extremely concerned that, in an effort
to
> establish OpenGL as a credible games 3D API, SGI may actually undercut
OpenGL's
> momentum in the PC market.
I think that any attempt to qualify OpenGL as a games 3D API would
not undercut any OpenGL momentum. In using OpenGL as a developer,
my biggest concern in the back of my head was that it wouldn't have
the higher end "working graphics" model for live visualization. Like
I mentioned in another message, it is critical for OpenGL to have
scalable speed between "Working" or "Games" graphics and
"Presentation" level graphics. It is decent at quick presentation
graphics. It is currently not completely acceptable in "Working"
graphics. The base idea of OpenGL is that it is an "Open Graphics
Language" meant to provide functionality to all levels.
> 4) There are unresolved issues around how CosmoGL coexists with Microsoft
> OpenGL on Windows platforms. For example, it would be unacceptable for a
naive
> user with a hardware accelerator to install an SGI 3D app from the web,
> unknowingly pick up CosmoGL as part of this process, and be stuck with
> software-rendering performance. It would be even worse if that resulted
in
> breaking hardware acceleration support for OpenGL-based applications.
This is a very true issue, and (from your guys side) probably a technical
quagmire of problems.
Doug Rabson
m...@woodsy.asd.sgi.com (Mark Kilgard) writes:
> [...]
>
> Wait a minute. Let's get the facts straight:
>
> o Direct3D doesn't support MMX now.
Current betas of DirectX support MMX for RGB rasterisation. The MMX
RGB renderer is faster than the ramp renderer on the same hardware.
In addition, it is more accurate (subpixel correct). DirectX 3 is
due to ship in the next couple of weeks and will include this
technology.
--
Doug Rabson, Microsoft RenderMorphics Ltd. Mail: d...@render.com
Phone: +44 171 734 3761
These are not the opinions of Microsoft. FAX: +44 171 734 6426
David Blythe
In article <DwxLu...@passport.ca> head...@passport.ca writes:
>
>>Before Direct3D supports MMX, it seems like actually supporting NT
>>might be a higher priority. This is definitely an area where OpenGL is
>>far superior to Direct3D. Not only is OpenGL available for _both_
>>Windows 95 and NT today, you can get it for the Mac, OS/2, Linux,
>>and all major X workstations.
>
>Mark,
>
> It is this very wide availability and portability of the API that makes it
>inferior in Microsoft's eyes. That they can't change it at will and control
>it irks them considerably -- as demonstrated by the significant amounts
>of cash they spend developing and promoting a competing API. An API
>which has now been demonstrated (in spite of MS claims to the contrary)
>to have no intrinsic performance benefit over OpenGL.
Actually Microsoft can extend OpenGL as they see fit, by adding Microsoft
specific extensions. That is one of the nice things about OpenGL as an
open standard; vendors can extend it as necessary to support new features
as they develop them. On a more pragamatic side, licensees are encouraged to
share extension information so that the API remains consistent and (hopefully)
clean. OpenGL 1.1 is the result of the first round of integrating various
vendor extensions into the core functionality.
-db
>
>
> They must be pissed.
Holger Grahn
Mark Kilgard wrote:
>
>
> Does any hardware actually work as you describe?
>
> There are a number of problems with the Direct3D hardware you describe:
>
> o Direct3D's execute buffer protocol is exposed to the application
> (indeed, application supposed to use C macros to write into the buffer)
> meaning that a graphics hardware accelerated for Direct3D is forced
> to implement this same protocol.
.. ..
Yes actually you need to write your own API (probably GL like) or
wrappers
to fill the execute buffers.
>
> o Sure, you could "send the buffer to the hardware like a display list",
> but if the application modifies the buffer again, you'd have to resend
> the entire execute buffer to the hardware since the execute buffer
> could have arbitarily changed.
Probably Direct3d want you to keep the application data in the execute
buffers.
E.g. the twist example ownly works with transformations coded inside an
execute buffers,
how performance change, if the execute buffer is filled each time.
Hopefully Locking and Unlocking a execute buffer must not be expensive,
because the buffer
could retain in video memory and the locks returns a pointer into video
memory ?
>
> o Because Direct3D's vertex list in its execute buffer is accessed by
> indices, the hardware has to maintain the entire vertex list downloaded
> in the hardware. This could be fairly large.
This is actually not so bad, because all vertex data can be transformed
and lit in one
step. In OpenGl has to transfrom each or at least every 3rd vertex
(using tristrips).
The problem is also that theirs is a upper limit on exectue buffers,
what if your
object doesn´t fit into an buffer ? How to split the triangles without
loosing the vertex
sharing.
>
> o Direct3D's execute buffers don't all good pipelined parallelism between
> the host CPU and the graphics hardware. While the host is updating an
> execute buffer, it cannot be being executed by the graphics hardware.
> Fast graphics hardware would end up being stalled while the CPU is
> filling the next buffer.
But depending on the granularity one buffer could be exectuted by the
hardware,
the other is locked and can be filled by the application.
Beside the unusual, not to say strange and difficult to handle Direct 3D
API and the limited documentation
here are other serious limitations of Direct 3D as far I have
encountered them :
- no support for vertex color
- no support for the gl color material feature, to replace only the
diffuse color channel
of the material. (big problem if you want to give each face a
separate color)
- no support for texture coordinate transformation matrix !
- the sample applications recreates the 3D devices and flushes all
Execute Buffers on
every window resize ! So window resize must be very slow with Direct
3d
- according to doc support for the change of culling mode is optional.
--
###################################################
Holger Grahn
h...@berlin.snafu.de
http://www.snafu.de/~hg
http://194.64.64.1/~hg
head...@passport.ca
>> It is this very wide availability and portability of the API that makes it
>>inferior in Microsoft's eyes. That they can't change it at will and control
>>it irks them considerably -- as demonstrated by the significant amounts
>>of cash they spend developing and promoting a competing API. An API
>>which has now been demonstrated (in spite of MS claims to the contrary)
>>to have no intrinsic performance benefit over OpenGL.
>
>Actually Microsoft can extend OpenGL as they see fit, by adding Microsoft
>specific extensions. That is one of the nice things about OpenGL as an
>open standard; vendors can extend it as necessary to support new features
>as they develop them.
Come on David, this is the net -- you're confusing the issue with relevant
facts. I thought that was against the rules :-) (Oh that's right, this is an anarchy,
and hence the lack of rules.)
I suppose it's not the 'extend at will' thing that bugs MS about it, but the fact that
it doesn't lock people in to Windows or some other MS controlled OS.
>On a more pragamatic side, licensees are encouraged to share extension
>information so that the API remains consistent and (hopefully)
>clean. OpenGL 1.1 is the result of the first round of integrating various
>vendor extensions into the core functionality.
> -db
Yeah -- it's not so bad. I'm not so sure about recent additions to glx though.
fb_config in particular. I hope things don't fall into the "select a visual API du jour"
syndrome. (oops -- sorry, but the last one didn't quite work for some new OpenGL
extensions, care to try this API instead?) Yes, I do realize how mind numbingly
difficult it is to design API's that extend and scale well in the future, and in general
how good OpenGL is in this regard, but I just like complaining sometimes and that
was all I could come up with at the spur of the moment :-)
That said, I don't think that fb_config is going to stay unreplaced or unchanged
for too long -- hence the SGIX at the end of the API name I guess.
Reto Koradi
Stephen H. Wright wrote:
> 1) I'm really intrigued by responses from (non-SGI) folks who imply
> they'd rather just use OpenGL for games development on the Windows
> platforms -- or who at least think having a different API for games
> development is a really bad idea.
I think that it's generally a bad idea to have different APIs without
good technical reasons. After following this discussion closely, I'm
not at all convinced that there are such reasons for having both
DirectX and OpenGL. The requirements for games and fields like CAD
or scientific visualization seem similar enough for one single API
to handle them. If there are additional possibilites or options
(like low precision rendering) needed for games, they can be
introduced into OpenGL with extensions or additional hints.
On the other hand, having one single API has obvious advantages,
just a few examples:
- software scalability and portability
- education (less learning, more qualified people)
- smaller development efforts for OS vendors
- smaller development efforts for graphics hardware vendors
- less confused software developers
I see only two reasons why Microsoft should "make their own":
1. They think that they can do something better than OpenGL.
2. They want to have full control, trying to monopolize another
field and forcing other vendors out of the market.
I just don't believe in point 1, the designers of OpenGL did
excellent work, and the important contributors (SGI) have a proven
track record in 3D graphics.
Point 2 is an impression that many people have, and I don't think
that Microsoft should be too happy about it. A clear statement for
one single 3D API supported by multiple vendors (OpenGL) would go
a big step towards working against such a reputation, and would be
of benefit for the whole industry.
--
Reto Koradi (k...@mol.biol.ethz.ch, http://www.mol.biol.ethz.ch/~kor)
Jeff Martyn
I am currently working for a Games Development company that is debating
between Direct3D and OpenGL.
Currently all the programmers prefer OpenGL, the reasons.
OpenGL is much easier to learn and get going quickly not just because the
API is simpler and the model more logical but because their is a wealth of
background information and reference material.
I realize the books on Direct3D are forthcoming but that doesn't help us
this week.
However the main problems with using OpenGL for games are:
It is too slow.
There is a question of how it will coexist with other Microsoft APIs:
DirectSound, DirectPlay .. which we must use.
My question to Microsoft and SGI is how can we get ahold of the new faster
OpenGL's that you have developed.
I need to run side by side tests, as our product (targeted for next Jan98)
must run on a minumum 75Mhz Pentium.
Can you help or direct me ?
Thanks,
Stephen H. Wright <swr...@microsoft.com> wrote in article
<507edb$c...@news.microsoft.com>...
> In *many* articles *many* people say ...
> > ... [everything deleted for the moment]
>
> I've really stirred up a hornet's nest with this one! And some of you
know
> from past experience that I sometimes enjoy doing that just to get
feedback,
> even if it's angry and hostile.
>
> I'm looking at about a dozen postings and can't possibly respond to them
all,
> now, particularly if they keep coming through. I'm going to make a
couple of
> general statements here and try to respond to the more frequently
repeated
> arguments later today or over the weekend. If it keeps pouring in, I'll
just
> have to agree to let you swamp me! (It looks like Hock is getting burned
out,
> too!)
>
> 1) I'm really intrigued by responses from (non-SGI) folks who imply
they'd
> rather just use OpenGL for games development on the Windows platforms --
or who
> at least think having a different API for games development is a really
bad
> idea. If any readers would prefer using OpenGL for games development, I'd
like
> to hear from them, through email (and here if you care to vent
publically).
> And I'd like to hear the reasons.
>
Michael I. Gold
"Jeff Martyn" <Jeff....@worldnet.att.net> writes:
| My question to Microsoft and SGI is how can we get ahold of the new faster
| OpenGL's that you have developed.
| I need to run side by side tests, as our product (targeted for next Jan98)
| must run on a minumum 75Mhz Pentium.
| Can you help or direct me ?
You can get a copy of Microsoft's latest release for Win95 from:
ftp://ftp.microsoft.com/Softlib/MSLFILES/Opengl95.exe
This release is significantly faster than the previous release from
Microsoft.
If the new Microsoft implementation is still not fast enough for you,
we will be making an initial release of Cosmo OpenGL available in
mid-September.
Lyle Meier
>Maybe that's because the Indy has no hardware acceleration for 3D
>operations and the Millennium I believe at least does some setup in
>hardware? Also, what systems are you comparing against? An entry 150Mhz
>R4K Indy against a 200Mhz PPro isn't a fair comparison.
>
Whats the price ratio of the two systems. If its about the same, and
I suspect it is as a PP system with a Millenium is in the 3-6k range
depending upon what else is included, then its a fair comparison, assuming
the indy still is being sold.
Mark Kilgard
In article <322765...@asd.sgi.com>, Brian Hook <bh...@asd.sgi.com> writes:
|> In article <5055j3$8...@butch.lmsc.lockheed.com>,
I'm not so fast to grant this point. The point that I'm arguing against
is that somehow Direct3D's execute buffer scheme is specially amenable to
acceleration via multiple host processors (it doesn't have to be particularly
symmetric). It's not really, nor is such an approach cost/performance
effective.
Yes, you could harness multiple host CPUs (ie, dual Pentiums or such)
for the execution of Direct3D execute buffers. But let's consider
two critical questions:
o Is an execute buffer scheme specially superior for a multiprocessor
implementation scheme? Specifically, let's compare it to OpenGL's
immediate batched model.
You could architect an OpenGL implementation that involved one host
process "feeding" immediate batched OpenGL commands to a separate
process on a second host processor. In conjunction with OpenGL
display lists, you could arrive at an OpenGL implementation that
was able to achieve basically the same multiprocessor performance
that Direct3D might able to achieve.
There's nothing uniquely advantageous about Direct3D's architecture
that would give it an advantage. With this said...
o In practice, is such a a scheme even an advantage?
Consider the economic issues why not:
A specialized 3D geometry processor is typically 3 to 4+ times cheaper
than an equivalent general purpose processor for equivalent FLOPS.
Additionally, because a 3D geometry processor is specilized at its
task, it tends to sustain geometry transformation speeds much closer
to the processor's peak floating point performance.
These economics are not likely to change since the general purpose
processor has to be good at general purpose things. The 3D processor
will continue to have its economic advantage due to specialization.
Consider the technical issues why not:
If the processors are connected in a useful way for non-graphics uses
(I'm assuming that they would be), the processors will need to
communicate through a cached, but cache coherent memory system. This
extra cache and consistency overhead really just slows down
communication throughput between the two processors when compared to
a processor feeding a specialized graphics subsystem through a fast
bus interface (ie, an interface without memory consistency constraints
and designed for high performance feeding of a consumer).
Consider the balance issues that occur:
If your second processor does all the 3D transformation of execute
buffers, that can leave your primary processor to accomplish more
application dependent work like constructing more execute buffers,
etc. But when this application-dependent work is small relative
to the time spent rendering the execute buffer, you end up with
your primary processor paused. The other alternative is that your
primary processor takes more time than the time spent rendering
the execute buffer. Now, your secondary processor ends up paused
for sometime. It turns out that it is very unlikely to have a well
balanced application. Consider though that if you build specialized
3D hardware, you can design the hardware itself to be balanced with
respect to the host processor speed.
Consider the historical evidence against such an implementation:
Multiprocessor graphics workstations have existed for a long time.
Despite this, few have implemented such a scheme (Integraph may do
something along these lines in its current products for OpenGL).
My assessment is that when multiprocessing capabilities are
available, you'd prefer to use them for higher-level tasks than
actual rendering (a task so well suited for specialized 3D hardware).
Instead, you use the multiple processors for things like application-
level culling, device handling, general application processing,
intersection detection, asynchronous file I/O, on-the-fly morphing,
and such. Using your expensive general purpose processors for
something as specialzied and straightforward as 3D transformation
and rasterization turns out to not be very cost effective.
Direct3D Immediate Mode's execute buffer scheme could be implemented
with a multiprocessor model, but there's nothing that makes such a model
uniquely or specially suited to an execute buffer scheme. Also, such
a model is not likely to be economically or performance competative
with a specialized 3D processor.
- Mark
Mark Kilgard
In article <322995...@spectrospin.ch>, Reto Koradi <k...@spectrospin.ch> writes:
|>
|> I see only two reasons why Microsoft should "make their own":
|>
|> 1. They think that they can do something better than OpenGL.
|> 2. They want to have full control, trying to monopolize another
|> field and forcing other vendors out of the market.
There's no need to suspect conspiracy when a simple misunderstanding
within Microsoft would suffice to explain.
Here are two other reasons to consider:
3. Microsoft marketing doesn't understand 3D interactive
graphics. They wrongly believe that "entertainment" 3D is
somehow vastly different from "CAD or scientific" 3D - enough
to justify two completely different low-level APIs.
The two types of 3D are really just two markets for the same
technology. Yes, they have different priorities, but their
basic required functionality is the same. Nobody would argue
that 2400 baud modems should have a completely different
programming interface from 9600 baud modems and faster.
Oddly, that is what Microsoft marketing appears to be claiming
for 3D.
4. Microsoft bought RenderMorphics. The Reality Lab API that has
become Direct3D's retained mode is a decent enough higher
level 3D API. Microsoft recognized that the retained mode was
really not sufficient for a lot of games which would demand
more control. Microsoft did the expedient thing and promoted
an internal Reality Lab interface into a public low-level
API. While the Reality Lab internal interface is a nice, fast
host-based software renderer, it is not the kind of interface
you want to support for years. The interface is rather poorly
suited for hardware acceleration compared to OpenGL.
Microsoft didn't have a fast OpenGL at the time, so
retargeting the RealityLab retained mode API to OpenGL wasn't
even viable within the timeframe Microsoft wanted to release
Direct3D.
Is Microsoft marketing wrong about the 3D market? Definitely. 3D is
totally new to them; they don't know enough to understand what they are
talking about. Supporting two APIs that provide the same basic
functionality is a terrible move in the long term.
I'll hedge my blanket criticism by saying that I believe Hock and Steve
at Microsoft actually do understand 3D. If I understand their comments
correctly, they seem a bit caught off guard by just how odd the
Microsoft marketing story on 3D APIs truly is (use 2 different 3D
APIs: OpenGL = slow, precise for CAD; Direct3D = fast, sloppy for
games). I sympathize with their attempts to defend it.
In the end, Microsoft's story to learn and use 2 different low-level 3D
APIs just doesn't make sense. My guess is that Direct3D's retained
mode will be interesting for a fair number of 3D apps that want a
high-level 3D interface. OpenGL will become the low-level 3D interface
of choice. Direct3D's immediate mode will continue to be supported,
but it will become an anchronism the way WinG did (Microsoft's last
attempt to solve the "PC game problem"...). And, Microsoft will
(rightfully) claim that they supported OpenGL from the very beginning.
--
BTW, one thing that I've got to comment on is the attacking nature of a
lot of the recent comparsions between SGI workstations and PCs. I find
it largely unbecoming and believe the criticisms totally fail to
appreciate what's truly exciting about interactive 3D today. Here's
what I mean:
It is indeed quite exciting that PCs are finally demonstrating
reasonably interactive 3D graphics. It is exciting not just because
lots more people will be benefitting from 3D applications on PCs
(that's certainly exciting!), but it also means that there's a whole
new demand for the creation of 3D content and tools. Let's be honest:
Silicon Graphics has played an important role in this state of
affairs. In addition to developing 3D from a niche market into one of
the world's leading computer lines, SGI developed and openly
standardized OpenGL as the best low-level interface for 3D. SGI
worked to establish OpenGL not just for workstations, but throughout
the computer industry (Cray, Microsoft, Intel, DEC, and Microsoft were
all early OpenGL adopters).
The reason for standardizing OpenGL wasn't that SGI believed it could
dominate the entire 3D market. The vision was that by having a common
3D programming interface across the entire range of computing, 3D would
rapidly expand from a niche technology to a fundamental computing
capability. You can see this happening today. As an example, SGI's
development of a free "faster than Microsoft" software-based PC OpenGL
is part of this vision.
By helping to establish the broad PC market, SGI believes it can
continue to do what it does well: create the fastest and most
innovative 3D graphics products on the planet. The idea is not to
dominate 3D everywhere, but to be the company that leads, and through
that lead, commands a premium for its computing products. I'll be
honest: SGI wants the high-value, high-margin portion of the 3D market
that SGI requires to sustain its unique business model. That said, a
huge mass-market for 3D is definitely vital for SGI's continued growth,
even if SGI does not participate directly in that broader market.
With this understood, SGI's current products do exactly what SGI
intends. IMPACT, RealityEngine, and InfiniteReality are clearly
unrivaled products in each's graphics performance range. They are the
products with which every 3D competitor tries to compare. Many users
in high-end CAD, visual simulation, film & video production, scientific
visualization, medical and defense imaging, 3D content production, and
other performance-oriented graphics markets find that these machines
solve their problems better than any other available hardware. At a
lower-price point, Indy makes available a binary-compatible workstation
with the same basic 3D capabilities and the built-in capability for
manipulating digital media like video.
The fact that PCs are getting better at 3D is an unqualified Good
Thing. SGI needs this to be true; SGI's customers want this to be
true. Nobody wants 3D to be a niche anymore. The idea that PCs are
"catching up" with SGI workstations is what many would like to believe,
but its just not the case. If you take an informed look at the
machines SGI has released in the past year (particularly IMPACT and
InfiniteReality), you'll see machines that aren't just rendering
polygons fast. They are doing new classes of operations like
convolutions and 3D texture mapping that open up whole new categories
of applications.
If you concentrate only on dollars/polygon/second, you are missing the
point since you are asking an SGI workstation to compete on the basis
for a benchmark that is years too old for many of the newer workstation
applications. Feel free to make the comparison; SGI workstations
continue to perform extremely well on such benchmarks, but don't be
oblivious to the new capabilities and their corresponding markets that
today's SGI workstations are enabling.
My point is really that if you squabble over meaningless metrics like
dollars/polygon/second of PCs versus SGI workstations, you are missing
the real point. Few to no one buys machines purely on that basis. I'm
happy when someone reports that PCs are getting faster at 3D. Is it
eroding SGI's market in high-value 3D? No way. It expands it; check
out SGI's growth rate and profit model if you need any proof. But,
please think before making mindless dollars/polygon/second comparisons.
- Mark
Richard Krehbiel
m...@woodsy.asd.sgi.com (Mark Kilgard) writes:
> In article <322995...@spectrospin.ch>, Reto Koradi <k...@spectrospin.ch> writes:
> |>
> |> I see only two reasons why Microsoft should "make their own":
> |>
> |> 1. They think that they can do something better than OpenGL.
> |> 2. They want to have full control, trying to monopolize another
> |> field and forcing other vendors out of the market.
>
> There's no need to suspect conspiracy when a simple misunderstanding
> within Microsoft would suffice to explain.
>
> Here are two other reasons to consider:
>
> 3. Microsoft marketing doesn't understand 3D interactive
> graphics. They wrongly believe that "entertainment" 3D is
> somehow vastly different from "CAD or scientific" 3D - enough
> to justify two completely different low-level APIs.
If you want to talk about market misunderstanding, it seems to me that
neither MS nor SGI understand the games market.
Game developers want the thinnest possible hardware abstractions. If
there's an OS or API there at all then it's likely perceived as more
of a hindrance than a help ("how do I prevent a task switch or
interrupt from sucking away CPU cycles while I'm rendering?"). The
popular delivery platform for PC games is a 32 bit DOS extender and
VESA VBE.
I believe VESA is currently developing a hardware 3D abstraction
similar to VBE, leaving software-only 3D rendering to the talent of
the game developer where it rightly belongs. You, MS and SGI: If you
want to sell to game developers, beat that.
--
Richard Krehbiel, Kastle Systems, Arlington, VA, USA
ri...@kastle.com (work) or ri...@mnsinc.com (personal)
Stephen H. Wright
In article <50fvte$l...@uuneo.neosoft.com>, lme...@sam.neosoft.com says...
The Millenium does not have hardware setup. You can get a 32Mb 200MHz PPro
system with an 8Mb Millenium for just under $3K.
Stephen H. Wright
Jeff Martyn -
You can get our Win95 libraries from:
ftp://ftp.microsoft.com/Softlib/MSLFILES
and get: Opengl95.exe
Thanks for the feedback on OpenGL and Direct3D!
Steve
In article <01bb98fe$139270e0$bea5...@599136721.worldnet.att.net>,
Jeff....@worldnet.att.net says...
>
>I am currently working for a Games Development company that is debating
>between Direct3D and OpenGL.
>Currently all the programmers prefer OpenGL, the reasons.
>
>OpenGL is much easier to learn and get going quickly not just because the
>API is simpler and the model more logical but because their is a wealth of
>background information and reference material.
>
>I realize the books on Direct3D are forthcoming but that doesn't help us
>this week.
>
>However the main problems with using OpenGL for games are:
>It is too slow.
>There is a question of how it will coexist with other Microsoft APIs:
>DirectSound, DirectPlay .. which we must use.
>
>My question to Microsoft and SGI is how can we get ahold of the new faster
>OpenGL's that you have developed.
>I need to run side by side tests, as our product (targeted for next Jan98)
>must run on a minumum 75Mhz Pentium.
>Can you help or direct me ?
>
Hock San Lee
There have been a lot of interesting discussions. I am going to add a
couple points to provide some perspectives:
OpenGL 1.0 has some weaknesses to be a viable game API. In particular, it
does not support texture object and vertex array performance extensions
required to write efficient and high performance games. These performance
problems were only addressed in OpenGL 1.1 spec completed last December.
Some people expressed an interest in using both color index and RGBA modes
in their applications. However, there are 2 problems: OpenGL does not
support texture in CI mode; application programming in CI mode is quite
different from RGBA mode. Even if these problems are solved, an
application will still not achieve platform portability and with hardware
support in this mode.
Hock San Lee
Microsoft
Michael I. Gold
ho...@microsoft.com (Hock San Lee) writes:
| OpenGL 1.0 has some weaknesses to be a viable game API. In particular, it
| does not support texture object and vertex array performance extensions
| required to write efficient and high performance games. These performance
| problems were only addressed in OpenGL 1.1 spec completed last December.
This is true. However, both features have been available as
extensions to 1.0 for a couple of years.
| Some people expressed an interest in using both color index and RGBA modes
| in their applications. However, there are 2 problems: OpenGL does not
| support texture in CI mode; application programming in CI mode is quite
| different from RGBA mode. Even if these problems are solved, an
| application will still not achieve platform portability and with hardware
| support in this mode.
Cosmo OpenGL supports a number of extensions for color index mode,
including texture mapping. We have offered these extensions to
Microsoft, and the offer remains open.
If color index mode proves critical for game developers (and the
Direct3D folks apparently are banking on this), hardware support may
be provided. What confuses me about your statement, however, is that
Direct3D faces the exact same issue. If hardware support is available
for ramp mode in Direct3D, it is also available for OpenGL. Again,
there is no inherent advantage to Direct3D here.
Since the soon-to-be-released Cosmo OpenGL is a software-only
implementation, portability is not a problem. It will run on any
graphics card which supports blits. ;-)
-- Michael
Chris Marriott
In article <uvidv4...@kastle.com>, Richard Krehbiel
<ri...@kastle.com> writes
>Game developers want the thinnest possible hardware abstractions. If
>there's an OS or API there at all then it's likely perceived as more
>of a hindrance than a help ("how do I prevent a task switch or
>interrupt from sucking away CPU cycles while I'm rendering?"). The
>popular delivery platform for PC games is a 32 bit DOS extender and
>VESA VBE.
What gives a game writer the "right" (if that's the right word to use)
to "break the rules" and take over the machine? Why shouldn't I be able
to play a game whilst waiting for my program to compile in the
background, or waiting for a long document to print? I typically have
10-15 applications running simultaneously on my machine (Pentium Pro,
Windows NT, 64MB RAM), and the machine stays "up" for months at a time -
are you seriously suggesting that I should have to shut down all my
other applications to play a game?
I'm not criticizing anyone; I'm just interested to know the "philosophy"
which makes game writers feel that they have "exlusive rights" to the
machine; why can't a game be a "good citizen" and share the machine's
resources like all other applications do?
Chris
--------------------------------------------------------------------------
Chris Marriott, Warrington, UK | Author of SkyMap v3 award-winning
ch...@chrism.demon.co.uk | shareware Win31/Win95 planetarium.
For full info, see http://www.execpc.com/~skymap
Author member of Association of Shareware Professionals (ASP)
--------------------------------------------------------------------------
Jeremy Gordon
Stephen H. Wright wrote:
> from past experience that I sometimes enjoy doing that just to get feedback,
Ok, here's some feedback. I learned GL, Inventor, and Performer
interning for
the Department of Defense when I was in college. Before that I followed
the PC demo
community learning 386 assembly, and tricks to make the PC do some
things that
people thought it couldn't. I've got a game development house in San
Francisco
doing titles for PlayStation, Saturn and PC. I've been using OpenGL 1.0
for Win95 for
our internal tools for a while, ( http://www.hyperimage.com/smsnap4.jpg
for a
reference of the type of application ). For the last two years, we've
been
working on titles for game consoles, the PlayStation and Saturn.
I've been excitedly following the rise of D3D since the 3DDDI press
releases,
and the only reason we're interested in it is access to 3D hardware via
the
D3D HAL. I think the last thing we'd ever do is to use someone elses
software
only implementation of anything for game development... If OpenGL
drivers were
put into the hands of every gamer that bought cheap 3D acclerators, and
the
extentions to provide face addressable texture maps, and low bit-depth
source
textures (to be shaded in RGB space) were in place, we would use it for
game
development in tandem with our own software only code. D3D, OpenGL,
whatever,
it's just a way to access the hardware, it doesn't matter who's software
only ramp mode is faster for any self respecting game developer ;) ;) ;)
...just my 2 cents ;)
-jeremy
-------------------------------------------------------------------
Jeremy Gordon Public key is available by finger
MagicArts Corporation Team Hyper Image ;)
http://hyperimage.com jgo...@hyperimage.com
Michael Chock
Chris Marriott wrote:
> What gives a game writer the "right" (if that's the right word to use)
> to "break the rules" and take over the machine? Why shouldn't I be able
> to play a game whilst waiting for my program to compile in the
> background, or waiting for a long document to print? I typically have
> 10-15 applications running simultaneously on my machine (Pentium Pro,
> Windows NT, 64MB RAM), and the machine stays "up" for months at a time -
> are you seriously suggesting that I should have to shut down all my
> other applications to play a game?
>
> I'm not criticizing anyone; I'm just interested to know the "philosophy"
> which makes game writers feel that they have "exlusive rights" to the
> machine; why can't a game be a "good citizen" and share the machine's
> resources like all other applications do?
>
Games are unique among other programs in that they often require an
absolute minimum of latency. A quarter-second pause can easily get a
player killed in many games. Even if a game is not a ridiculous
performance hog, like Quake (don't get me wrong; I love these), if some
scheduler decides that it's time to defragment a hard drive, it can ruin
a game. The same situation in a compiler might only cause an annoying
slowdown.
- Mike
Another blatant plug for:
The Software Zone Games Pages
http://www.softwarezone.com/
Stephen H. Wright
Jeremy -
Thanks for the feedback!
Steve
In article <50klhv$p...@hyperimage.com>, jgo...@hyperimage.com says...
Stephen H. Wright
Michael -
In article <50i3j2$f...@fido.asd.sgi.com>, go...@puck.asd.sgi.com says...
>
>ho...@microsoft.com (Hock San Lee) writes:
>
>| OpenGL 1.0 has some weaknesses to be a viable game API. In particular, it
>| does not support texture object and vertex array performance extensions
>| required to write efficient and high performance games. These performance
>| problems were only addressed in OpenGL 1.1 spec completed last December.
>
>This is true. However, both features have been available as
>extensions to 1.0 for a couple of years.
Several people in this thread have been making the point that Microsoft should
support a single API for the games and professional 3D communities, partly to
simplify the API story on the Microsoft platform, and partly to provide
portability to other platforms. Hock's point was that the the API changes
required to enable games development with OpenGL have not been available in a
*portable* form until 1.1. Even today the case can be made that they are not
portable, since no one except Microsoft is out there with a 1.1 product today.
It is true that a well-written OpenGL application will query for extensions and
use them only if supported, but that misses the point: the performance
differences are so profound that a game requiring texturing would be better off
using a rendering engine like Direct3D or RenderWare with good texture support
than trying to use OpenGL in the absence of the appropriate extensions.
It is also true that the extensions have been available on some platforms for
some time, but that misses the point as well. The games developer needs to
have them available on the volume games platform, before he or she will
consider using OpenGL, not on SGI workstations.
Finally, it is also true that Microsoft could have implemented those extensions
as extensions some time ago. Frankly, we've had our hands full just getting
core OpenGL software performance up to a competitive level, starting with the
(widely acknowledged to be a lousy performing) SGI sample implementation. The
1.1 extensions would have been useless API changes without the performance work
we've done. (For example, vertex array was supported as an extension in our NT
3.51 release, but it didn't provide any performance advantage in that
implementation.)
Thinking about the historical factors, it might help if everyone in this thread
would step back for a minute and remember how we got here.
The move towards having a games 3D API goes back about 2 years (recall that the
RenderMorphics acquisition took place about 18 months back), and, like it or
not, there was no question that OpenGL was not then appropriate for the games
market. (For what it's worth, I wasn't involved in that acquisition, it
started before I even came on board here, so I don't have a personal axe to
grind in defending it.) For example:
1) Microsoft had just released the first NT 3.5 OpenGL implementation and had
lots of tuning to work on as well as a lot of IHV relationships to try to
build. We were in no position to offer OpenGL as a credible games development
API for Windows.
2) I believe SGI was thinking about trying to partition a subset of OpenGL for
the games market, but they did not communicate those ideas to other ARB members
until after the RenderMorphics acquisition. They were months if not years away
from being able to offer a credible proprietary games API.
3) The texturing and vertex array extensions described above had not even been
proposed for the next core OpenGL specification. (The 1.1 specification
process didn't really start until the 2/95 ARB meeting.) The standards process
was months if not years away from being able to provide a credible standard
games API.
4) I suspect that the code used in Cosmo (which rumor has it SGI obtained from
3DLabs) was nowhere near as well-tuned then as it is now. I know, at least,
that 3DLabs has invested a lot in tuning their code over the last two years.
5) The dominant consumer machines then were 386 and 486 PC's without enough
floating point capability to handle the OpenGL geometry pipeline in software,
as against integer pipelines for games API's. Our OpenGL 1.0 NT 3.51 software
pipeline did CDRS at 0.061 frames/second on a 33MHz 486. Yes, that's really
one frame every 16 seconds; that's about *1/8* the performance of the same
software running on a P90 (and about *1/100* the performance of our
1.1 implementation running on a PPro 200.)
In short, we didn't have the required hardware, a tuned pipeline or the
required API.
Several people on this thread have suggested that the move to Direct3D simply
reflects Microsoft's desire to control API's. Certainly Microsoft does have a
business interest in being able to innovate to meet ISV needs -- and the
continuing rapid evolution of the entire DirectX API family in partnership
with PC ISV's and IHV's is a good example of the value of being able to do
that. Nevertheless, I can't see that this was nearly as significant as the
brute fact that when it came to consumer 3D, OpenGL completely missed the
window of opportunity.
>| Some people expressed an interest in using both color index and RGBA modes
>| in their applications. However, there are 2 problems: OpenGL does not
>| support texture in CI mode; application programming in CI mode is quite
>| different from RGBA mode. Even if these problems are solved, an
>| application will still not achieve platform portability and with hardware
>| support in this mode.
>
>Cosmo OpenGL supports a number of extensions for color index mode,
>including texture mapping. We have offered these extensions to
>Microsoft, and the offer remains open.
>
>If color index mode proves critical for game developers (and the
>Direct3D folks apparently are banking on this), hardware support may
>be provided. What confuses me about your statement, however, is that
>Direct3D faces the exact same issue. If hardware support is available
>for ramp mode in Direct3D, it is also available for OpenGL. Again,
>there is no inherent advantage to Direct3D here.
Sounds like we're going around in circles here. Let me try a fresh start.
Direct3D, going back to its roots in RenderMorphics' Reality Lab engine, has a
fast ramp mode. All the game 3D engines have great ramp mode implementations.
This has been critical over the past couple of years, but we don't see that
continuing to be a key differentiator in the future, given the evolution
towards 16-bit PC video cards. IHV's are not providing ramp-mode
acceleration, and Direct3D is focussing on providing better RGB performance
(e.g., the MMX driver.)
However, some people in this thread have argued that color-index mode will
continue to be important, and therefore having good OpenGL support through
Cosmo is important. I think Hock was trying to point out a couple of
additional problems with continuing to provide good color-index support in
OpenGL. Let me restate them:
1) Texture support. The issue is not lack of API's and whether or not SGI is
giving them away, but performance of the underlying algorithms. Texture
filtering and sampling in RGB space is straightforward compared to CI space.
We believe this is another factor that will continue to drive acceptance of RGB
mode in the games community.
2) Application development focus. Some rendering engine issues are relatively
transparent to the application developer. Choosing between CI and RGB mode is
not one of them. An application that supports both frequently has to make
fundamental decisions that affect not only the pipeline and model but even the
art content. I personally have been hoping that the advent of cheap 16bpp
hardware would put an early end to CI or ramp mode application development, and
I'm not happy with the prospect that Cosmo might attract developers into
creating a bigger CI legacy burden.
>Since the soon-to-be-released Cosmo OpenGL is a software-only
>implementation, portability is not a problem. It will run on any
>graphics card which supports blits. ;-)
And there's the rub with promoting CI to the development community. Cosmo --
as currently billed -- won't take advantage of any graphics card which supports
textured and shaded triangles, let alone triangle setup or a true geometry
pipeline. And Cosmo -- even with an aggressive IHV program -- won't be able to
accelerate CI rendering, because the IHV's we're aware of aren't accelerating
it. Which means that applications written only for CI mode are going to be
stuck at one performance level while their RGB competitors soar ahead.
CI is an attractive alternative *today* for the application developer -- and it
may still be a win for an application with a relatively limited lifetime like a
game -- but it's a dead end for products that will continue to require support
and updates for years to come. The update from CI to RGB mode may be a costly
and painful one, depending on the extent to which both application code and
artwork require revision.
David Blythe
In article <50i0f1$s...@news.microsoft.com> ho...@microsoft.com (Hock San Lee) writes:
>There have been a lot of interesting discussions. I am going to add a
>couple points to provide some perspectives:
>
>does not support texture object and vertex array performance extensions
>required to write efficient and high performance games. These performance
>problems were only addressed in OpenGL 1.1 spec completed last December.
I'd like to clarify a point about the vertex array extension and revised
variant included in 1.1. Their inclusion helps make 1995/6-vintage low-end
and mid-range PC implementations of OpenGL more suitable for games
deployment. Other OpenGL implementations had already demonstrated their
suitability for such applications (games, entertainment, visual simulation)
before the advent of the vertex array proposal. In many ways this feels
like another ramp-mode red herring (or sacred cow). Other vendors seemed
to be getting on adequately (using RGB-mode too) but the push came from the
PC-end of the spectrum with a need to take short-cuts trading flexibility
for speed. Once this short-cut was introduced it did usher in discussions
for lots of other dubious short-cuts such as disabling clip checking,
caching transformed vertices, culling hints, etc. These are also likely to
have diminishing benefit as processors and accelerators mature, just like
ramp-mode.
There will of course be contentious debate over when they are no longer
needed, just like ramp-mode :)
On the issue of texture objects, I suspect that their importance to
PC games implementations is overstated. The original texture object-like
mechanism was to optimize display lists containing teximage calls and treat
executions of such display lists as an efficient texture binding call.
This seemed okay and even worked okay on SGI's RE2, but it became more
problematic as the imaging path was extended and it completely broke down
when the realization was made that it was useful to update portions of
texture rather than the entire texture. This brought about the texture
object extension, and it caused us to abandon the teximage within a display
list paradigm. Now efficient binding is done through the texture object
extension, but that isn't impossible with the display list mechanism. I
am sure there are other 1.0 implementations which do a good job of it.
I'm happy to concede that texture objects are good, but its not completely
obvious to me that they would make or break OpenGL as a portable games API.
-db
>
>Hock San Lee
>Microsoft
>
Richard Krehbiel
Chris Marriott <ch...@chrism.demon.co.uk> writes:
> In article <uvidv4...@kastle.com>, Richard Krehbiel
> <ri...@kastle.com> writes
> >Game developers want the thinnest possible hardware abstractions. If
> >there's an OS or API there at all then it's likely perceived as more
> >of a hindrance than a help ("how do I prevent a task switch or
> >interrupt from sucking away CPU cycles while I'm rendering?"). The
> >popular delivery platform for PC games is a 32 bit DOS extender and
> >VESA VBE.
>
> What gives a game writer the "right" (if that's the right word to use)
> to "break the rules" and take over the machine?
Well, I never said they had any such *right*. I just know that's what
they *want*.
> Why shouldn't I be able
> to play a game whilst waiting for my program to compile in the
> background, or waiting for a long document to print? I typically have
> 10-15 applications running simultaneously on my machine (Pentium Pro,
> Windows NT, 64MB RAM), and the machine stays "up" for months at a time -
> are you seriously suggesting that I should have to shut down all my
> other applications to play a game?
Uh huh. :-)
Actually, it's a matter of system resources. There are plenty of
games and puzzles that cooperate just fine, and I'd be pretty
disturbed if I had to boot DOS to play FreeCell. Real-time simulation
games are another matter. The more CPU they have available, the
better they run.
> I'm not criticizing anyone; I'm just interested to know the "philosophy"
> which makes game writers feel that they have "exlusive rights" to the
> machine; why can't a game be a "good citizen" and share the machine's
> resources like all other applications do?
Just like every other programmer out there, they want their
application to be seen in the most favorable light. If it's a real
time simulation game, then any CPU cycles the game loses to other
system activity (or arduous API abstractions) makes it slower; and on
slower CPUs it may take *everything* the CPU has to run the simulation
at acceptable speed.
Again, I never said game writers have any sort of "right" to "break
the rules", where "rights" and "rules" are very poorly defined, BTW.
It's *my* computer, I paid for it, I own it, *I* make the rules, not
MS or SGI or anyone else. I'll buy games that play the best, and if
that means booting DOS for the best game of Quake, then so be it!
Mark Kilgard
In article <50l0di$q...@news.microsoft.com>, swr...@microsoft.com (Stephen H.
Wright) writes:
|>
A single observation...
|> Several people in this thread have been making the point that Microsoft should
|> support a single API for the games and professional 3D communities, partly to
|> simplify the API story on the Microsoft platform, and partly to provide
|> portability to other platforms. Hock's point was that the the API changes
|> required to enable games development with OpenGL have not been available in a
|> *portable* form until 1.1. Even today the case can be made that they are not
|> portable, since no one except Microsoft is out there with a 1.1 product today.
Take a step back and look what you've just explained:
OpenGL wasn't *portable* enough (your emphasis), so Microsoft invented
a second entirely different and proprietary 3D interface.
Does that seem consistent to you?
- Mark
Stephen H. Wright
With regard to the vertex array extension, it may be true that non-PC
implementations of OpenGL were well-suited for games even without the
availability of these extensions. Most games developers, of course, do not
target those platforms. If they are indeed required for developers on the
volume "vintage" games platforms then they are required to enable OpenGL as a
viable games API. And while Microsoft, representing the PC industry, did lobby
for the vertex array extension, it's worth noting that the entire ARB was
enthusiastically in support of putting the extension into core OpenGL, and that
significant changes were made very late in the specification stage to
accomodate Hewlett-Packard's suggestions to meet high-end requirements. I don't
believe this is either a red herring or sacred cow.
With regard to the texture object extension, Template recently posted that
using the texture object extension in 1.1 improved software rendering
performance by (if I recall properly) about 15x. (Part of this improvement may
be attributable to general pipeline tuning on our part.) However problematic
these changes may have been from an SGI architectural perspective, it's clear
that they have a real and not "overstated" impact on suitability for the games
market, which, at least today, places a very high emphasis on the use of
textures over tesselation to convey artwork.
By the way, I find it amusing that one SGI poster reproaches us on the grounds
that these extensions were available in other implementations and we only
adopted them recently in our 1.1 implementation; while another suggests that
they are not particularly germane to the general OpenGL industry and were added
as concessions to the PC side of the business.
Steve Wright
OpenGL Program Manager
Microsoft Corporation
In article <50lmkh$k...@fido.asd.sgi.com>, bly...@banshee.asd.sgi.com says...
Peter Sloan
Stephen H. Wright (swr...@microsoft.com) wrote:
: Michael -
[ stuff deleted ]
: >Cosmo OpenGL supports a number of extensions for color index mode,
: >including texture mapping. We have offered these extensions to
: >Microsoft, and the offer remains open.
: >
: >If color index mode proves critical for game developers (and the
: >Direct3D folks apparently are banking on this), hardware support may
: >be provided. What confuses me about your statement, however, is that
: >Direct3D faces the exact same issue. If hardware support is available
: >for ramp mode in Direct3D, it is also available for OpenGL. Again,
: >there is no inherent advantage to Direct3D here.
: Sounds like we're going around in circles here. Let me try a fresh start.
: Direct3D, going back to its roots in RenderMorphics' Reality Lab engine, has a
: fast ramp mode. All the game 3D engines have great ramp mode implementations.
: This has been critical over the past couple of years, but we don't see that
: continuing to be a key differentiator in the future, given the evolution
: towards 16-bit PC video cards. IHV's are not providing ramp-mode
: acceleration, and Direct3D is focussing on providing better RGB performance
: (e.g., the MMX driver.)
I think that CI support for textures would be useful for both game
developers and non game developers. This is supported in HW for the
Lockheed/Martin board (I think) and I believe the Ultra64 as well.
This can be done even if the FB is in RGB mode - SGI has an extension
that almost does the trick (glColorTableSGI) but just falls short (the
LUT is accesed after filtering, not before...)
: However, some people in this thread have argued that color-index mode will
: continue to be important, and therefore having good OpenGL support through
: Cosmo is important. I think Hock was trying to point out a couple of
: additional problems with continuing to provide good color-index support in
: OpenGL. Let me restate them:
: 1) Texture support. The issue is not lack of API's and whether or not SGI is
: giving them away, but performance of the underlying algorithms. Texture
: filtering and sampling in RGB space is straightforward compared to CI space.
: We believe this is another factor that will continue to drive acceptance of RGB
: mode in the games community.
I agree - but as I stated above this doesn't mean that you can't have
CI mode textures (and limited texture memmory is a huge problem that
doesn't look like it will go away soon...)
[ more stuff deleted ]
--
-Peter-Pike Sloan
http://www.cs.utah.edu/~ppsloan
pps...@lal.cs.utah.edu RA in the SCILodge
Stephen H. Wright
Mark -
There's no contradiction here ...
In article <50me99$s...@fido.asd.sgi.com>, m...@woodsy.asd.sgi.com says...
>
>In article <50l0di$q...@news.microsoft.com>, swr...@microsoft.com (Stephen H.
>Wright) writes:
>|>
>
>A single observation...
>
>|> Several people in this thread have been making the point that Microsoft
should
>|> support a single API for the games and professional 3D communities, partly
to
>|> simplify the API story on the Microsoft platform, and partly to provide
>|> portability to other platforms. Hock's point was that the the API changes
>|> required to enable games development with OpenGL have not been available in
a
>|> *portable* form until 1.1. Even today the case can be made that they are
not
>|> portable, since no one except Microsoft is out there with a 1.1 product
today.
>
>Take a step back and look what you've just explained:
>
> OpenGL wasn't *portable* enough (your emphasis), so Microsoft invented
> a second entirely different and proprietary 3D interface.
>
>Does that seem consistent to you?
>
>- Mark
It's the other posters on this thread that have been emphasizing portability to
other platforms. All I've done is point out that the combination of this
requirement and API support for games weren't both there when they needed to
be.
I'm not that concerned with game API portability as long as the API is
available on the volume games platforms (which wasn't true of the extensions I
was talking about until very recently.) In that context it's worth pointing
out that Microsoft didn't "invent a second entirely different and proprietary
3D interface". It acquired one of the leading game API vendors with a good
portability across the leading games platforms.
My sense is that the main benefit of having a UNIX cross-platform story for
games API's is to simplify life for the game developer by enabling him to test
and develop on the same platform. (Few developers see a business case for
marketing and qualifying titles on UNIX compared with the volume market.)
Unfortunately, having a portable graphics API only addresses a small part of
that need as long as the developer is trying to develop on UNIX and deploy on
Windows. It makes a lot more sense to get the developer onto NT, where many of
the game dev toolmakers are moving, and where we can easily support the same
API's used by the game.
(I understand you may not share that goal with me!)
Hock San Lee
In article <50n7er$2...@magus.cs.utah.edu>, pps...@lal.cs.utah.edu says...>: >Cosmo OpenGL supports a number of extensions for color index mode,
>: >including texture mapping. We have offered these extensions to
>: >Microsoft, and the offer remains open.
>: >
>: >If color index mode proves critical for game developers (and the
>: >Direct3D folks apparently are banking on this), hardware support may
>: >be provided. What confuses me about your statement, however, is that
>: >Direct3D faces the exact same issue. If hardware support is available
>: >for ramp mode in Direct3D, it is also available for OpenGL. Again,
>: >there is no inherent advantage to Direct3D here.
>
>: Sounds like we're going around in circles here. Let me try a fresh
start.
>: Direct3D, going back to its roots in RenderMorphics' Reality Lab
engine, has a
>: fast ramp mode. All the game 3D engines have great ramp mode
implementations.
>: This has been critical over the past couple of years, but we don't see
that
>: continuing to be a key differentiator in the future, given the
evolution
>: towards 16-bit PC video cards. IHV's are not providing ramp-mode
>: acceleration, and Direct3D is focussing on providing better RGB
performance
>: (e.g., the MMX driver.)
>
>developers and non game developers. This is supported in HW for the
>Lockheed/Martin board (I think) and I believe the Ultra64 as well.
>This can be done even if the FB is in RGB mode - SGI has an extension
>that almost does the trick (glColorTableSGI) but just falls short (the
>LUT is accesed after filtering, not before...)
>
>: continue to be important, and therefore having good OpenGL support
through
>: Cosmo is important. I think Hock was trying to point out a couple of
>: additional problems with continuing to provide good color-index support
in
>: OpenGL. Let me restate them:
>
>: 1) Texture support. The issue is not lack of API's and whether or not
SGI is
>: giving them away, but performance of the underlying algorithms.
Texture
>: filtering and sampling in RGB space is straightforward compared to CI
space.
>: We believe this is another factor that will continue to drive
acceptance of RGB
>: mode in the games community.
>
>CI mode textures (and limited texture memmory is a huge problem that
>doesn't look like it will go away soon...)
>
>[ more stuff deleted ]
>
>--
>-Peter-Pike Sloan
>http://www.cs.utah.edu/~ppsloan
>pps...@lal.cs.utah.edu RA in the SCILodge
Sounds like you want the paletted texture extension in our OpenGL 1.1
implementation. It supports index texture in RGBA mode and is used by the
Maze screen saver. 3Dlabs will be supporting it. I believe SGI will be
supporting it too...
Microsoft defines this extension to address performance and size issues.
Note that this works only in RGBA mode, not color index mode.
Hock San Lee
Microsoft
Michael I. Gold
ho...@microsoft.com (Hock San Lee) writes:
| Sounds like you want the paletted texture extension in our OpenGL 1.1
| implementation. It supports index texture in RGBA mode and is used by the
| Maze screen saver. 3Dlabs will be supporting it. I believe SGI will be
| supporting it too...
|
| Microsoft defines this extension to address performance and size issues.
| Note that this works only in RGBA mode, not color index mode.
The paletted_texture extension is the basis for the color index mode
texture extension. At least we use the same internal formats, and the
texture download code is shared.
Stephen Platt
Mark Kilgard wrote:
>
> In article <50l0di$q...@news.microsoft.com>, swr...@microsoft.com (Stephen H.
> Wright) writes:
> |>
>
> A single observation...
>
> |> support a single API for the games and professional 3D communities, partly to
> |> simplify the API story on the Microsoft platform, and partly to provide
> |> portability to other platforms. Hock's point was that the the API changes
> |> required to enable games development with OpenGL have not been available in a
> |> *portable* form until 1.1. Even today the case can be made that they are not
> |> portable, since no one except Microsoft is out there with a 1.1 product today.
>
>
> OpenGL wasn't *portable* enough (your emphasis), so Microsoft invented
> a second entirely different and proprietary 3D interface.
>
> Does that seem consistent to you?
>
> - Mark
I think you missed what Hock and Steve are trying to say.
OpenGL has industry momemtum. Microsoft APIs don't. Momentum, in a
sense, is
"resistance to change in direction."
In a nutshell, OpenGL is a broad, expansive API, covering a wide range
of hardware
platforms. As it changes, the changes need time to propagate across the
vendor
space. (See "ARB", also "multivendor consortium.")
Changes in OGL *do take time* to come into being.
D3D is proprietary. One vendor setting the specs, a smaller market
space
supporting it. Low mass. It can respond to change quickly; if the user
space
suddenly decides it needs Gizmo3 support, it can be added quickly.
Without
six vendors' worth of incompatible extensions, followed by spec
proposals,
ARB debates, and actual implementation.
Stop treating D3D as an enemy... Treat it as a laboratory experiment in
which
changes can be implemented and tested coherently (as opposed to
proprietarily).
-Steve
--
----------------------------------------
Stephen M. Platt, Ph. D.
Research and Development
National Software Testing Laboratories
A Division of the McGraw-Hill Companies
Mark Kilgard
In article <50n9kk$e...@news.microsoft.com>, swr...@microsoft.com (Stephen H.|> >[...deleted...]
|> >
|> >Take a step back and look what you've just explained:
|> >
|> > OpenGL wasn't *portable* enough (your emphasis), so Microsoft invented
|> > a second entirely different and proprietary 3D interface.
|> >
|> >Does that seem consistent to you?
|>
|>
|> I'm not that concerned with game API portability as long as the API is
|> available on the volume games platforms (which wasn't true of the extensions
|> I
|> was talking about until very recently.) In that context it's worth pointing
|> proprietary
|> portability across the leading games platforms.
I am refering to Direct3D's immediate mode API, not the original Reality
Lab API that has since become Direct3D retained mode.
Direct3D immediate mode is indeed a newly invented low-level API promoted
by Microsoft. The original RealityLab had an internal driver interface
that Microsoft refashioned and promoted to be a new low-level 3D API.
The two reasons Microsoft invented Direct3D immediate mode are:
1. Microsoft marketing mistakenly believes that there is a difference
between "game" and "real" 3D.
Microsoft has confused markets with technologies. Interactive
3D is a single technology though it has many markets. Promulgating
this mistaken view with two differnt low-level 3D APIs dillutes the
innovation possible for everyone wanting to use 3D since similiar
effort has to be expended for both APIs that at a base level do
the same basic thing.
People today are wondering what 3D API to learn; card vendors are
trying to figure out how much time needs to be spent on drivers to
support the two APIs; two sets of tech writers are writing manuals
that are explaining how to do basically identical things. It's
a big waste. There's not really much room for argument that
Direct3D has created unnecessary confusion about how to handle 3D.
2. Microsoft bought RenderMorphics and wanted a quick product, but
realized RealityLab needed a low-level interface. To be
expedient, Microsoft promoted an internal interface into as
a low-level 3D API.
Suggesting that OpenGL lacked features or portability as the reason
that motivated the development of Direct3D immediate mode is a crock.
- Mark
Peter Sloan
Michael I. Gold (go...@puck.asd.sgi.com) wrote:
: ho...@microsoft.com (Hock San Lee) writes:
: | Sounds like you want the paletted texture extension in our OpenGL 1.1
: | implementation. It supports index texture in RGBA mode and is used by the
: | Maze screen saver. 3Dlabs will be supporting it. I believe SGI will be
: | supporting it too...
: |
: | Microsoft defines this extension to address performance and size issues.
: | Note that this works only in RGBA mode, not color index mode.
: The paletted_texture extension is the basis for the color index mode
: texture extension. At least we use the same internal formats, and the
: texture download code is shared.
Is this extension available now? I am using a MAX Impact currently
and it would be really useful. When is filtering done in the
extension? It should be done after the LUT's otherwise it is basicaly
useless...
On the PC side someone said that 3Dlabs was going to support this -
will that be in hardware? With post-LUT filtering?
[ stuff deleted ]
--
-Peter-Pike Sloan
http://www.cs.utah.edu/~ppsloan
pps...@ptc.com 3DPaint Programmer (PTC!)
Michael I. Gold
pps...@lal.cs.utah.edu (Peter Sloan) writes:
| Michael I. Gold (go...@puck.asd.sgi.com) wrote:
| : The paletted_texture extension is the basis for the color index mode
| : texture extension. At least we use the same internal formats, and the
| : texture download code is shared.
|
| Is this extension available now? I am using a MAX Impact currently
| and it would be really useful. When is filtering done in the
| extension? It should be done after the LUT's otherwise it is basicaly
| useless...
This extension was written by Microsoft and adopted for Cosmo OpenGL
for the PC market. I am aware of no plans to support it on SGI
systems.
Filtering is done after the LUT, so in RGB mode you can have more
colors in the final image than in the original texture.
I don't know anything about 3Dlabs plans in this regard.
Stephen H. Wright
In article <50popp$c...@magus.cs.utah.edu>, pps...@lal.cs.utah.edu says...
>
>: | Sounds like you want the paletted texture extension in our OpenGL 1.1
>: | implementation. It supports index texture in RGBA mode and is used by the
>: | Maze screen saver. 3Dlabs will be supporting it. I believe SGI will be
>: | supporting it too...
>: |
>: | Microsoft defines this extension to address performance and size issues.
>: | Note that this works only in RGBA mode, not color index mode.
>
>: texture extension. At least we use the same internal formats, and the
>: texture download code is shared.
>
>Is this extension available now? I am using a MAX Impact currently
>and it would be really useful. When is filtering done in the
>extension? It should be done after the LUT's otherwise it is basicaly
>useless...
>
>will that be in hardware? With post-LUT filtering?
>
>[ stuff deleted ]
>
>--
>-Peter-Pike Sloan
>http://www.cs.utah.edu/~ppsloan
>pps...@ptc.com 3DPaint Programmer (PTC!)
>pps...@lal.cs.utah.edu RA in the SCILodge
Peter -
The *rumor* is that 3DLabs may provide GLint driver support for Cosmo, which
would presumably include the palletted texture extension. I've also heard --
hmmm, rumors -- that IHV's are not thrilled with the prospect of adding Cosmo
GL driver support to a stew that already includes Heidi and Microsoft OpenGL
(and, yes, Direct3D!)
Our own software implementation of this extension does perform post-LUT
filtering, and presumeably IHV's that provide hardware support will do so
post-LUT as well. I'm not aware which of our ISV's will be supporting this
extension and the 1.1 features, nor in what time frames.
Mark Kilgard
In article <50ptd6$l...@news.microsoft.com>, swr...@microsoft.com (Stephen H.
Wright) writes:
|>
|> The *rumor* is that 3DLabs may provide GLint driver support for Cosmo, which
|> |> would presumably include the palletted texture extension. I've also heard
|> --
|> hmmm, rumors -- that IHV's are not thrilled with the prospect of adding Cosmo
|> |> GL driver support to a stew that already includes Heidi and Microsoft
|> OpenGL
|> (and, yes, Direct3D!)
As I understand things, the complaint is not with writing a driver
for any particular API; the complaint is having to write drivers for
so many APIs. Really, it's a shame 3D board vendors have to write
any more than 1 driver.
Don't pawn the problem of having to write multiple 3D drivers for
each PC graphics card off on SGI or Cosmo OpenGL. It is Microsoft
promoting two different low-level 3D APIs that is at the heart of the
problem. Imagine how clean the 3D driver issue would be if Microsoft
had simply provided a reasonable OpenGL driver interface early on.
Cosmo OpenGL would not even have to exist then!
You also mention Heidi, AutoCAD's hardware driver interface. That's
really a bit different from a general purpose low-level 3D driver.
Presumably, if AutoCAD could get their hands on a fast enough portable
and general purpose 3D API, they would not require an application-specific
driver model. Again, if Microsoft had a suitable driver interface for
OpenGL, Heidi would not need to exist. As evidence for this, consider
that workstation CAD software makers do not demand a special hardware
driver from SGI workstations; they just know to use the basic OpenGL interface
since it is _optimized_ and leanest interface to the graphics
hardware. And no SGI graphics library engineer is complaining about having
to write multiple 3D hardware drivers for a single graphics subsystem.
As I see it, AutoCAD's need to have an application-specific interface
to 3D hardware is just more evidence that Microsoft dropped the
ball with regard to 3D driver interfaces.
- Mark
Martin Szinger
Stephen H. Wright wrote:
>
> Several people in this thread have been making the point that Microsoft should
> support a single API for the games and professional 3D communities, partly to
> simplify the API story on the Microsoft platform, and partly to provide
>
> Thinking about the historical factors, it might help if everyone in this thread
> would step back for a minute and remember how we got here.
From my vantage point, the rest of this discussion looks like a laundry list of
technical obstacles facing OpenGL on Wintel HW/SW that have been successively
overcome. So bravo MS! But now, you can't really use this to justify the existence
of Direct3D anymore, can you? If anything, it shows the rate at which OpenGL on
Windows is surging ahead. So, chalk off the loss of RenderMorphics against the
massive profit from MS Office and get on with the business of making OpenGL the one
and only 3D API for Windows. Historically, MS has shown itself to be brilliant
about ditching losing strategies, even their own strategies, in favor of what's
clearly going to work (ie., "market demands"). However, they're also known for
using a confusing amalgam of strategies to freeze out a market and wither
opposition while they position themselves better. Which MS strategy is this
OpenGL/Direct 3D business illustrating?
> The move towards having a games 3D API goes back about 2 years (recall that the
> RenderMorphics acquisition took place about 18 months back), and, like it or
> not, there was no question that OpenGL was not then appropriate for the games
> market. (For what it's worth, I wasn't involved in that acquisition, it
> started before I even came on board here, so I don't have a personal axe to
> grind in defending it.) For example:
>
> 1) Microsoft had just released the first NT 3.5 OpenGL implementation and had
> lots of tuning to work on as well as a lot of IHV relationships to try to
> build. We were in no position to offer OpenGL as a credible games development
> API for Windows.
Looks like it's been getting a lot of tuning lately.
> 2) I believe SGI was thinking about trying to partition a subset of OpenGL for
> the games market, but they did not communicate those ideas to other ARB members
> until after the RenderMorphics acquisition. They were months if not years away
> from being able to offer a credible proprietary games API.
Technology has caught up to the point where partitioning isn't really an issue
anymore. My opinion, at least.
> 3) The texturing and vertex array extensions described above had not even been
> proposed for the next core OpenGL specification. (The 1.1 specification
> process didn't really start until the 2/95 ARB meeting.) The standards process
> was months if not years away from being able to provide a credible standard
> games API.
But here it is now.
> 4) I suspect that the code used in Cosmo (which rumor has it SGI obtained from
> 3DLabs) was nowhere near as well-tuned then as it is now. I know, at least,
> that 3DLabs has invested a lot in tuning their code over the last two years.
Competition, great. That'll only push the market faster.
> 5) The dominant consumer machines then were 386 and 486 PC's without enough
> floating point capability to handle the OpenGL geometry pipeline in software,
> as against integer pipelines for games API's. Our OpenGL 1.0 NT 3.51 software
> pipeline did CDRS at 0.061 frames/second on a 33MHz 486. Yes, that's really
> one frame every 16 seconds; that's about *1/8* the performance of the same
> software running on a P90 (and about *1/100* the performance of our
> 1.1 implementation running on a PPro 200.)
I bet it'll really fly on the P7, eh? Plus MMX and AGP! Working on a scaled back
3D API at this point is akin to pushing software RAM doublers in the face of
collapsing memory prices.
> In short, we didn't have the required hardware, a tuned pipeline or the
> required API.
Now you do, now you do, now you do. Run with it, man.
> that. Nevertheless, I can't see that this was nearly as significant as the
> brute fact that when it came to consumer 3D, OpenGL completely missed the
> window of opportunity.
You speak of it as if it's past tense. Did a 3D API for PC's sneak in somewhere in
the last 2 years and suddenly overrun the market, while we weren't paying attention?
The window of opportunity is opening wider every day, I'd say.
>
> Steve Wright
> OpenGL Program Manager
> Microsoft Corporation
Martin Szinger
Software Engineer
Amherst, Systems, Inc.
-- insert appropriate disclaimer here --
Stephen H. Wright
Mark -
In article <50rv6a$r...@fido.asd.sgi.com>, m...@woodsy.asd.sgi.com says...
>
>In article <50ptd6$l...@news.microsoft.com>, swr...@microsoft.com (Stephen H.
>Wright) writes:
>|>
>|> The *rumor* is that 3DLabs may provide GLint driver support for Cosmo,
which
>|> |> would presumably include the palletted texture extension. I've also
heard
>|> --
>|> hmmm, rumors -- that IHV's are not thrilled with the prospect of adding
Cosmo
>|> |> GL driver support to a stew that already includes Heidi and Microsoft
>|> OpenGL
>|> (and, yes, Direct3D!)
>
>As I understand things, the complaint is not with writing a driver
>for any particular API; the complaint is having to write drivers for
>so many APIs. Really, it's a shame 3D board vendors have to write
>any more than 1 driver.
>
>Don't pawn the problem of having to write multiple 3D drivers for
>each PC graphics card off on SGI or Cosmo OpenGL. It is Microsoft
>promoting two different low-level 3D APIs that is at the heart of the
>problem.
The issue is not merely having another interface to support. If that's all it
were, SGI's introduction of yet another interface would still be a problem and
would still be worth a complaint. (SGI may, of course, choose to pretend that
this is really Microsoft's fault for introducing Direct3D.)
That issue is complicated by the entire unresolved issue of interoperability
between Cosmo and Microsoft OpenGL on Windows platforms. Introducing driver
support drives the interoperability issues down an additional level, adding new
dependencies on additional system components.
>Imagine how clean the 3D driver issue would be if Microsoft
>had simply provided a reasonable OpenGL driver interface early on.
>
>Cosmo OpenGL would not even have to exist then!
And imagine how easy this would have been if SGI had "simply" provided a
reasonably apt games API and competitive sample implementation when Microsoft
needed it!
>You also mention Heidi, AutoCAD's hardware driver interface. That's
>really a bit different from a general purpose low-level 3D driver.
>Presumably, if AutoCAD could get their hands on a fast enough portable
>and general purpose 3D API, they would not require an application-specific
>driver model. Again, if Microsoft had a suitable driver interface for
>OpenGL, Heidi would not need to exist.
I can't yet name names, but we've actually heard from one driver writer house
working on 3D Windows drivers for one IHV that they're getting excellent Heidi
results through an OpenGL layer that connects to an MCD-based OpenGL driver.
(You may, of course, continue to maintain that the MCD interface is not a
"suitable driver interface for OpenGL.")
>As evidence for this, consider
>that workstation CAD software makers do not demand a special hardware
>driver from SGI workstations; they just know to use the basic OpenGL interface
>since it is _optimized_ and leanest interface to the graphics
>hardware. And no SGI graphics library engineer is complaining about having
>to write multiple 3D hardware drivers for a single graphics subsystem.
>
>As I see it, AutoCAD's need to have an application-specific interface
>to 3D hardware is just more evidence that Microsoft dropped the
>ball with regard to 3D driver interfaces.
>
>- Mark
Given the performance of our 1.1 software as well as the wide availability of
cheap OpenGL ICD- and MCD-based hardware accelerators, it's hard to see the
AutoDesk/Heidi story in that light. Presumably the Heidi decision was made at
least a year ago, i.e., at a time when we didn't have either the fast 1.1
software or the MCD option, but I still don't believe your explanation, for a
number of reasons:
1) AutoDesk never talked with the OpenGL group at Microsoft to talk about
performance requirements and learn about our product plans, which is what I
would have expected if they had undertaken an objective evaluation of our
implementation.
2) I've also heard through inside sources at AutoDesk that their evaluation of
OpenGL was skewed in that only a perfunctory effort was made to write an OpenGL
driver for the evaluation, and that it was not well designed or optimized for
OpenGL.
3) I have heard through other ISV and IHV contacts that AutoDesk is adamantly
"NIH" about OpenGL, having spent money acquiring the Heidi code and feeling
that they feel an ongoing need to justify the purchase.
4) The head of the Kinetix division (which markets 3D Studio Max, the primary
Heidi-based product at this time) has gone on the record as saying that he
regards Microsoft as an "enemy" after the SoftImage acquisition.
In short, there appear to be multiple sensitive "political" issues involved.
However, if you want to continue blaming it on the poor software performance
and complex driver support story for OpenGL 1.0, I'll be happy to remind you
that both of them derive from the SGI sample implementation, and both problems
were not solved until Microsoft redesigned the front end with both software
performance and hardware support in mind.
Stephen H. Wright
In article <323416...@amherst.com>, m...@amherst.com says...
>
>Stephen H. Wright wrote:
>>
>> [ much deleted; here's what I take as the essence ... ]
>> In short, we didn't have the required hardware, a tuned pipeline or the
>> required API.
>
>Now you do, now you do, now you do. Run with it, man.
>
>> that. Nevertheless, I can't see that this was nearly as significant as the
>> brute fact that when it came to consumer 3D, OpenGL completely missed the
>> window of opportunity.
>
>You speak of it as if it's past tense. Did a 3D API for PC's sneak in
somewhere in
>the last 2 years and suddenly overrun the market, while we weren't paying
attention?
>The window of opportunity is opening wider every day, I'd say.
>
>>
>> Steve Wright
>> OpenGL Program Manager
>> Microsoft Corporation
>
>Martin Szinger
>Software Engineer
>Amherst, Systems, Inc.
>
Martin -
As I read it, your basic argument is that we've overcome all the technical
hurdles over the last two years and now we can proceed ahead with OpenGL as a
games API rather than Direct3D, so why not do it?
The answer is that there is already far too much development underway for
Direct3D. There are literally dozens of IHV's making hardware that will
support the D3D HAL. There are literally dozens of ISV's writing software that
will use the Direct3D interface to take advantage of that hardware. Direct3D
is not "overrunning" the market, but it's much closer to a de facto standard in
the games market than OpenGL.
You suggest that Microsoft has shown in the past that it can abandon an
unproductive approach and switch gears. This is true, but it is also true that
Direct3D is not, today, an unproductive approach. We're not going to abandon
it any more than we're going to abandon OpenGL. Both API's have a lot of
momentum going for them in different markets.
One additional specific point:
>I bet it'll really fly on the P7, eh? Plus MMX and AGP! Working on a
>scaled back 3D API at this point is akin to pushing software RAM doublers
>in the face of collapsing memory prices.
Ironically, while most hardware improvements tend to level the playing field in
the "API wars", MMX actually increases the importance of Direct3D in the
software rasterization arena for fairly arcane tecnical reasons. MMX has some
great instructions for improving the performance of the inner scanline loop;
unfortunately, at any given point in time you have to choose between normal
floating point operations and these parallel integer operations. The switch
between the two modes is relatively expensive, but this is not an issue for
games API's, nay of which use a fixed-point pipeline. It is an issue for
OpenGL, which uses a floating point pipeline, forcing processor mode switches
back and forth for every primitive.
Mark Kilgard
In article <322EEC...@nstl.com>, Stephen Platt <st...@nstl.com> writes:
|>
|> In a nutshell, OpenGL is a broad, expansive API, covering a wide range of
|> hardware
|> platforms. As it changes, the changes need time to propagate across the
|> vendor
|> space. (See "ARB", also "multivendor consortium.")
|>
|> Changes in OGL *do take time* to come into being.
|>
|> D3D is proprietary. One vendor setting the specs, a smaller market space
|> supporting it. Low mass. It can respond to change quickly; if the user
|> space
|> suddenly decides it needs Gizmo3 support, it can be added quickly. Without
|> six vendors' worth of incompatible extensions, followed by spec proposals,
|> ARB debates, and actual implementation.
If that is your understanding of things, please let me correct it.
OpenGL vendors are free to implement whatever extensions they
deem worthwhile. There is no need for ARB approval. Microsoft has
implemented its own extensions this way; as does Brian Paul's Mesa,
as does Cosmo OpenGL; as does SGI for its latest graphics subsystems.
Even the EXT extensions do not require ARB approval per se. They
simply require the commitment of multiple ARB members to implement
them. For the sake of consistency and good design, there generally
is discussion within the ARB of EXT extensions, but it not typically
a lengthly or particularly rigorous process.
Still if any vendor thought the EXT process was too cumbersome for
proprietary extension, they are free to simply implement whatever they
want.
Standards like OpenGL 1.1 do ential ARB review and approval, and the
ARB members worked very quickly and efficiently to release OpenGL 1.1.
In part, this is because, OpenGL specification revisions are made by
incorporating successful extensions.
As for your assertion about multiple sets of incompatible extensions,
maybe you can explain what you mean. OpenGL extensions are typically
quite clear about how they interact with the main spec and other related
extensions. I'm aware of no incompatible extensions.
OpenGL has a track record of scores of innovative extensions being
implemented dusring the last few years. This demonstrates the openness
of the OpenGL API for vendor extensibility.
On the other hand, Direct3D has no such extension mechanism. Presumably,
extensions to Direct3D immediate mode can come only from Microsoft. If
3Dlabs or 3Dfx or any other PC company has a great idea, the best they can
do is petition Microsoft to include the feature at some point in some
future Direct3D.
You argue that one vendor and a less established user base are an
advantage to revising Direct3D. But Microsoft today can make whatever
independent extensions they desire to OpenGL already. If Microsoft
has great ideas, they could just as easily unilaterally extend OpenGL.
The downside is the only source of innvotion is Microsoft; OpenGL
benefits from a much broader pool of innovators.
Also, if you look at Direct3D IM's execution buffer model with an
exposed "protocol", it is actually considerably harder to extend
that sort of an implicit API than one like OpenGL with clean entry
points. Direct3D has no capability for extensibility other than by
what Microsoft makes it, and for technical reasons, even that is
difficult.
- Mark
Mark Kilgard
In article <323416...@amherst.com>, Martin Szinger <m...@amherst.com> writes:
|> Stephen H. Wright wrote:
|> >
|> > Several people in this thread have been making the point that Microsoft should
|> > support a single API for the games and professional 3D communities, partly to
|> > simplify the API story on the Microsoft platform, and partly to provide
|> > portability to other platforms. [...]
|> >
|> > Thinking about the historical factors, it might help if everyone in this
|> thread
|> > would step back for a minute and remember how we got here.
|>
|> From my vantage point, the rest of this discussion looks like a laundry list
|> of
|> technical obstacles facing OpenGL on Wintel HW/SW that have been successively
|> |> overcome. So bravo MS! But now, you can't really use this to justify the
|> existence
|> of Direct3D anymore, can you?
Stephen and Hock certainly seem to be trying.
- Mark
Mark Kilgard
In article <5121mo$l...@news.microsoft.com>, swr...@microsoft.com (Stephen H.
Wright) writes:
|> >
|> >Cosmo OpenGL would not even have to exist then!
|>
|> And imagine how easy this would have been if SGI had "simply" provided a
|> reasonably apt games API and competitive sample implementation when Microsoft
|> |> needed it!
Does SGI have to lay a golden OpenGL implementation on your doorstep?
Who do you guys think you are? Microsoft?
Oh, yeah - you guys are Microsoft. I'm sure lots of OpenGL licensees
would love it if SGI wrote their OpenGL implementations too.
|> 3) I have heard through other ISV and IHV contacts that AutoDesk is adamantly
|> "NIH" about OpenGL, having spent money acquiring the Heidi code and feeling
|> that they feel an ongoing need to justify the purchase.
That's unfortunate.
I can think of another large PC software vendor who is also feeling
the need to justify an expensive purchase of inferior technology.
Can you say Direct3D immediate mode?
|> In short, there appear to be multiple sensitive "political" issues involved.
|> However, if you want to continue blaming it on the poor software performance
|> and complex driver support story for OpenGL 1.0, I'll be happy to remind you
|> that both of them derive from the SGI sample implementation, and both problems
|> were not solved until Microsoft redesigned the front end with both software
|> performance and hardware support in mind.
And I will remind you that the Cosmo OpenGL, IMPACT OpenGL, and
InfiniteReality OpenGLs were also all derived from the OpenGL sample
implementation. All the OpenGL implementations (excepting Mesa) have
the same software origin; the differences are due to hardware and
the commitment each vendor makes to their implementations.
- Mark
Mark Kilgard
In article <5123v3$l...@news.microsoft.com>, swr...@microsoft.com (Stephen H.
|> hurdles over the last two years and now we can proceed ahead with OpenGL as a
|> |> games API rather than Direct3D, so why not do it?
|>
|> The answer is that there is already far too much development underway for
|> Direct3D. There are literally dozens of IHV's making hardware that will
|> support the D3D HAL.
Uh, so maybe you can explain how these IHVs are different from:
o OS/2 application developers 8 years ago.
o Network managers using LAN Manager 6 years ago.
o Game developers told WinG was the answer 2 years ago.
o Microsoft Network content providers 1 year ago.
|> There are literally dozens of ISV's writing software that
|> will use the Direct3D interface to take advantage of that hardware. Direct3D
|> is not "overrunning" the market, but it's much closer to a de facto standard in
|> the games market than OpenGL.
Today's best PC games totally ignore both Direct3D and OpenGL. Game
programmers will only care about using 3D APIs when the APIs provide
excellent hardware access. The problem is that Direct3D's flawed execute
buffer architecture will not scale for fast 3D graphics hardware the
way OpenGL is proven to do.
Direct3D's immediate mode is less functional, provides less exposure of
features for hardware acceleration, is less extensible, and completely
lacks portability to other platforms.
|> You suggest that Microsoft has shown in the past that it can abandon an
|> unproductive approach and switch gears. This is true, but it is also true that
|> Direct3D is not, today, an unproductive approach. We're not going to abandon
|> it any more than we're going to abandon OpenGL. Both API's have a lot of
|> momentum going for them in different markets.
Give me a break. Both APIs do essentially the same thing. They both
transform and rasterize polygons. Why do PC users, developers, and
hardware vendors have to divide or duplicate their efforts to accomplish
the same basic operation?
The idea that "game" 3D is different from "real" 3D is just wrong. A
low-level API provides access to a technology - in this case, interactive
3D graphics. Microsoft has invented this unjustifiable distinction between
types of 3D. Eventually, games will want to do the kind of serious
things done by "real" 3D apps (and CAD designers will also want to take
a break and play games). Microsoft would do better to advance PC 3D by
focusing on the best 3D API that scales across all the markets for 3D.
The problem is that that simply isn't Direct3D.
I've really got to sympathize with Steve for having to defend Microsoft's
dual 3D API story. Steve knows enough about 3D for me to surmise he's
got to be wondering how Microsoft ended up on two different 3D paths.
- Mark
Stephen H. Wright
Mark -
Your discussion of the OpenGL extension process is technically accurate but
overstates the flexibility and freedom available to vendors in actual practice.
Vendor-specific extensions have some impact on the entire OpenGL community, and
the community often responds to them.
Last April Microsoft experimented with an extension to turn off clip tests in
the pipeline when the application "knew" that it would not be necessary (for
example, by higher-level bounds tests). Hock's informational posting stirred
up a thread that ran for almost a month and generated lots of feedback both pro
and con. Particularly germane in this context was a discussion over whether to
use Hint or Enable semantics, and a discussion as to whether an inadvertent
perspective divide by 0 as a result of application error would constitute a
violation of the OpenGL specification.
This is not a complaint about that feedback. It's a critical part of an open
industry standard process. The licensees have a responsibility to try to
prevent one implementor from going off and creating extensions that lead to
confusing and inconsistent semantics for ISV's to sort through, or which break
the operating assumptions of OpenGL. In addition, as new extensions are
offered by different vendors, we face the natural tension between maintaining a
standard and offering differentiating value, and over time either have to pull
significant new functionality into a common core or say goodbye to having a de
facto standard.
I said "responsibility", but I didn't say "authority", and, as you suggest,
vendors may do what they want. However, this is a no-win situation for
Microsoft. I suggest that if Microsoft had done something as dramatic as
implementing a low-precision, color index mode of OpenGL, if it wasn't
interested in giving that technology back to the ARB, and if we did it all in a
blazing hurry without paying any attention to ARB feedback -- if we did all
that, we'd be facing even more Microsoft-bashing from the ARB and SGI than we
are today. I believe we would then be criticized for:
1) Undercutting the professional quality of OpenGL's subpixel precision
standards by promoting a cheap games rendering engine under OpenGL's hood.
There would be ongoing concern and confusion over whether or not we used
non-conformant short-cuts to improve benchmark results.
2) Ignoring the OpenGL community "in typical arrogant Microsoft fashion".
3) Attempting to subvert and ultimately take over the API by introducing
non-portable extensions on the volume-leading platform.
I even venture to suggest that SGI would eventually have implemented their own
"Cosmo GL", a competing implementation intended to prove that you don't have to
"cut corners" to get the same performance! ;-)
Steve Wright
OpenGL Program Manager
Microsoft Corporation
In article <513bbv$h...@fido.asd.sgi.com>, m...@woodsy.asd.sgi.com says...
Stephen H. Wright
Mark -
It might help us all stay focussed on the issues rather than the people if you
were to actually address the reasons I've given rather than dismissing them
(i.e., "Stephen and Hock certainly seem to be trying."). If recollection
serves, I've listed several technical reasons why OpenGL wasn't anywhere near
meeting our needs for a game API back when we began investing in one.
Steve Wright
OpenGL Program Manager
Microsoft Corporation
In article <513cu9$h...@fido.asd.sgi.com>, m...@woodsy.asd.sgi.com says...
>
>In article <323416...@amherst.com>, Martin Szinger <m...@amherst.com>
writes:
>|> Stephen H. Wright wrote:
>|> >
>|> > Several people in this thread have been making the point that Microsoft
should
>|> > support a single API for the games and professional 3D communities,
partly to
>|> > simplify the API story on the Microsoft platform, and partly to provide
>|> > portability to other platforms. [...]
>|> >
>|> > Thinking about the historical factors, it might help if everyone in this
>|> thread
>|> > would step back for a minute and remember how we got here.
>|>
>|> From my vantage point, the rest of this discussion looks like a laundry
list
>|> of
>|> technical obstacles facing OpenGL on Wintel HW/SW that have been
successively
>|> |> overcome. So bravo MS! But now, you can't really use this to justify
the
>|> existence
>|> of Direct3D anymore, can you?
>
Stephen Drye
Stephen H. Wright wrote:
>
> Ironically, while most hardware improvements tend to level the playing field in
> the "API wars", MMX actually increases the importance of Direct3D in the
> software rasterization arena for fairly arcane tecnical reasons. MMX has some
> great instructions for improving the performance of the inner scanline loop;
> unfortunately, at any given point in time you have to choose between normal
> floating point operations and these parallel integer operations. The switch
> between the two modes is relatively expensive, but this is not an issue for
> games API's, nay of which use a fixed-point pipeline. It is an issue for
> OpenGL, which uses a floating point pipeline, forcing processor mode switches
> back and forth for every primitive.
Except for the fact that Quake has proven beyond a doubt that it is time
for
the use of fixed-point to go the way of the Dodo.
From any perspective (pardon the pun ;) ) fixed point math for 3D
existed as
a way around the previously poor floating point performance of Intel
processors. That isn't an issue anymore, and with floating point being
much simpler and more flexible to use, fixed point won't be preeminent
much longer. See Mike Abrash's column in the latest Dr. Dobb's
Sourcebook
issue for more details.
Hmm, D3D uses fixed point. OpenGL uses floating. Who is better
positioned
for the "new world order"?
Stephen Drye
scd...@entrust.com
Not speaking for Nortel Secure Networks.
Stephen H. Wright
Mark -
In article <513elm$h...@fido.asd.sgi.com>, m...@woodsy.asd.sgi.com says...
>
>In article <5121mo$l...@news.microsoft.com>, swr...@microsoft.com (Stephen H.
>Wright) writes:
>|> >
>|> >Cosmo OpenGL would not even have to exist then!
>|>
>|> And imagine how easy this would have been if SGI had "simply" provided a
>|> reasonably apt games API and competitive sample implementation when
Microsoft
>|> |> needed it!
>
>Does SGI have to lay a golden OpenGL implementation on your doorstep?
>Who do you guys think you are? Microsoft?
>
>Oh, yeah - you guys are Microsoft. I'm sure lots of OpenGL licensees
>would love it if SGI wrote their OpenGL implementations too.
Wait a minute. *You're* the one who wants Microsoft to have released a
games-appropriate OpenGL library. All I've done is continue to remind you that
the performance of the sample implementation, the hardware capabilities, and
the feature set of the API we licensed from SGI did not meet the requirements
of that market. If it was so important to SGI's business that Microsoft
promote OpenGL for running 3D games, then SGI damn well should have been
selling technology that did the job.
As far as wanting to have everything done for us goes, though: it took
Microsoft three years to turn that sample implementation into the 1.1 product
we're shipping today, just to meet the needs of the technical workstation
market. We had to design and implement an architecture for both NT and 95 that
would support software rendering as well as hardware acceleration. We had to
design and implement windowing system extensions to integrate OpenGL graphics
with Windows and GDI. We had to port the code to our platform (a bigger job
than porting between UNIX platforms). We had to provide better Windows
environment integration, in the form of font utilities, printing and metafile
support. We had to develop a DDK to enable hardware vendors to provide
solutions and drivers for our platform. And we had to tune the software
performance. So the attempted wisecrack about wanting a "golden"
implementation dropped in our laps is out of place.
>|> 3) I have heard through other ISV and IHV contacts that AutoDesk is
adamantly
>|> "NIH" about OpenGL, having spent money acquiring the Heidi code and feeling
>|> that they feel an ongoing need to justify the purchase.
>
>That's unfortunate.
>
>I can think of another large PC software vendor who is also feeling
>the need to justify an expensive purchase of inferior technology.
>Can you say Direct3D immediate mode?
Since we're asking rhetorical questions, have you noticed how frequently you
adopt the method of ignoring the issues I raise or the points I address and
seizing on a side issue to turn into yet another (or yet another rehash of a)
criticism?
Let's try to explore the issue a little more instead. I went on to refer to
this as a "sensitive political issue" rather than going on the attack with
AutoDesk. Quite clearly AutoDesk thinks it is important for them to control
their own 3D API, and I actually don't blame them for that. It gives them the
power to innovate easily and fluidly to meet the needs of their own application
development teams. I'd like to evangelize them to use OpenGL -- just as you'd
like to evangelize us to only use OpenGL -- but I think I understand why they
don't today.
As far as the Microsoft RenderMorphics acquisition goes, I'll remind you that
no one has reponded to my list of reasons for the acquisition.
>|> In short, there appear to be multiple sensitive "political" issues
involved.
>|> However, if you want to continue blaming it on the poor software
performance
>|> and complex driver support story for OpenGL 1.0, I'll be happy to remind
you
>|> that both of them derive from the SGI sample implementation, and both
problems
>|> were not solved until Microsoft redesigned the front end with both software
>|> performance and hardware support in mind.
>
>And I will remind you that the Cosmo OpenGL, IMPACT OpenGL, and
>InfiniteReality OpenGLs were also all derived from the OpenGL sample
>implementation. All the OpenGL implementations (excepting Mesa) have
>the same software origin; the differences are due to hardware and
>the commitment each vendor makes to their implementations.
>
>- Mark
Microsoft's commitment is fairly obvious. We've already invested many man
years in the work I outlined above, and we've turned a non-starter on the PC
platform into the industry's leading software implementation. We sell more
bundled OpenGL systems than SGI and the other UNIX vendors combined, and we're
already out with full 1.1 support, ahead of all the other vendors.
This is irrelevant to you, however, because the only litmus of "commitment" you
will accept is for Microsoft to abandon Direct3D and evangelize OpenGL for the
games community. So be it.
Mark Kilgard
In article <514c18$g...@news.microsoft.com>, swr...@microsoft.com (Stephen H.
Wright) writes:
|>
|> Your discussion of the OpenGL extension process is technically accurate but
|> overstates the flexibility and freedom available to vendors in actual
|> practice.
|> Vendor-specific extensions have some impact on the entire OpenGL community,
|> and
|> the community often responds to them.
Whether an extension has an impact on the OpenGL community at large
generally depends on two things:
1. Utility - if the extension is not useful or isn't general enough
or has serious technical flaws, developers will likely deem the
extension "not worth it" and avoid it. In the medium to long-term,
an extension's inherent quality justifies the effort to develop
and use it.
2. Availability - if the extension is useful but only available on
your platform, developers may still pass it by. Typically,
developers want to see a publicly available specification for the
extension so that other vendors might also implement the extension.
The specification also helps developers understand precisely how
the extension operates.
Of course, there may be reasons why a vendor doesn't want the extension to be
widely available (eg: a feature for backward compatibility, something designed
specifically to access a non-general hardware feature, etc). It's a vendor's
decision to decide if an extension is going to be important enough for
the vendor to want to promote the extension's availability through
public dicsussion and specification.
Likewise, utility depends on the vendor. An extension's utility results from
the cleverness and generality of the vendor's design.
My point is that whether extensions that a vendor comes up with are going
to have an impact on the OpenGL community at large depends primarily on
the effort the vendor puts in to establish the utility and availability of
the extension.
Coming back to your point, OpenGL's extension mechanism provides a
_great deal_ of freedom and flexibility to implement extensions. The subtler
point is that OpenGL's framework provides built-in incentives for
a vendor to openly discuss and publically specify extensions in order to
establish their utility and availability. And in turn, these extra steps
help ensure that the extension does mesh well with OpenGL's existing
functionality. It is important to understand that these are not
manadatory steps though.
It's my opinion that OpenGL's framework has the right combination of
invecentives to make sure vendors keep adding functionality and do so
in a way that advances OpenGL as a whole, but vendor's still have
the flexibility to experiment with their own ideas and innovations if
they so choose.
|> Last April Microsoft experimented with an extension to turn off clip tests in
|> the pipeline when the application "knew" that it would not be necessary (for
|> example, by higher-level bounds tests). Hock's informational posting stirred
|> up a thread that ran for almost a month and generated lots of feedback both pro
|> and con. Particularly germane in this context was a discussion over whether to
|> use Hint or Enable semantics, and a discussion as to whether an inadvertent
|> perspective divide by 0 as a result of application error would constitute a
|> violation of the OpenGL specification.
|>
|> This is not a complaint about that feedback. It's a critical part of an open
|> industry standard process. The licensees have a responsibility to try to
|> prevent one implementor from going off and creating extensions that lead to
|> confusing and inconsistent semantics for ISV's to sort through, or which break
|> the operating assumptions of OpenGL. In addition, as new extensions are
|> offered by different vendors, we face the natural tension between maintaining a
|> standard and offering differentiating value, and over time either have to pull
|> significant new functionality into a common core or say goodbye to having a de
|> facto standard.
I see the experience that you describe as an example of OpenGL's framework
working to promote good extensions. I hope you'll agree.
My guess (and hope) is that the feedback you got from the extra time spent
discussing the extension served to better illuminate the extension's
intended functionality. I think vendors should have the freedom to
consult with other ARB members or not, and if the vendor doesn't get
productive advice, the vendor is free to ignore any or all advice given.
In the end, the vendor is the one responsible for the extension's
implementation and ultimate success or failure.
|> I said "responsibility", but I didn't say "authority", and, as you suggest,
|> vendors may do what they want. However, this is a no-win situation for
|> Microsoft. I suggest that if Microsoft had done something as dramatic as
|> implementing a low-precision, color index mode of OpenGL, if it wasn't
|> interested in giving that technology back to the ARB, and if we did it all in a
|> blazing hurry without paying any attention to ARB feedback -- if we did all
|> that, we'd be facing even more Microsoft-bashing from the ARB and SGI than we
|> are today.
It would depend on the extension you implemented. If your low-precision,
color index mode was fast and lots of developers wanted to use it and
the specification was consistent and implementable by others, I think
Microsoft would deserve a great deal of credit.
On the other hand, if it wasn't any faster than what could be done with
today's functionality or it was greatly inconsistent with existing
OpenGL functionality, there would likely be criticism. The real
criticism would come if Microsoft tried to force a flawed extension on
the bulk of the OpenGL community (I'd certainly would hope it would
not).
Ultimately, my point is that Microsoft does indeed have a great deal
of leeway to extend OpenGL to meet the market demands important to
Microsoft. Instead of fragmenting the PC market for 3D technology by
promoting two distinct and incompatible APIs, Microsoft could have
choosen to advance a single API (OpenGL) and simply provided
well-thoughout extensions to address its issues with OpenGL for games.
- Mark
Peter Shenkin
In article <514rbm$a...@news.microsoft.com>,
Stephen H. Wright <swr...@microsoft.com> wrote:
>In article <513elm$h...@fido.asd.sgi.com>, m...@woodsy.asd.sgi.com says...
>>Who do you guys think you are? Microsoft?
>>
>>Oh, yeah - you guys are Microsoft. I'm sure lots of OpenGL licensees
>>would love it if SGI wrote their OpenGL implementations too.
>
>Wait a minute. *You're* the one who wants Microsoft to have released a
>games-appropriate OpenGL library. All I've done is continue to remind you that
>the performance of the sample implementation, the hardware capabilities, and
>the feature set of the API we licensed from SGI did not meet the requirements
>of that market.
Whoa. The issue here is API, not implementation. It is up
to every vendor to implement the API to be as fast as possible on
the hardware the vendor is supporting. You can't really blame
SGI for not having a fast enough implementation for PC platforms.
A sample implementation is supposed to be only an example -- not
a product. Producing a product is the job of whoever is porting
OpenGL to the PC -- Microsoft at first, and now, apparently, SGI
with CosmoGL.
The underlying issue is whether OpenGL is an appropriate API for
games. The answer, based simply on reading the discussion so
far, seems to be "Yes, given the availability of extensions."
This seems to be what games developers have been saying as
well as what the Microsoft people seem to be saying now, though
they seemed to be saying something different a couple of weeks
ago.
As far as implementation is concerned, with the appropriate
extensions, the answer seems also to be "Yes", given what both
Microsoft and SGI claim for their current PC implementations
of OpenGL.
Based on what I've seen so far in this discussion, I don't
really have any reason to believe that Direct3D is a nefarious
scheme by Microsoft to undermine OpenGL; it is quite possible
that the route to fast games in a more general way than each
game having its own set of drivers was simply available faster
with Direct3D than with OpenGL, given the hard task of adding
the right extensions to OpenGL and making it run fast on the PC.
The real questions at this point are (1) whether, at this moment,
there would be any need for Direct3D given the current state of
OpenGL, if Direct3D didn't already exist. It seems likely (based
only on my reading of the discussions in this Newsgroup) that the
answer to this is "No." (2) If the answer to (1) is "No", does
Direct3D need to be supported and further developed, given the
number of people who are already committed to it. I have no
insight into this issue.
If anyone's read this far, I have a technical question concerning
coexistence of CosmoGL and "other" OpenGL implementations. Wouldn't
it be possible for both of these to exist on the same machine,
and for a given application to dynamically link to one or the other
at runtime? For example, a game might be written to first
inquire whether a hardware-accelerated OpenGL exists on the
current platform; if so, link to the DLL that supports it
(presumably, the Microsoft implmentation). Otherwise, link
to the CosmoGL DLL, if it's there, and if the game developer
thinks that's a good idea. Or even allow the user to configure
a game to link to some other OpenGL library.
Some of the Microsoft people have implied that the existence
of CosmoGL makes life harder for games developers. But I
don't understand why this should be. If they write to the
OpenGL API, why does it matter which library is used at runtime?
Of course, if the game requires extensions that only one version
supports, he doesn't have to bother with the others at all, so
life is still easy for him.
-P.
--
****** ********** In Memoriam, Bill Monroe, 1911 - 1996 ******************
* Peter S. Shenkin, Chemistry, Columbia U., 3000 Broadway, Mail Code 3153,*
** NY, NY 10027; she...@columbia.edu; (212)854-5143; FAX: 678-9039 ***
MacroModel WWW page: http://www.cc.columbia.edu/cu/chemistry/mmod/mmod.html