Alex St John on Direct3D vs OpenGL
ast...@bootnet.com
I have a gift for you Chris. Perhaps it will help you sleep better at night.
I was fired three days later for telling Deborah and Paul that they were
idiots for letting Microsoft's 3D strategy be a mess for so long. As you can
see I was fed up. Pior to your open letter, they had decided to go with an
OGL strategy. Pushing these guys, just made them push back.
------------------------------------------------------------- From: Paul
Maritz Sent: Saturday, June 14, 1997 12:06 AM To: Alex St. John; Bill
Gates; Eric Engstrom; Deborah Black; Jay Torborg; Kevin Dallas Subject: RE:
Developers Petition for Open GL
This has been decided. Our strategic direction is D3D.
Wrt Talisman, we will continue to evangelize the approach and design, but it
is separable from the position of pushing D3D forward. We recently had
meeting with Intel’s graphics architects where they validate the key idea’s
in Talisman (chunking, and anisotropic texturing) as being right way to go
(though they think these features can and should be added incrementally to
keep costs down).
We will also be working with Intel to get them to agree on overall graphics
framework, and get their energy directed in same direction as us.
Wrt OGL, we have to ensure that we have good OGL support for NT in
workstation market. We would like to cut our effort in this however, and let
SGI pick up the work. We actually had really interesting mtg today with SGI
where they basically said that they have decided that they are not a software
company, they are not a consumer device company, they are a
workstation/server company, and they see big oppty to inherit traditional
Apple’s role in media community, but UNIX is non-starter to do this, and as a
result they are going to build no-compromise NT machines. In mid’98, they
plan to introduce a $3.5K NT based machine, that will have same performance
as the mid range of their current Octane line ($35K machine today). They want
us to actually get rid of MCD drivers in OGL since they think it results too
constrained a hardware architecture. They want to rework the OGL stack and
give it back to us. Longer term they want to see if there is some way to get
OGL and D3D to share more and more. IFF we can give them an architecture that
allows them to innovate in hardware, and allows them to migrate their OGL
investment, then they are happy to be aligned with us, and have no interest
in trying to migrate apps off native Windows. They have no interest in
helping Java3D, and say that Sun has no interest in working with them. We
will have follow-up mtg to discuss: (a) them picking up support for OGL on
NT, and (b) to understand how they think D3D and OGL can share more
(apparently they have idea’s on this, but paranoia has prevented them from
sharing this to date). Obviously given the position on D3D above, we do not
want to compromise our progress on D3D, but we should listen with open mind.
-----Original Message----- From: Alex St. John Sent: Friday, June
13, 1997 12:08 PM To: Bill Gates; Paul Maritz; Eric Engstrom; Deborah
Black; Jay Torborg; Kevin Dallas Subject: FW: Developers Petition for
Open GL
Boom! Well this has clearly gotten out of hand. This took the concerted
effort of a lot of groups to achieve. Some really poor evangelism and
account management, a little bad media handling, a really screwed up 3D
strategy for too long, and a proactive effort on the part of some current and
former Microsoft employees to push this through. Chris Hecker was kind of
enough to orchestrate the authoring and signing of this petition for us.
I've asked some of the folks I know on this petition to send some email to me
explaining WHY they feel OGL should be our 3D API. They say perfectly
reasonable things like; · It's easier to program to and better documented · I
don't get enough support from Microsoft · I just care about 3DFX HW this
Xmas, and they have an OGL driver for it that supports functionality on their
card, their D3D driver doesn't. (3Dfx is tanking on supporting D3D features
now, because they perceive themselves as being in competition with Talisman)
· I don't get support for the 3D functionality I want/need from Microsoft
fast enough so, I'm hoping SGI, and open support for extensions will do a
better job. · I associate all the broken driver problems I'm having with
Microsoft and D3D. I think having OGL (== API support from SGI) will mean
having fast working drivers.
Our 3D strategy and messaging is an ongoing fiasco. I got back from Europe
this week to learn that there had been a Paulma meeting where this was all
resolved. "Resolved" to me would mean that we have 1 3D driver model for
consumer HW on top of which all of our 3D API's sit, that our effort to make
a "Talisman chip" is kept well clear of association with that driver model,
and that we make it a major priority to rapidly innovate that driver
architecture, and religiously ensure broad, fast, robust support for 3D HW.
Until something like this is done, there will be no "resolution" for this,
just slow painful decline of our leverage and credibility in this space.
Would somebody please make my day and tell me this was "resolved". Because
if it was we really need to get some clear messaging out there fast.
----------
From: Kevin Bachus
Sent: Thursday, June 12, 1997 11:07 PM
To: Kevin Dallas; Alex St. John
Cc: Morris Beton MM - Games; DRG Chat; DirectX Program Managers
Subject: Developers Petition for Open GL
Developers Petition for Open GL
Next Generation Magazine Online
June 13, 1997
A virtual who's who in 3D game developers came together to begin a petition
for Microsoft to actively support the Open GL API within Windows 95 and
Windows NT.
Ever since the introduction of DirectX (and specifically Direct3D) developers
have been massively dissatisfied with the restrictions that it placed upon
game developers. Instead of freeing them, it in many ways shackled them. As a
result, many developers sought other solutions of which one of the most
popular became Open GL. Despite the advances made with revisions of the D3D
APIs (and the introduction of such facets as DrawPrimative) Open GL still
thrived.
In an unusual show of unity, a number of game developers have begun a
petition to Microsoft to have them actively begin supporting Open GL within
Windows 95 so that hardware vendors can begin the development of more fully
featured drivers.
Among the companies represented by the letter were:
• Id Software
• Epic Megagames
• Activision
• Outrage and Parallax
• Totally Games
• Ion Storm
• and dozens of others.
John Carmack best summed up the movement: "The best thing Microsoft could do
for the game community would be to release the Win95 OpenGL MCD framework to
allow hardware vendors to easily build robust, full featured drivers. Without
Microsoft's help, there will be several partial implementations to satisfy
specific requirements, resulting in version problems and incompatibilities.
The strengths of OpenGL are important enough that it is going to be used one
way or another, but life would be so much better if Microsoft cooperated.''
The letter itself actually reads:
We, the undersigned professional game developers, call on Microsoft to
continue its active OpenGL development, to ship its DirectDraw bindings for
OpenGL and the Windows95 MCD driver-enabled OpenGL, and to continue to
improve its implementation of the OpenGL API and its driver models by
aggressively supporting common extensions and future ARB-approved standard
features. As developers, we believe the choice of which 3D API to support for
our games should be ours alone.
We want any 3D API competition to happen on an open technical playing field,
with us, the people who actually write the games, deciding which APIs we
should and should not use. This open technical competition is healthy for the
industry and will result in better games and 3D technology. We recognize
Microsoft must take part in creating this technically competitive environment
because of their control over the operating system, and we urge the company
to be a positive force in doing so by actively supporting OpenGL. The entire
PC game industry will benefit as a result.
Signed,
Bill Baldwin Brian Hook William Scarboro
Sean Barrett Andrew Howe Jason Shankel
Ken Birdwell Brent Iverson Zachary Simpson
Seamus Blackley Rick Johnson David Stafford
Stefan Boberg Dave Kaemmer Tim Sweeney
John Carmack Donavon Keithley Chris Taylor
Glenn Corpes Jason Leighton Dave Taylor
Steve Crane John Lemberger Trey Taylor
Mark Dochterman Peter Lincroft Cameron Tofer
Jim Dose Mike Linkovich Matt Toschlog
James Fleming Jonathan Mavor Neall Verheyde
Rick Genter Stan Melax Charlie Wallace
Ed Goldman John Miles Kevin Wasserman
Chris Green Doug Muir Patrick Wilkinson
Robin Green Casey Muratori David Wu
Mike Harrington John Nagle Pat Wyatt
Ryan Haveson Mike Newhall Billy Zelsnack
Chris Hecker Jay Patel Greg Zeschuk
Lawrence Holland John Romero
Time will tell if Microsoft listens to the development community.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Gavin Bell
Wow, now THAT made all the time I spend scanning this newsgroup
worthwhile...
Did anybody else find it strange that in all those discussions about
3D strategy ONLY Alex even hinted at what would be best for
Joe-average-consumer? It is all strategy, positioning, and
us-versus-them.
Hey, Mr. Gates: IT IS ABOUT THE CUSTOMER, STUPID!
"Ok, we'll support OpenGL on NT because we want to take over the
workstation market, and D3D on 95 because we want to take over the 3D
games market". Didn't ANYBODY besides Alex have the guts to say
"Won't that make our customers' lives miserable, since there will be
twice as many half-baked drivers and customers will have to
distinguish between which cards run which pieces of software?"
Microsoft appears to have plenty of technology evangelists. What they
need is more CUSTOMER evangelists, banging some sense into the heads
of the people who let the price of their stock options inflate their
egos.
Sigh. Not that any OTHER computer company is a whole lot better at
thinking about actually making their customers happy, rather than
thinking about how they can become the next Microsoft...
Gavin Bell (ga...@wasabisoft.com)
SkyPaint 1.0 is here!
http://www.wasabisoft.com/
Russ Williams
Gavin Bell wrote in message <355327a7...@news.binc.net>...
>Wow, now THAT made all the time I spend scanning this
>newsgroup worthwhile...
>
>Did anybody else find it strange that in all those discussions
>about 3D strategy ONLY Alex even hinted at what would be
>best for Joe-average-consumer?
Naive much?
Notice how there was a lot of back-story only hinted at in
those messages and who's email it was? I'm not saying
that Alex trimmed the threads to make himself look good
(how would I know), but you have absolutely no idea
what the other people involved had to say for themselves.
Also, the mail from Paul Maritz clearly states that:
"[SGI] want us to actually get rid of MCD drivers in OGL
since they think it results too constrained a hardware
architecture. They want to rework the OGL stack and
give it back to us."
Wasn't that a big point of contention - how MS tried to
kill OpenGL by killing the Win95 MCDs? Now this
seems to imply that it was _SGI_ that wanted MCDs
killed.
---
Russ
Sean Timarco Baggaley
In article <355327a7...@news.binc.net>, Gavin Bell
<ga...@mailbag.com> writes
>Wow, now THAT made all the time I spend scanning this newsgroup
>worthwhile...
>Did anybody else find it strange that in all those discussions about
>3D strategy ONLY Alex even hinted at what would be best for
>Joe-average-consumer? It is all strategy, positioning, and
>us-versus-them.
>Hey, Mr. Gates: IT IS ABOUT THE CUSTOMER, STUPID!
Since when were software *developers* "customers"? We are third-party
software suppliers. It is *US* who have to give the customer what they
want.
Since customers are clearly buying Win95, Win95-based computer games and
other stuff "we" don't like, it obviously makes fuck-all difference what
*WE* think or say about what they buy. They'll buy it anyway.
>"Ok, we'll support OpenGL on NT because we want to take over the
>workstation market, and D3D on 95 because we want to take over the 3D
>games market". Didn't ANYBODY besides Alex have the guts to say
>"Won't that make our customers' lives miserable, since there will be
>twice as many half-baked drivers and customers will have to
>distinguish between which cards run which pieces of software?"
NT is not -- AND NEVER HAS BEEN -- a consumer OS. It may get marketed as
one at some later date, but at present, it ain't.
Besides, you'd still need a different driver for both Win95 and NT,
since both use different driver models. (Win98 goes some way towards
fixing this, but 98 will take some time to infiltrate and replace the
current Win95 user-base.)
So why the blazes should MS bother converting a workstation-level API to
run on the shitty, no-name, poorly-supported hardware Win95 has to live
with.
NT has a *huge* advantage, shared by many other workstation OSes such as
IRIX, Linux and their ilk: it can be a damned sight pickier as to which
hardware it supports, because its users are willing to pay that premium
for the extra stability and power.
OpenGL was NEVER designed with games in mind. DirectX was. Consequently,
the two have massive differences in their underlying development paths.
While MS have definitely made plenty of mistakes in the past, it's only
fair to point out that *MOST* games developers are now perfectly content
to use the D3D API in DirectX 5 now that the DrawPrimitive() method is
available.
*
Let's take a closer look at those companies whose names were so casually
dropped into one of the emails:
>Among the companies represented by the letter were:
>
> • Id Software
> • Epic Megagames
> • Activision
> • Outrage and Parallax
> • Totally Games
> • Ion Storm
> • and dozens of others.
Noticed that most of that list are licensees (or the developers of) a
certain, well-known, game engine, yet?
Of the seven devcos mentioned, *five* have a vested interest in the
success of the Quake engine. Coincidence?
The dates on those posts also suggests that the discussion was taking
place shortly *before* DX5 was launched; an update that answered enough
of many of the signatories' quibbles (not least being the end of Execute
Buffers.)
Take a look in Dejanews and you'll find that many of the pros here no
longer give a toss about OpenGL. (And the vast majority of the only ones
who do happen to be working on Quake clones in some form or another...)
>Microsoft appears to have plenty of technology evangelists. What they
>need is more CUSTOMER evangelists, banging some sense into the heads
>of the people who let the price of their stock options inflate their
>egos.
Actually, a simple reading of MS' recent press releases (lurking on
www.microsoft.com/directx) will reveal that the entire question is moot:
MS are now working with SGI on the DX/OpenGL 'combined API' called
"Fahrenheit".
Only a tiny (irritatingly vocal) minority really cares about OpenGL any
more.
The rest of us are actually writing games...
--
Sean Timarco Baggaley
Total UCE accounts killed off as a result of my complaints: 6.
Total fines to offenders by ISPs I have complained to: $3500.
Go ahead. Make my day.
E&OE
Link
Sean Timarco Baggaley wrote in message <93QB+EAI...@dial.pipex.com>...
>So why the blazes should MS bother converting a workstation-level API to
>run on the shitty, no-name, poorly-supported hardware Win95 has to live
>with.
This is the prime sticking point I still have with D3D... I think the bar
for entry-level 3D HW was way too low. Accommodating early accelerators
(which there are still quite a few installed) that didn't have fog/efficient
z-buffers/alpha is a royal pain in the ass. From what I've seen, such a
crap bunch of hardware has hindered most of the D3D games out there, because
you can tell they're built to appease the lowest-common denomonator and
don't properly take advantage of the better accelerators' capabilities
(MotoRacer for one... there are many others) This is why Quake1/2 were such
convincing arguments for OGL... they simply look better than D3D games.
Anyways, the politics at Microsoft & SGI, exposed in this thread (though
possibly not accurately) make for interesting reading. I kinda wish these
details were known a long time ago... only if because then people wouldn't
have wasted a lot of arguments on speculative issues.
>NT has a *huge* advantage, shared by many other workstation OSes such as
>IRIX, Linux and their ilk: it can be a damned sight pickier as to which
>hardware it supports, because its users are willing to pay that premium
>for the extra stability and power.
>
>OpenGL was NEVER designed with games in mind. DirectX was. Consequently,
>the two have massive differences in their underlying development paths.
Yuck, you're just parroting Alex St. John's line... I don't think it's a
valid one. OGL was built over the years to accommodate what the graphics
community found it required for 3D apps. "3D for games" is a meaningless
statement.
>While MS have definitely made plenty of mistakes in the past, it's only
>fair to point out that *MOST* games developers are now perfectly content
>to use the D3D API in DirectX 5 now that the DrawPrimitive() method is
>available.
Even I have to admit that some of the features lined up for DX6 sound rather
tasty.
>Let's take a closer look at those companies whose names were so casually
>dropped into one of the emails:
>
>>Among the companies represented by the letter were:
>>
>> • Id Software
>> • Epic Megagames
>> • Activision
>> • Outrage and Parallax
>> • Totally Games
>> • Ion Storm
>> • and dozens of others.
>
>Noticed that most of that list are licensees (or the developers of) a
>certain, well-known, game engine, yet?
I think that smaller developers were pushing for OGL, not just id & their
minions. It's an easier to use API that could've reduced development time.
I know you hear veterans talking about it being "a week's work" to switch..
but I really think it's a heck of lot of work to accomodate the variety of
HW via D3D. I could just be thick.
>Actually, a simple reading of MS' recent press releases (lurking on
>www.microsoft.com/directx) will reveal that the entire question is moot:
>MS are now working with SGI on the DX/OpenGL 'combined API' called
>"Fahrenheit".
Well... yes. This war seems to be one of those poor dead horses everyone
continues to beat because, well, things are more difficult where they
*might* have been easier. Unfortunately (like with Apple), MS didn't so
much engineer the death of OGL, SGI seems to have helped plenty with that.
- Mike
Javier Arevalo
Sean Timarco Baggaley <stbag...@stimarco.cix.co.uk> wrote:
>OpenGL was NEVER designed with games in mind. DirectX was. Consequently,
>the two have massive differences in their underlying development paths.
While I agree with this point, I think that the whole issue is
confused. Is it an API problem, or a whole architecture problem?
People talk about OpenGL because itæ„€ a nice API, but I donæ„’ buy
this.
>Noticed that most of that list are licensees (or the developers of) a
>certain, well-known, game engine, yet?
In the list of signatures on the letter there were people from
Electronic Arts, Bullfrog, etc (who "casually" happen to frequent RGP
too).
>The dates on those posts also suggests that the discussion was taking
>place shortly *before* DX5 was launched; an update that answered enough
>of many of the signatories' quibbles (not least being the end of Execute
>Buffers.)
If somebody thinks that the issue was Execute Buffers, then my faith
in the intelligence of game developers is totally lost. The issue is
about drivers, extensibility, API development control,
consumer-oriented hardware, and why not, a chunk of PR blahblah.
>MS are now working with SGI on the DX/OpenGL 'combined API' called
>"Fahrenheit".
Fahrenheit is
1) a way for Microsoft to get rid of the bad name made by Direct3D
while "staying in control".
2) a way for SGI to save their face and let OpenGL/PC die gracefully
while "staying in control".
Fahrenheit will be what Microsoft decides it to be. They might as well
call it "Direct3D 8.0" but a new name soudns better. And yes, I like
things the way they are because there is a consumer-oriented company
devoted to ensuring widespread support. Which is what I care about in
the end, I will stand a few headaches going around the API quirks.
Greets
Javier Arevalo
http://web.jet.es/jare
change nospam to jare in the address to send email
Javier Arevalo
"Link" <mik...@interlog.com> wrote:
>I think that smaller developers were pushing for OGL, not just id & their
>minions. It's an easier to use API that could've reduced development time.
>I know you hear veterans talking about it being "a week's work" to switch..
>but I really think it's a heck of lot of work to accomodate the variety of
>HW via D3D. I could just be thick.
Since we will never know what would have it been like to develop using
OpenGL for cards such as the Mystique, Rendition, PowerVR and S3
Virge, we will never know if it was a good or bad idea.
I don“t hear the "support for available consumer hardware" part in
OpenGL / Glide advocates. I only hear "it“s easier".
Gavin Bell
>>Did anybody else find it strange that in all those discussions about
>>3D strategy ONLY Alex even hinted at what would be best for
>>Joe-average-consumer? It is all strategy, positioning, and
>>us-versus-them.
>
>>Hey, Mr. Gates: IT IS ABOUT THE CUSTOMER, STUPID!
>
>Since when were software *developers* "customers"?
Huh? I said JOE-AVERAGE-CONSUMER. You know, the guy who goes down to
CompUSA, asks the salesperson which board is best for games and costs
less than $174.99, and then gets to sit through a lecture on "Well, if
you want to run Quake, then this one is better, if you want to run
XXX, then this one is better. Oh, and be sure to get the latest
drivers from http://www...com/, the ones that come in the box are
screwed up."
So are you going to tell me with a straight face that if Microsoft had
adopted OpenGL three years ago that the 3D hardware and drivers would
be just as screwed up as they are now?
That if Permedia and 3DFX and all the other chip companies didn't have
to develop THREE DIFFERENT SETS OF DRIVERS (one set for OpenGL on
Win95, one for OpenGL on WinNT, one for Direct3D) instead of only two
that they wouldn't be less likely to crash and burn so often?
>Since customers are clearly buying Win95, Win95-based computer games and
>other stuff "we" don't like, it obviously makes fuck-all difference what
>*WE* think or say about what they buy. They'll buy it anyway.
I don't care about developers. Anybody have return-rate figures for
add-in 3D graphics boards? Anybody have return-rate figures for
hardware-accelerated games. Oops, I forgot, you can't return software
at most places, so if that game you bought needs alpha blending and
that hardware you bought six months ago doesn't support blending then
I guess you're just screwed...
The sad thing is that SGI went through all that incompatibility
nonsense-- used to be a lot of IRIS GL features were supported on
high-end SGI systems but not the low-end systems. OpenGL was
originally slated to be "IRIS GL 5.0", with all of that crap cleaned
up (with a rich set of features GUARANTEED to at least work, a clean
extension mechanism, etc). So there's no excuse for Microsoft
subjecting their customers to a world of incompatible hardware and
software.
Javier Arevalo
ga...@mailbag.com (Gavin Bell) wrote:
>up (with a rich set of features GUARANTEED to at least work, a clean
>extension mechanism, etc). So there's no excuse for Microsoft
>subjecting their customers to a world of incompatible hardware and
>software.
Sounds like you did not accept that low-end 1st generation
accelerators deserved a place in the market. I disagree wit hthat view
of the consumer dynamics... even though I hate supporting things like
the Mystique or not using 3Dfx to the max.
Matt Craighead
Gavin Bell wrote:
> So are you going to tell me with a straight face that if Microsoft had
> adopted OpenGL three years ago that the 3D hardware and drivers would
> be just as screwed up as they are now?
Yes. More so. And, actually, it's not so bad now.
> That if Permedia and 3DFX and all the other chip companies didn't have
> to develop THREE DIFFERENT SETS OF DRIVERS (one set for OpenGL on
> Win95, one for OpenGL on WinNT, one for Direct3D) instead of only two
> that they wouldn't be less likely to crash and burn so often?
What if they only had to develop D3D drivers?
> I don't care about developers. Anybody have return-rate figures for
> add-in 3D graphics boards? Anybody have return-rate figures for
> hardware-accelerated games. Oops, I forgot, you can't return software
> at most places, so if that game you bought needs alpha blending and
> that hardware you bought six months ago doesn't support blending then
> I guess you're just screwed...
"I don't care about developers" is a bad sign.
In the computer industry, it's NORMAL to buy hardware and have it be
obsolete within a year. 3D is just moving faster than the rest; that's
all.
Don't get any illusions into your head that software emulation solves
anything. Sure, you might end up with the right image on the screen,
but at 5 fps if you're lucky, considering all the 2D-3D switches (one
per HW/SW switch) and the slow speed of all software 3D emulation.
> The sad thing is that SGI went through all that incompatibility
> nonsense-- used to be a lot of IRIS GL features were supported on
> high-end SGI systems but not the low-end systems. OpenGL was
> originally slated to be "IRIS GL 5.0", with all of that crap cleaned
> up (with a rich set of features GUARANTEED to at least work, a clean
> extension mechanism, etc). So there's no excuse for Microsoft
> subjecting their customers to a world of incompatible hardware and
> software.
See above about emulation.
Most of the problems are not MS's fault, BTW. D3D works well. The
drivers are so-so. I can't be sure, but I'm guessing that DX6 will
make D3D a clear choice over OGL. It's adding great new functionality
while improving ease of use and performance. Of course, everything is
just rumor still (unless you're at CGDC, lucky bastards), but soon
I'll know what is real and what is fake -- just a few more days and
I'll be getting that beta CD. Of course, that NDA will make me shut
up as well, but until then, I'm clear. :)
Remember that the level of criticism of D3D took a SHARP drop after
DX5 was released.
DX6 won't be in consumers' hands for another two months or so, but if
you're a developer and your project isn't almost done, it is an
important consideration.
--
Matt Craighead
Engineer, Window Painters, Ltd.
http://www.windowpainters.com
Chris Hecker
ast...@bootnet.com writes:
>I have a gift for you Chris. Perhaps it will help you sleep better at night.
>I was fired three days later for telling Deborah and Paul that they were
>idiots for letting Microsoft's 3D strategy be a mess for so long. As you can
>see I was fed up. Pior to your open letter, they had decided to go with an
>OGL strategy. Pushing these guys, just made them push back.
Ah, a new strategy for Alex, imply it was my fault that OpenGL was
deprecated by Microsoft. This one's as tired as the others, Alex, and
as usual it ignores all the other things Microsoft did to try to kill
OpenGL that needed no prompting from me or others.
It's a testament to your considerable marketing skills that you've
convinced some people who don't know you that you were trying your
best for us developers and our industry. Maybe someday you'll realize
you could be spending that energy constructively.
Chris
ast...@bootnet.com
> Ah, a new strategy for Alex, imply it was my fault that OpenGL was
> deprecated by Microsoft. This one's as tired as the others, Alex, and
> as usual it ignores all the other things Microsoft did to try to kill
> OpenGL that needed no prompting from me or others.
I didn't "imply" anything Chris, I outright said it, and then supported it
with evidence. Need some more? Nobody important at Microsoft really gave a
damn about whether or not OGL was going to be the MS API, because nobody
thought of it as a competitive API threat from SGI anymore until it blew up
in the media with your help. A few days earlier, Bill had sent mail saying
it would be fine if they innovated from the OGL code base. When they smell
an API threat, they squish it. You know that.
> It's a testament to your considerable marketing skills that you've
> convinced some people who don't know you that you were trying your
> best for us developers and our industry. Maybe someday you'll realize
> you could be spending that energy constructively.
>
> Chris
>
Blah, blah, blah, I was doing what I thought was best for Microsoft, and that
meant having strong developer support. What was best for Microsoft was
having a developer community that was happy with them. Making 3 different 3D
API's, 4 different 3D drivers, and wild assed 3D hardware wasn't serving
anybody well.
What exactly do you think I or Microsoft did to kill OGL Chris? You know
Bill gave me the letter you sent him about your hallucination that I was
lying to the press about OGL. What you seem to have thought I was saying to
the press on my own was Microsoft's official positioning of its 3D API's that
they spent weeks deciding on internally. Microsoft's implimentation of OGL
was to be "targeted" at the high end, ie. to Kill Unix apps according to
Bill, and D3D at the low end for consumers. It wasn't my opinion about what
the API's were capable of. Maybe if you actually spoke to me other than
saying "hi" at the occasional social event we run into, you might actually
know something about what went on, instead of clinging to this persistent
fantasy you seem to have. Maybe you just like the fantasy more than the
truth, it seems to involve less personal culpability for you.
There was never a technology battle between OGL and D3D, just a political
battle between the people controlling those technologies, I was a casualty,
and your side lost.
Jason Shankel
ast...@bootnet.com wrote:
>
> > Ah, a new strategy for Alex, imply it was my fault that OpenGL was
> > deprecated by Microsoft. This one's as tired as the others, Alex, and
> > as usual it ignores all the other things Microsoft did to try to kill
> > OpenGL that needed no prompting from me or others.
>
> I didn't "imply" anything Chris, I outright said it, and then supported it
> with evidence. Need some more? Nobody important at Microsoft really gave a
> damn about whether or not OGL was going to be the MS API, because nobody
> thought of it as a competitive API threat from SGI anymore until it blew up
> in the media with your help. A few days earlier, Bill had sent mail saying
> it would be fine if they innovated from the OGL code base. When they smell
> an API threat, they squish it. You know that.
>
Alex,
I'm confused. I thought you said that OpenGL was a "high level" API and
D3D was "driver model". I thought you said that the two APIs, despite
some interface similarities, were fundamentally different.
This being the case, why would the D3D group have the
toe-may-toe/toe-mah-toe attitude you imply? Why would they have been
considering OpenGL as the D3D strategy at all? Were they really as
clueless as you imply the rest of us were? Could they realy not tell
the difference between a low-level driver interface like D3D and a high
level API like OpenGL?
So, despite all previous arguments that D3D is a better technical
solution to the consumer hardware problem, in reality Microsoft favored
D3D over OpenGL because their feelings were hurt by Chris' letter? Are
they REALLY that petty and childish?
--
Jason Shankel,
Maxis, Inc.
s h a n k e l
at
p o b o x . c o m
Jonathan Blow
>What exactly do you think I or Microsoft did to kill OGL Chris? You know
>Bill gave me the letter you sent him about your hallucination that I was
>lying to the press about OGL. What you seem to have thought I was saying to
>the press on my own was Microsoft's official positioning of its 3D API's that
>they spent weeks deciding on internally. Microsoft's implimentation of OGL
>was to be "targeted" at the high end, ie. to Kill Unix apps according to
>Bill, and D3D at the low end for consumers. It wasn't my opinion about what
>the API's were capable of.
So lemme get this straight, Alex... you're saying that because they were
Microsoft's official lies you were spreading to the press, and not your
personal lies that you made up yourself, that it's okay? "Like hey, man,
I was just doing my job." Or something.
As I recall, you stated early and often that "OpenGL was designed for high-end
applications like CAD and is unsuitable for games". Whenever you said
these things, you were talking about OpenGL in general, not Microsoft's
implementation of OpenGL, as you are now trying to (quite weakly) claim.
So were you intentionally misleading the press back then, or are you
just trying to revise history now?
>Maybe if you actually spoke to me other than
>saying "hi" at the occasional social event we run into, you might actually
>know something about what went on, instead of clinging to this persistent
>fantasy you seem to have. Maybe you just like the fantasy more than the
>truth, it seems to involve less personal culpability for you.
Let's keep all punches above the belt, okay? If this keeps up, someone's
going to mention Adolf Hitler, or TH3 BIFFSTER!!!!! will join the 'debate'.
>There was never a technology battle between OGL and D3D, just a political
>battle between the people controlling those technologies, I was a casualty,
>and your side lost.
*WE* (developers who understand something about graphics APIs) know that there
was never a technology battle between OGL and D3D. D3D can't compete.
However, Microsoft's side of the political battle is all about how D3D
is technologically superior to OpenGL. We must refute this. You understand
all these things, so why are you trying to make an issue out of it?
As for your assertion that OpenGL "lost": it was pretty clear at the
CGDC this year that OpenGL has more support among developers than ever.
For example, few people were talking about how to achieve high-end
effects with Direct3D. A lot of people were talking about how to do
things in OpenGL.
-J.
ast...@bootnet.com
In article <35574C...@seesig.for.address>,
Both groups had a stake in 3D, the question was which group would own
everything 3D, I repeat, it had nothing to do with D3D vs. OGL as
technology. They had the word "3D" in common, it was the idea not the bits
that mattered. Read Dilbert sometime, it was just like that. I once asked a
Microsoft V.P. for a suggestion on a good management book, and he seriously
told me that the only book that had helped him at Microsoft was "The Dilbert
Principal". I read it, he was right. The difference between them and
children is that kids fight over candy, Microsoft groups battle over power
worth millions in stock options.
Perhaps you heard that Brad Silverberg has "Effectively" left Microsoft...
old executives never die, they just vest away. There was an ongoing battle
between Brads organization which owned Win95, and Alchins organization which
owned NT for control of Microsofts platform definition and strategy. D3D was
on the Win95 side, OGL was on the NT side.
ast...@bootnet.com
In article <6j7nq5$f...@scam.XCF.Berkeley.EDU>,
Jonathan Blow <j...@bolt-action.com> wrote:
>
> In article <6j6hv3$m3$1...@nnrp1.dejanews.com>, <ast...@bootnet.com> wrote:
>
> >What exactly do you think I or Microsoft did to kill OGL Chris? You know
> >Bill gave me the letter you sent him about your hallucination that I was
> >lying to the press about OGL. What you seem to have thought I was saying
to
> >the press on my own was Microsoft's official positioning of its 3D API's
that
> >they spent weeks deciding on internally. Microsoft's implimentation of OGL
> >was to be "targeted" at the high end, ie. to Kill Unix apps according to
> >Bill, and D3D at the low end for consumers. It wasn't my opinion about
what
> >the API's were capable of.
>
> So lemme get this straight, Alex... you're saying that because they were
> Microsoft's official lies you were spreading to the press, and not your
> personal lies that you made up yourself, that it's okay? "Like hey, man,
> I was just doing my job." Or something.
Hmmm, I guess that is exactly what it was to the best of your ability to
understand. The only major difference is that I didn't have to gas any
Jewish people to further my nefarious cause. Say, would you like to buy one
of my OpenGL developer skin lamps?
ast...@bootnet.com
> As for your assertion that OpenGL "lost": it was pretty clear at the
> CGDC this year that OpenGL has more support among developers than ever.
> For example, few people were talking about how to achieve high-end
> effects with Direct3D. A lot of people were talking about how to do
> things in OpenGL.
>
> -J.
>
I assure you, OpenGL is as dead as DOS. You'll probably need 24 months to
fully realize it, but it's true. Feed me these words in two years if I'm
wrong. :)
Chris Hargrove
>I assure you, OpenGL is as dead as DOS. You'll probably need 24 months to
>fully realize it, but it's true. Feed me these words in two years if I'm
>wrong. :)
Why wait two years? Can't we just feed them to you now?
--
Chris Hargrove
Programmer, 3DRealms Entertainment
chr...@3drealms.com
http://www.3drealms.com
Jason Shankel
ast...@bootnet.com wrote:
> I assure you, OpenGL is as dead as DOS. You'll probably need 24 months to
> fully realize it, but it's true. Feed me these words in two years if I'm
> wrong. :)
Uh, there's a difference between losing to D3D as a gaming API on the PC
and being as "dead as DOS".
If OGL never takes off as a gaming API (definitely possible), it will at
worst be relegated back to the industry for which it was originally
designed (high-quality workstation graphics, professional imaging,
etc). Hell, even Microsoft admits that OpenGL is better suited to those
environments.
DOS was effectively controlled by a single company, served a single
purpose and was killed by planned obsolescence. OpenGL is controlled by
a multi-company ARB which has a diverse set of requirements and is not
bound by the PC gaming industry or by Microsoft.
So, while it is not reasonable to say that GL is as "dead as DOS", it
MIGHT be reasonable to say that GL is about as relevant to games as
Unix, though judging by the GL turnout at CGDC this year I think even
this is premature.
And you may feed me my words when SIGGRAPH papers stop using GL and
start using Farenheit.
--
Jason Shankel,
Maxis, Inc.
email provider: p o b o x . c o m
user id: s h a n k e l
Good luck with that one, spambots.
Paul Hsieh
ast...@bootnet.com said:
> > As for your assertion that OpenGL "lost": it was pretty clear at the
> > CGDC this year that OpenGL has more support among developers than ever.
> > For example, few people were talking about how to achieve high-end
> > effects with Direct3D. A lot of people were talking about how to do
> > things in OpenGL.
>
> fully realize it, but it's true.
That would imply that DOS is dead. Besides you
> [...] Feed me these words in two years if I'm wrong. :)
Well ... does that mean we get to feed words to you that you mentioned two
years ago too? (Probably some crap about execute buffers?)
What kind of nonsense was this guy spouting two years ago? Anyone have
anything on record? (Keep in mind Carmack didn't go on his famous .plan
rant until Dec 1996, so nobody gave a fuck about who Alex St. John was back
then.)
--
Paul Hsieh
email,finger: q...@pobox.com
URL: http://www.pobox.com/~qed
Chris Hecker
ast...@bootnet.com writes:
>I didn't "imply" anything Chris, I outright said it, and then supported it
>with evidence. Need some more? Nobody important at Microsoft really gave a
>damn about whether or not OGL was going to be the MS API, because nobody
>thought of it as a competitive API threat from SGI anymore until it blew up
>in the media with your help.
Sorry, but you're ignoring the OpenGL features that were in the works
but stopped long before my articles came out (ddraw bindings, MS's
multitexture extension, MCD for Win95, a supported Win95 ICD kit,
etc.).
>Bill gave me the letter you sent him about your hallucination that I was
>lying to the press about OGL.
Alex, you lied to the press about OpenGL, you lied to your management
about developer interest in OpenGL, you've lied about me to people
behind my back--you lie when it suits you. I only started posting to
this thread when you spewed more technical falsehoods. This is fine,
and you seem to be proud of this (when confronted on a lie you usually
take the "it's marketing, dude" attitude), however why would you
expect me to say anything more than "hi" to you when you can't be
trusted? I actually like you in a social way, but I certainly don't
trust you.
If I ever saw any indication you had changed I'd be happy to talk to
you. You know my email address. Alex St. John is welcome to send
mail any time. "The Saint" needn't bother.
Chris
Paul Hsieh
nos...@jet.es said:
> chr...@3drealms.com (Chris Hargrove) wrote:
> >>I assure you, OpenGL is as dead as DOS. You'll probably need 24 months to
> >>wrong. :)
>
>
He's no longer the messenger. Microsoft fired him. Now he's just a loud
mouth with a column on Boot.
> D3D is here to stay, that is obvious from the momentum if you actually
> step back a bit and look at both OGL & D3D. The DX team takes 1 year
> to make the next version, the ARB takes one year to agree on what
> issues should be discussed.
But in absence of a committee to discuss DX, Microsoft makes mistakes that
take time to correct.
> That's at least my perception. Not using OpenGL I may be mistaken in
> that perception...
Javier Arevalo
chr...@3drealms.com (Chris Hargrove) wrote:
>>I assure you, OpenGL is as dead as DOS. You'll probably need 24 months to
>>fully realize it, but it's true. Feed me these words in two years if I'm
>>wrong. :)
>Why wait two years? Can't we just feed them to you now?
Yeah kill the messenger.
D3D is here to stay, that is obvious from the momentum if you actually
step back a bit and look at both OGL & D3D. The DX team takes 1 year
to make the next version, the ARB takes one year to agree on what
issues should be discussed.
That's at least my perception. Not using OpenGL I may be mistaken in
that perception...
ast...@bootnet.com
In article <3558A9...@bottom.for.e-mail>,
see...@bottom.for.e-mail wrote:
>
> ast...@bootnet.com wrote:
>
> > I assure you, OpenGL is as dead as DOS. You'll probably need 24 months to
> > fully realize it, but it's true. Feed me these words in two years if I'm
> > wrong. :)
>
> and being as "dead as DOS".
>
> If OGL never takes off as a gaming API (definitely possible), it will at
> worst be relegated back to the industry for which it was originally
> designed (high-quality workstation graphics, professional imaging,
> etc). Hell, even Microsoft admits that OpenGL is better suited to those
> environments.
>
> DOS was effectively controlled by a single company, served a single
> purpose and was killed by planned obsolescence. OpenGL is controlled by
> a multi-company ARB which has a diverse set of requirements and is not
> bound by the PC gaming industry or by Microsoft.
>
> So, while it is not reasonable to say that GL is as "dead as DOS", it
> MIGHT be reasonable to say that GL is about as relevant to games as
> Unix, though judging by the GL turnout at CGDC this year I think even
> this is premature.
>
> And you may feed me my words when SIGGRAPH papers stop using GL and
> start using Farenheit.
>
> --
> Jason Shankel,
> Maxis, Inc.
>
> email provider: p o b o x . c o m
> user id: s h a n k e l
> Good luck with that one, spambots.
>
A reasonable argument Jason. I hope you're right in the end, but I've seen
too much technology come and go to be a believer. I ask myself who's going
to make enough money off OpenGL to resuscitate it. Having an Open Standards
body control a technology is actually a sure death sign in my book. It just
means nobody feels enough ownership of the technology to drive it anywhere
aggressively... see Unix. Having lots of hardware companies all rolling
their own drivers for it is another sure sign of death. Nothing can screw up
a technologies reputation faster than having ATI write a driver for it.
ast...@bootnet.com
In article <MPG.fc2a1267...@nntp.chromatic.com>,
> > >>I assure you, OpenGL is as dead as DOS. You'll probably need 24 months
to
> > >>fully realize it, but it's true. Feed me these words in two years if
I'm
> > >>wrong. :)
> >
> >
> > Yeah kill the messenger.
>
> mouth with a column on Boot.
>
> > step back a bit and look at both OGL & D3D. The DX team takes 1 year
> > to make the next version, the ARB takes one year to agree on what
> > issues should be discussed.
>
> take time to correct.
>
> > that perception...
>
It pains me to say this, but I don't think Microsoft is going to be making 3D
mistakes on the scale it was before from now on. They finally pulled
together a unified team. There's a reasonable probability with the focus
they have on it now, that it will improve dramatically and consistently for
the next couple of years... in a Microsoft kind of way. Talisman and
infighting between the D3D and OGL teams kept things screwed for a solid 18
months. Now Talisman and the OGL projects are dead, and all those people are
working on the next version of the API formerly known as D3D.
ast...@bootnet.com
In article <checkerE...@netcom.com>,
Okay Chris, fair enough. There's certainly nothing I'm going to be able to
say to deter you from repeatedly asserting that I'm a liar without supporting
the claim.
You can scream liar again if you like, but I feel like I should tell you this
anyway. Microsoft had a multimedia review meeting in Febuary 1996, Seamus
Blackely and Tim Sweeney were there. Chaz and Hock got in a discussion over
3D features infront of Bill shortly after the meeting, and Bill said
something very close to this affect; "I'm sorry, this is my fault, I've
clearly failed to communicate my intentions clearly to everyone involved.
The purpose of supporting OpenGL is to get legacy Unix applications ported to
Windows NT. I don't want us investing any effort in enhacing or extending
OpenGL beyond satisfying that objective." That's about when those extensions
were killed if I recall correctly.. Which I may not, and you can call that a
lie to if you prefer. Bill said it directly to Hock, so I suppose you can
ask him for his version.
ast...@bootnet.com
In article <MPG.fc24a49d...@nntp.chromatic.com>,
q...@chromatic.com (Paul Hsieh) wrote:
>
> ast...@bootnet.com said:
> > > As for your assertion that OpenGL "lost": it was pretty clear at the
> > > CGDC this year that OpenGL has more support among developers than ever.
> > > For example, few people were talking about how to achieve high-end
> > > effects with Direct3D. A lot of people were talking about how to do
> > > things in OpenGL.
> >
> > fully realize it, but it's true.
>
>
> > [...] Feed me these words in two years if I'm wrong. :)
>
> Well ... does that mean we get to feed words to you that you mentioned two
> years ago too? (Probably some crap about execute buffers?)
>
> What kind of nonsense was this guy spouting two years ago? Anyone have
> anything on record? (Keep in mind Carmack didn't go on his famous .plan
> rant until Dec 1996, so nobody gave a fuck about who Alex St. John was back
> then.)
>
Here, I'll help you out.
-PC's would capture 50% of the game market, N64 would fail. WRONG
-PC Arcade industry would take off, creating new billion dollar market for PC
games. WRONG
-DirectX would remove driver headaches for developers. MAJOR WRONG.. it was
a nice thought though...
Jason Shankel
ast...@bootnet.com wrote:
> A reasonable argument Jason. I hope you're right in the end, but I've seen
> too much technology come and go to be a believer. I ask myself who's going
> to make enough money off OpenGL to resuscitate it. Having an Open Standards
> body control a technology is actually a sure death sign in my book. It just
> means nobody feels enough ownership of the technology to drive it anywhere
> aggressively... see Unix. Having lots of hardware companies all rolling
> their own drivers for it is another sure sign of death. Nothing can screw up
> a technologies reputation faster than having ATI write a driver for it.
You may be right. On the other hand, some technologies benefit from the
open committee structure. Witness C/C++ vs Visual Basic. For years the
great complaint against C++ was that it was not standardized. No one
with portability/sustainability on their mind is using VB.
A 3d API is NOT going to succeed on Windows without Microsoft's
approval, I agree. But, lack of success on Windows does not constitute
death. The rest of the 3d graphics world is unlikely to adopt
Farenheit, even if it turns out BETTER than OpenGL, because it will not
be designed for their platforms.
As you say, see Unix. Perhaps it is better to predict that OpenGL is as
"dead as Unix", which is not all that dead.
I am not a microphobe by any stretch, but I do believe that this entire
conflict was essentially constructive (and is not yet resolved).
Without a vocal minority constantly touting the benefits of the Mac,
Windows never would have gotten any better. Without the rest of the
"serious" world using Unix for servers, NT probably wouldn't have
happened. Without some of us saying of D3D "that's nice, but it ain't
OpenGL", then it would have been a LOOONG walk from execute buffers to
Farenheit. Microsoft's great strength is that they copy the good ideas
of others and then play a kick-ass game of catch up. It just seems that
from time to time they need a little help determining what is and is not
a good idea.
I only hope that OGL enthusiasts and SGI can keep their message strong
enough to make Farenheit something more than just the political
compromise it is today. Alot depends on how well SGI can leverage their
credibility. Once the argument is over, for good, Microsoft will
inevitably freeze them out. The question is, will they freeze them out
at Farenheit 2.0 or Farenheit 4.0.
Paul Hsieh
> > > step back a bit and look at both OGL & D3D. The DX team takes 1 year
> > > to make the next version, the ARB takes one year to agree on what
> > > issues should be discussed.
> >
> > But in absence of a committee to discuss DX, Microsoft makes mistakes that
> > take time to correct.
> >
> > > That's at least my perception. Not using OpenGL I may be mistaken in
> > > that perception...
>
> mistakes on the scale it was before from now on. They finally pulled
> together a unified team. There's a reasonable probability with the focus
> they have on it now, that it will improve dramatically and consistently for
> the next couple of years... in a Microsoft kind of way.
I cannot comment directly on specifics, but internally we (Chromatic
Research) have seen Microsoft's DX6 and DX7 specs, we look at the state of
our hardware and that of the industry and we say "What the f*ck is Microsoft
doing?" All we want to do is support Microsoft's APIs but their decisions
are incomprehensibly short sighted.
Vague example: DX7 incorporates feature X which is a good thing
theoretically, but there are varied ways of implementing feature X, so a
maximal amount of abstraction is what you would expect so that HW vendors
can implement whatever they like, and the one that does it best will be
rewarded via user and developer feed back etc.
But no, Microsoft picked a specific hardware implementation from a specific
company that had working beta hardware available roughly around the time the
DX7 committee was putting the spec together. The implementation itself has
pluses and negatives, but more importantly it shuts out alternative ideas.
So now this hardware company has an unfair advantage for all the wrong
reasons.
They may have a better team now, but its still being driven as much
politically as it is technologically.
> [...] Talisman and infighting between the D3D and OGL teams kept things
> screwed for a solid 18 months. Now Talisman and the OGL projects are
> dead, and all those people are working on the next version of the API
> formerly known as D3D.
But fundamentally, they are just Microsoft employees building these things,
and they just don't inspire any sort of confidence. As much as I think of
SGI as a completely screwed up company, they still have top notch engineers
and the resiliance of OpenGL throughout all of this is a testimony of that.
Javier Arevalo
q...@chromatic.com (Paul Hsieh) wrote:
>Vague example: DX7 incorporates feature X which is a good thing
>theoretically, but there are varied ways of implementing feature X, so a
>maximal amount of abstraction is what you would expect so that HW vendors
>can implement whatever they like, and the one that does it best will be
>rewarded via user and developer feed back etc.
Game developers frown at the idea of a high level API that they
haven't designed themselves (me too). They ask for "access to the
metal", "direct control over specific hardware features" and all that,
"we will still write our engines so just give me a DrawTriangle()
function somewhere".
Hardware developers frown at the idea of a low-level API they haven't
designed thmeselves (you too). They ask for "interfaces that allow
IHVs to implement their own solutions", "don't control the way we
implement our features" and all that, "we want to have places where to
innovate without losing support".
Is any of the sides wrong? Not. I am not and I don't think you are
either. But our goals are different. Yours is to have wide software
support to sell your specific hardware. Mine is to have wide hardware
support to sell my specific software.
So if you really think that a single solution is going to fit both
goals, I think you are fundamentally misled.
I don't want a Direct3DDevice17::DrawShadowOfObject(Direct3DObject17
*); interface that hardware vendors choose to implement the way they
want (if at all), or that reverts to software emulation at 3fps. When
a hardware feature becomes so established that there are no
differences among HW implementations, and consistent universal
support, and an established way to use it, then let it go into the
API. Until then I don't want it. Texture-mapped triangles are that
right now, and barely anything else. Once you step past that, you get
into the realms of:
- square textures only?
- Z-buffer friendly chroma-key, or z-buffer unfriendly per-texel
alpha?
- Alpha-blending or stippling?
- Iterated or flat per-vertex alpha?
Of course one needs some foresight and patience, but also needs
results. Direct3D was able to gain instant acceptance because it
solved the problems of today (consistent interface to access the
hardware, without hiding the inconsistencies of the hardware itself).
That's a testament to the Direct3D design guidelines along with all
the mistakes they also made.
I as a game developer don't want to be the canonfodder in the battle
between software and hardware developers. Microsoft decided that it
would be in their interest to avoid the consumers be as well, and with
all the technical mistakes included they suceeded in just two years.
And the argument that "it's just because it is Microsoft and they have
big bucks" is not applicable. If it was not a solution, it would not
be successfully used by 95% of game developers, and IHVs wouldn't
think that the Microsoft logo in their box is a more important feature
than any algorithm their engineers develop.
Since nobody has developed games with OpenGL which support the vast
array of consumer 3D cards, the battle has not been actually fought
down in the trenches and no side can claim victory. I for one will
hope for my side to win, and if that means that some IHVs are going to
be screwed then too bad; I'm sure they don't care either if my game
runs in someone else's hardware or not.
Chris Hecker
ast...@bootnet.com writes:
> <stuff about Billg>
Oh boy, things are getting a bit confusing now! You just posted an
anecdote that supports what I was saying about MS starting to kill
OpenGL before I got involved and contradicts what you were saying
about it being my fault. Okay...
I think I'll recap my main points to avoid confusion and then try to
bow out of this thread (wish me luck):
1. Microsoft dislikes OpenGL because they don't control it, and for
_no_ defensible technical reason (including previously posted nonsense
by you and others in Microsoft evangelism, like "designed for games",
"driver models", etc.). You seem to have come around to agree on this
one here at the end of the thread, but the reason I even got into this
thread is you posted some technical falsehoods supposedly justifying
D3D (of which I gave three examples in my first post). Anyway, if you
agree, that's great. Too bad no one at Microsoft will admit it.
2. Microsoft started to kill OpenGL long before I (or anybody else)
got involved. You seem to agree on this one now, too.
3. You lie when it suits you. I'm surprised you even want an example
since you've bragged about it many times before, but if I must, how
about the time you told Gamecenter that OpenGL was designed for
photorealistic offline rendering, not real time graphics. I believe a
mutual acquaintance called you on this and you said (wait for it)
"Hey, it's marketing." Maybe you've changed since you left MS, but
the first post in this thread didn't seem to indicate that.
Anyway, I'm not sure how we got so personal in this thread, since it
started off with me just calling you on technical nonsense. If I got
personal first (I don't even remember at this point :), I apologize.
Chris
Chris Hecker
nos...@jet.es (Javier Arevalo) writes:
>Game developers frown at the idea of a high level API that they
>haven't designed themselves (me too).
>designed thmeselves (you too).
I think you're selling a lot of smart people on both sides of the
fence a bit short. Have you actually talked to IHVs about API
abstractions? I find IHVs are thoughtful and intelligent, and not as
short sighted as you imply. Also, I find most game developers
appreciate the right level of abstraction, and can think about more
than just the game they're working on at the moment.
The reason IHVs like OpenGL is because it is the right level of
abstraction (or a lot closer than the currently available
competition), and this is because it was designed by people with
experience trading off between SW and HW abstractions. D3D,
amazingly, manages both too much low level specification (fixed vertex
formats, app-lockable frame buffer and texture memory, etc...just ask
a HW guy for zillions of examples) and too high level of a
specification (no rules or invariants for anything, no features
specified, etc.).
>the ARB takes one year to agree on what issues should be discussed.
This is not true. Have you been involved in the extensions process
for things like multitexture, particles, and the like? Because OpenGL
is open, you can be involved if you want. Extensions mean we can try
things out before they go into the specification proper, which saves
headaches later and makes sure we get experience implementing and
using features before they're forced on people. Contrast that with
"the other API."
>a hardware feature becomes so established that there are no
>differences among HW implementations, and consistent universal
>support, and an established way to use it, then let it go into the
>API. Until then I don't want it.
Golly, sounds like you just described the OpenGL extensions mechanism... :)
>And the argument that "it's just because it is Microsoft and they have
>big bucks" is not applicable. If it was not a solution, it would not
>be successfully used by 95% of game developers, and IHVs wouldn't
Hmm, as a game developer, I'd think you'd want something better than
"a solution." I'd rather have "the best solution." From the number
of IHVs doing OpenGL drivers, it looks like we might get that choice
if we're lucky.
Chris
Juan Carlos 'JCAB' Arevalo Baeza
On Thu, 14 May 1998 08:48:25 GMT, che...@netcom.com (Chris Hecker)
dignified this group by writing:
>I think you're selling a lot of smart people on both sides of the
>fence a bit short. Have you actually talked to IHVs about API
>abstractions? I find IHVs are thoughtful and intelligent, and not as
>short sighted as you imply. Also, I find most game developers
Yes. But they need to innovate in order to differentiate from their
competitors. And having a fixed set of supported features prevents
them from using a big field of differentiation. Thus the struggle.
>appreciate the right level of abstraction, and can think about more
>than just the game they're working on at the moment.
That is actually true. Jare and I count ourselves among the more
'do-it-yourselvers' of the developers. That's why I've developed my
own API, on top of D3D, OGL or whatever I wish. Not all are like that.
But there are quite a few.
>The reason IHVs like OpenGL is because it is the right level of
>abstraction (or a lot closer than the currently available
And the reason why us developers don't like it is because it's way
too much abstraction without much chance to choose.
>competition), and this is because it was designed by people with
>experience trading off between SW and HW abstractions. D3D,
>amazingly, manages both too much low level specification (fixed vertex
>formats, app-lockable frame buffer and texture memory, etc...just ask
>a HW guy for zillions of examples) and too high level of a
>specification (no rules or invariants for anything, no features
>specified, etc.).
Personally, I enjoy the fact that with D3D you can use it as a pure
triangle rendering machine, or you can go ahead and use all the scene
abstraction of RM. You can approximate this somewhat with OGL, but not
quite.
IHV's must understand that different developers like different
levels of abstraction.
I do agree with the problems of D3D, though. It's not a fully
specified API, and that's what's killing it. OTOH, what's killing OGL
is that it's so statically specified that anything not supported by
the HW must be seamlessly emulated in SW.
Personally, I prefer the D3D nightmare to the OGL one, although I
understand why some wouldn't.
>is open, you can be involved if you want. Extensions mean we can try
>things out before they go into the specification proper, which saves
Yes, that's an advantage.
>Golly, sounds like you just described the OpenGL extensions mechanism... :)
Yes. The problem I see with them is that while they are extensions,
they are not widely supported. And when one day some become full
features, then you can't test for their HW support anymore. Direct3D
has a very bad model for communicating HW support to the applications.
But at least it has one.
>Hmm, as a game developer, I'd think you'd want something better than
>"a solution." I'd rather have "the best solution." From the number
>of IHVs doing OpenGL drivers, it looks like we might get that choice
>if we're lucky.
I think this is the other real problem OpenGL. IF we get lucky. We
haven't so far...
I sure prefer to have a solution than no solution at all.
I need 3 changes on OGL to make it something usable:
1- Have Win95 drivers for all or most major HW (yes, that's IHV's
work.)
2- Make a new feature (an extension for now, if you want, let's call
it the HW_CHECK extension), that will allow apps to check if a certain
triangle will be rendered in HW or SW. No caps bits, no crap. Just set
the triangle up, and, instead of rendering it, return a boolean. If
the API is well designed inside, it should be trivial to implement.
3- Provide a means of accesing the frame buffer. I know IHV's hate
this. But sometimes it's so painful not to have it... If you want,
make it like the rest of OpenGL: if the HW can't support it (for
example, if the frame buffer is compressed a-la Talisman), then have
it emulated in SW (make off-screen buffer at Lock, and blit it to the
fra<me buffer at Unlock). Of course, it should support the HW_CHECK
extension also.
I'd like to see if, being the OpenGL so open, it'd have a chance of
supporting any of those requests.
Your one and only...
JCAB (NOT Jacob)
Juan Carlos 'JCAB' Arevalo Baeza
On Wed, 13 May 1998 14:17:51 -0700, q...@chromatic.com (Paul Hsieh)
dignified this group by writing:
>Vague example: DX7 incorporates feature X which is a good thing
>theoretically, but there are varied ways of implementing feature X, so a
>
>But no, Microsoft picked a specific hardware implementation from a specific
>company that had working beta hardware available roughly around the time the
I don't know about 'feature X'. I assume you mean something like
the S3 texture compression of DX6?
What I don't understand is the need of sticking to one single
specification. It'd have been so easy for them to support it for ANY
compression algorythm...
Aside from that, and knowing that I'm one of the biggest fans of
your Mpact 2, I'd like to ask directly what you think about the
extensions to OpenGL I've proposed in my previous posting here. I
mean, the HW_CHECK extension and the frame buffer access. As a IHV, do
you think it's doable? Would it be easy or complicated? Would it
disrupt the OpenGL support in any way?
R. Jason Sams
>They are obviously not, since they aren't devoting so many resources
>to their OpenGL drivers despite their "desire" to do so.
Every major IHV is developing or has released OpenGL drivers for their
cards. As the hardware becomes better the arguement to use Direct3D has
less merit. It was designed as an API to work with crippled hardware. As
such it caries a large amount of baggage. Examples here are the lack of
multi-texture, I know its in the works but OpenGL had it for a while now.
DirectX lacks the ability to fully use geomitry acceleration. Projected
Textures, Accumulation buffering, and Stencil Buffering. Stenciling will
quickly become more important as multiple IHVs will release cards providing
this ability. There is no way to utilize it in Direct3D. I guess DirectX
games will not have proper shadows, only professional games will.
>Oh I appreciate it as much as the next guy. But I need to ship in a
>year with the smallest amount of tech support troubles, for all 3D
>cards and with the best speed at each one.
OpenGL standard is forcing the IHV to implement a common set of basic
abilities. If you want to use card specific features then check for
extensions.
>I haven't tried OpenGL aside from the experiments here and there. I
>have formed an opinion on it based not on desire or technical merit,
>but on practicality.
That is the problem with this entire arguement. Many of the people arguing
one side or another have limited or no knowledge of the APIs in question. If
you do not have a in depth undestanding of BOTH APIs then you are not
qualified to compare them on a technical basis.
>I think about the future too. If the future can be either an enhanced
>DirectX or the OpenGL solution I must choose the first one. I trust
>Microsoft's ability to fuck up everything the first 3 times and then
>get it right with the 4th.
And sometimes they still don't get it right. Windows 95/98 still routinly
crashes.
>And if I want an extension mechanism (which I'm not terribly
>interested in, I mean, it would be cool but it's not my priority),
>I'll let Microsoft know I want it.
You must have much better luck than I. Asking for a stable OS goes nowhere.
Asking for OpenGL support goes nowhere. Asking them to provide NT support
to DirectX still is not done.
>>Hmm, as a game developer, I'd think you'd want something better than
>>"a solution." I'd rather have "the best solution." From the number
>>of IHVs doing OpenGL drivers, it looks like we might get that choice
>>if we're lucky.
>
>Read what you just wrote. Then go to a business college and ask them
>if they think that is a solid grounds for making a decision.
By that standard I am sure we will get lucky. It's my job to see that it
happens. Writing OpenGL drivers is not a trivial task. Based on the amount
of time it takes to develop a good OpenGL driver from scratch, and the start
date based on when Microsoft finished screwing the IHVs by pulling the
driver model for Windows 95 we should see finished drivers in the next 2-4
months.
The most compelling argument to get OpenGL support is to write a killer game
that uses it. If you can produce a game good enough, I can guarantee that
the IHVs will provide whatever driver you need. To them they need to sell
hardware and they can only do that if they run the cool games.
We are the game developers, its up to us to win or lose this battle.
R. Jason Sams
Matt Craighead
Juan Carlos 'JCAB' Arevalo Baeza wrote:
> 2- Make a new feature (an extension for now, if you want, let's call
> it the HW_CHECK extension), that will allow apps to check if a certain
> triangle will be rendered in HW or SW. No caps bits, no crap. Just set
> the triangle up, and, instead of rendering it, return a boolean. If
> the API is well designed inside, it should be trivial to implement.
I would prefer caps bits myself. The "probe" method of checking caps
can get REALLY icky. You might have, say, 5-10 crucial engine states
for various rendering types (light/no light, texture/no texture with
all the different variations on how texturing is done, blending for
certain FX, and so on). Now, OpenGL has a LOT of render states. D3D
has less but still >50. Let's say you get a GL_FALSE return code (SW).
What now? What do you start disabling? How can you find out what is
valid without an O(2^n) search for boolean states (glEnable, glDisable)
and more for other states (glBlendMode)?
Something like that will ENCOURAGE HW with exclusive caps, too -- the
trilinear vs. multitexture, alpha vs. fog, and such.
I would prefer a simple caps bit check. Enable the supported features,
disable the unsupported features. If a crucial state is unsupported,
skip it. And allow driver writers three return codes: GL_UNSUPPORTED,
GL_EMULATED, GL_ACCELERATED. Make it so they don't HAVE to support
everything! A rasterization-only OpenGL that actually had drivers
would be better than today's full OpenGL with questionable driver
availability.
As for locking the framebuffer, sure, HW guys don't like it, but it's
essential if you're putting 2D on top of 3D! As long as you don't
mix framebuffer locks and 3D rendering, you're fine.
--
Matt Craighead
Engineer, Window Painters, Ltd.
http://www.windowpainters.com
Javier Arevalo
jc...@roningames.com (Juan Carlos 'JCAB' Arevalo Baeza) wrote:
> What I don't understand is the need of sticking to one single
>specification. It'd have been so easy for them to support it for ANY
>compression algorythm...
Maybe they want to have a solid foundation on texture compression
before letting the API handle wildly different cases.
You know about the PowerVR and what it means for the HW to do
something in a totally different and odd way.
Javier Arevalo
jc...@roningames.com (Juan Carlos 'JCAB' Arevalo Baeza) wrote:
>3- Provide a means of accesing the frame buffer. I know IHV's hate
>this. But sometimes it's so painful not to have it...
My game has been able to survive the texture memory limits without any
visual quality loss thanks to that. Whoopi! and I hope it doesn't
break 2 years from now. :)
Javier Arevalo
che...@netcom.com (Chris Hecker) wrote:
>I find IHVs are thoughtful and intelligent, and not as
>short sighted as you imply.
They are obviously not, since they aren't devoting so many resources
to their OpenGL drivers despite their "desire" to do so.
>Also, I find most game developers
>appreciate the right level of abstraction, and can think about more
>than just the game they're working on at the moment.
Oh I appreciate it as much as the next guy. But I need to ship in a
year with the smallest amount of tech support troubles, for all 3D
cards and with the best speed at each one.
I haven't tried OpenGL aside from the experiments here and there. I
have formed an opinion on it based not on desire or technical merit,
but on practicality.
I think about the future too. If the future can be either an enhanced
DirectX or the OpenGL solution I must choose the first one. I trust
Microsoft's ability to fuck up everything the first 3 times and then
get it right with the 4th.
We'll see who gets burned, but your argument that I just want cheap
food today doesn't hold just because I take the position of defending
the "unpopular" solution.
You see, my curent game even still uses execute buffers and I'm not
ashamed. ;-)
>Golly, sounds like you just described the OpenGL extensions mechanism... :)
And if I want an extension mechanism (which I'm not terribly
interested in, I mean, it would be cool but it's not my priority),
I'll let Microsoft know I want it.
>Hmm, as a game developer, I'd think you'd want something better than
>"a solution." I'd rather have "the best solution." From the number
>of IHVs doing OpenGL drivers, it looks like we might get that choice
>if we're lucky.
Read what you just wrote. Then go to a business college and ask them
if they think that is a solid grounds for making a decision.
"If we get lucky", come on. We've been being almost lucky for two
years now.
I prefer a viable "worst solution" than a better one that will happen
if "we're lucky".
Sean T Barrett
Matt Craighead <crai...@citilink.com> wrote:
>As for locking the framebuffer, sure, HW guys don't like it, but it's
>essential if you're putting 2D on top of 3D! As long as you don't
>mix framebuffer locks and 3D rendering, you're fine.
Huh? What's the gain? Sure, writing to the framebuffer
is more convenient, and convenience is usually good, but
"essential"?
Break your 2d art into mostly-opaque rectangles, download
as textures, render with bilerping off.
It's the same amount of data going down the bus (assuming
that the frame buffer writes would get combined and bursted
as efficiently as texture downloads), you suck up some fill
rate but if you wrote to the frame buffer in 2d you wouldn't
be using the fill rate during that time period, etc. etc. etc.
It just seems pointless for them to support that path just
to avoid drawing the non-opaque pixels. (Besides, alpha'd
edges look nicer anyway.) It makes sense that the
consumer-oriented cards have been doing it to make it
easier to port old code, but it hardly seems "essential".
Sean
Chris Hecker
jc...@roningames.com (Juan Carlos 'JCAB' Arevalo Baeza) writes:
>2- Make a new feature (an extension for now, if you want, let's call
>it the HW_CHECK extension), that will allow apps to check if a certain
>triangle will be rendered in HW or SW. No caps bits, no crap. Just set
This kind of thing has been gone over before in detail, but the key is
you're asking the wrong question. You don't care if a feature is "in
HW" or not. You care if a feature meets some minimum [app-specific]
performance requirement. The only robust way to figure this out is to
time it.
Chris
Chris Hecker
nos...@jet.es (Javier Arevalo) writes:
>>Hmm, as a game developer, I'd think you'd want something better than
>>"a solution." I'd rather have "the best solution." From the number
>>of IHVs doing OpenGL drivers, it looks like we might get that choice
>>if we're lucky.
>Read what you just wrote. Then go to a business college and ask them
>if they think that is a solid grounds for making a decision.
>"If we get lucky", come on. We've been being almost lucky for two
>years now.
>I prefer a viable "worst solution" than a better one that will happen
>if "we're lucky".
I knew as soon as I posted it that using the term "lucky" was a
mistake in the unforgiving world of r.g.p. How about this: "we might
get that choice if we, as game developers, work hard enough to make it
happen." That's more along the lines of what I meant. This is just
what I've been saying all along, and it's bigger than whether OpenGL
becomes successful or dies.
We game developers have the real power in this industry, but we get
dicked around because it's a lot of work to organize. You can argue
about whether OpenGL or D3D is better designed (although I think the
vast majority of technical people would side with OpenGL), but you
can't reasonably argue that the API design ever had anything to do
with which one Microsoft decided to force on the industry. That, in
my opinion, is bad for our industry, and we have only ourselves to
blame for not standing up to it.
I'm not denying it's easier to just give up and support D3D; of course
it is. However, I think it's worth it to take a little risk and try
to make OpenGL successful because I feel strongly that it's better for
the game industry. If we fail, at least we can say we made an effort
to do the right thing.
Chris
Michael K
Chris Hecker wrote:
> nos...@jet.es (Javier Arevalo) writes:
[snip]
> >Read what you just wrote. Then go to a business college and ask them
> >if they think that is a solid grounds for making a decision.
> >"If we get lucky", come on. We've been being almost lucky for two
> >years now.
> >I prefer a viable "worst solution" than a better one that will happen
> >if "we're lucky".
>
> I knew as soon as I posted it that using the term "lucky" was a
> mistake in the unforgiving world of r.g.p.
Unforgiving and highly flamable :). We need to resolve to be less
criticle(SP?) of others.
Michael
Phil Oliver
R. Jason Sams wrote in message <6jgojk$h8g$1...@news7.ispnews.com>...
>By that standard I am sure we will get lucky. It's my job to see that it
>happens. Writing OpenGL drivers is not a trivial task. Based on the amount
Why would anybody want to write an OpenGL driver from scratch
given the number of drivers that have been written so far incl. Mesa?
Sounds like extreme masochism to me.
Glenn Corpes
Chris Hecker wrote:
> ast...@bootnet.com writes:
> > <stuff about Billg>
>
> Oh boy, things are getting a bit confusing now! You just posted an
> anecdote that supports what I was saying about MS starting to kill
> OpenGL before I got involved and contradicts what you were saying
> about it being my fault. Okay...
>
> I think I'll recap my main points to avoid confusion and then try to
> bow out of this thread (wish me luck):
>
> 1. Microsoft dislikes OpenGL because they don't control it, and for
> _no_ defensible technical reason (including previously posted nonsense
> by you and others in Microsoft evangelism, like "designed for games",
> "driver models", etc.).
Surely the fact that there is a stable D3D driver for every 3D chip while
non-miniGL drivers are thin on the ground to say the least says something
about the driver models?
-=< gco...@ea.com Project leader, Bullfrog >=-
Glenn Corpes
Sean T Barrett wrote:
> Matt Craighead <crai...@citilink.com> wrote:
> >As for locking the framebuffer, sure, HW guys don't like it, but it's
> >essential if you're putting 2D on top of 3D! As long as you don't
> >mix framebuffer locks and 3D rendering, you're fine.
>
> Huh? What's the gain? Sure, writing to the framebuffer
> is more convenient, and convenience is usually good, but
> "essential"?
>
> Break your 2d art into mostly-opaque rectangles, download
> as textures, render with bilerping off.
Correct, avoid writing to the screen with the processor at all costs.
One of D3D's strengths is that it allows access to hardware with non
readable surfaces, for example the PowerVR's z-buffer, it will also work
with future hardware with non readable screen RAM, AIUI openGL supposedly
has to provide read access to this stuff, which is strange when you
consider that QuakeII runs fine on PowerVR, this is because their driver
is of course a subset (aren't they all?), in fact QuakeGL drivers tend to
simultaneously be subsets and supersets (extensions) of openGL which IMO,
illustrates the point that while an openGL variant may have been a better
API than D3D, standard, ARB controlled openGL itself wasn't.
Russ Williams
>>resources to their OpenGL drivers despite their "desire"
>>to do so.
>
>drivers for their cards.
"Is developing" is worthless. They've been in perpetual
beta for many months.
MCD drivers are also useless - you only need to look at
the MCD vs beta ICD scores for Quake to see that.
They are simply too slow.
>As the hardware becomes better the arguement to use
>Direct3D has less merit.
*One* of the arguments.
>It was designed as an API to work with crippled hardware.
Which is still what is being shipped.
Is that going to change in the next year? Doubtful.
Sure, the hardware will improve, but I'll bet that in a year's
time we still don't have consumer hardware supporting
all of the required OpenGL render-states in hardware.
>As such it caries a large amount of baggage.
Hehe. In comparison to an API that requires software
emulation of unsupported features, *D3D* has a lot
of baggage?
>Examples here are the lack of multi-texture,
In DX6, I believe. That's coming in July.
>I know its in the works but OpenGL had it for a while now.
OK. Fair point. The Voodoo 2 supports multi-texture.
Can I get a (non-beta) Voodoo 2 OpenGL driver that
supports its multitexturing?
>DirectX lacks the ability to fully use geomitry acceleration.
True. Do any consumer cards other than Diamond's FireGL
1000 Pro support that?
>Projected Textures, Accumulation buffering,
Dunno what these are.
>and Stencil Buffering. Stenciling will quickly become more
>important as multiple IHVs will release cards providing
>this ability.
Yup. It'll be nice to see Mark Kilgard's samples running on
commodity hardware.
>There is no way to utilize it in Direct3D.
Yet.
(Although I'd expect it might be doable using alpha or
z-buffer tricks. Don't know for certain, though.).
>I guess DirectX games will not have proper shadows,
I guess not. Still, who'd want to do shadows with an
emulated stencil-buffer?
>only professional games will.
It was this comment that made me choose to reply to this
message.
Maybe you should look up the term. See how many
games are being released using OpenGL and
stencil-buffer shadows? Zero. How many with OpenGL?
Mostly just the Quake licensees. It seems that the
professionals are using D3D.
I don't doubt that this situation would change (literally)
overnight if OpenGL suddenly became viable.
>>Oh I appreciate it as much as the next guy. But I need
>>to ship in a year with the smallest amount of tech
>>support troubles, for all 3D cards and with the best
>>speed at each one.
>
>OpenGL standard is forcing the IHV to implement a
>common set of basic abilities.
Yes. Mostly in software, since they can't fit an Onyx on
a $30 chip. Is it a good idea forcing IHVs to
write/beg/borrow/steal software OpenGL renderers?
>If you want to use card specific features then check for
>extensions.
A good point, but what about determining which standard
features are in hardware, and which aren't?
Sure, you could time some rendering, but that would require
an exponential number of tests.
>>I haven't tried OpenGL aside from the experiments here
>>and there. I have formed an opinion on it based not on
>>desire or technical merit, but on practicality.
>
>That is the problem with this entire arguement. Many of
>the people arguing one side or another have limited or
>no knowledge of the APIs in question. If you do not have
>a in depth undestanding of BOTH APIs then you are not
>qualified to compare them on a technical basis.
See the bit you quoted above... Not on a technical basis,
but on practicality.
>>I think about the future too. If the future can be either an
>>enhanced DirectX or the OpenGL solution I must choose
>>the first one. I trust Microsoft's ability to fuck up everything
>>the first 3 times and then get it right with the 4th.
>
>And sometimes they still don't get it right. Windows 95/98
>still routinly crashes.
Really? Try different drivers and/or working hardware.
>>And if I want an extension mechanism (which I'm not
>>terribly interested in, I mean, it would be cool but it's
>>not my priority), I'll let Microsoft know I want it.
>
>You must have much better luck than I. Asking for a
>stable OS goes nowhere.
Why? Win95/98 *is* stable. Sure, it can be crashed by
anything trashing memory, but that's a necessity for
DOS game support. If you want a _more_ stable OS,
buy NT.
>Asking for OpenGL support goes nowhere.
Really? OpenGL was supported the last time I looked.
You have ICDs on both Win95 and NT. MCDs on NT.
>Asking them to provide NT support to DirectX still is
>not done.
Depends what you ask for. NT4 has supported DDraw
since it's release. NT4SP3 supports all of DX3 except
HW 3d, AIUI (is that a MS limitation or a lack of NT
drivers?)
>>>Hmm, as a game developer, I'd think you'd want
>>>something better than "a solution." I'd rather have
>>>"the best solution." From the number of IHVs doing
>>>OpenGL drivers, it looks like we might get that
>>>choice if we're lucky.
>>
>>Read what you just wrote. Then go to a business
>>college and ask them if they think that is a solid
>>grounds for making a decision.
>
>By that standard I am sure we will get lucky. It's my job
>to see that it happens. Writing OpenGL drivers is not
>a trivial task.
Of course. So why is that a better option than using a
more limited API that's a close match for the limited
hardware?
>Based on the amount of time it takes to develop a good
>OpenGL driver from scratch, and the start date based
>on when Microsoft finished screwing the IHVs by pulling
>the driver model for Windows 95 we should see finished
>drivers in the next 2-4 months.
Blah blah blah. We've been hearing that for the last 18
months. Real Soon Now, huh?
>The most compelling argument to get OpenGL support is
>to write a killer game that uses it.
Like Quake/Quake 2/Hexen 2? They all sold well, but I
still don't see drivers.
>If you can produce a game good enough, I can guarantee
>that the IHVs will provide whatever driver you need.
Ah yes. QuakeGL.
Just imagine the benefits: hundreds of subtly different
'OpenGL' drivers for every combination of card and
game.
>To them they need to sell hardware and they can only do
>that if they run the cool games.
Yup. Which is why people use D3D - it provides support
for *all* IHVs hardware.
>We are the game developers, its up to us to win or lose
>this battle.
And our part in this battle would be, what? Sitting around,
waiting/hoping/praying/asking IHVs for OpenGL drivers?
We *still* haven't got *first generation* OpenGL drivers,
yet, and the initial releases are always flaky. How long
before they are actually usable? Are you willing to risk
everything on drivers hopefully being available by the
time you ship? It's a big task to push onto an IHV, so what
makes you think they'd:
i) Take any notice
ii) Make a good job of it
iii) Do either of the above before you need to ship
---
Russ
PS - I still don't get why people think it's an either-or
decision. Changing from one 3d API to another isn't
exactly difficult. People have 3d cards with D3D
support, so why not do both? Support your preferred
API and your customers.
R. Jason Sams
>"Is developing" is worthless. They've been in perpetual
>beta for many months.
True, however they are nearing completion. At least from three of the
companies.
>MCD drivers are also useless - you only need to look at
>the MCD vs beta ICD scores for Quake to see that.
>They are simply too slow.
MCDs are slower. However if you want ANY acceleration on NT OpenGL is your
only choice. They were designed to make the life of the driver writer
easier, not make performance better. ICD should always win on performance.
>>It was designed as an API to work with crippled hardware.
>
>Which is still what is being shipped.
>Is that going to change in the next year? Doubtful.
>Sure, the hardware will improve, but I'll bet that in a year's
>time we still don't have consumer hardware supporting
>all of the required OpenGL render-states in hardware.
Also true. However, the nVidia TNT, Matrox G200, s3 Savage, and others will
support most of the OpenGL rendering states. You still have to be aware of
the costs of diffrent rendering modes.
>>As such it caries a large amount of baggage.
>
>Hehe. In comparison to an API that requires software
>emulation of unsupported features, *D3D* has a lot
>of baggage?
By baggage I mean that once the hardware becomes more powerful, why not use
a proven and robust api that works well with high end hardware. DirectX is
continually playing catch up to the hardware.
>>Examples here are the lack of multi-texture,
>
>In DX6, I believe. That's coming in July.
True, but I would rather not have to wait for Microsoft to add features that
are already available to me using other means.
>>DirectX lacks the ability to fully use geomitry acceleration.
>
>True. Do any consumer cards other than Diamond's FireGL
>1000 Pro support that?
Rendition will be shipping one soon acording to rumors on the web.
>>Projected Textures, Accumulation buffering,
>
>Dunno what these are.
>
>>and Stencil Buffering. Stenciling will quickly become more
>>important as multiple IHVs will release cards providing
>>this ability.
>
>Yup. It'll be nice to see Mark Kilgard's samples running on
>commodity hardware.
>
nVidia and 3Dlabs have already announced (TNT) or shipped (Premedia2) chips
with this support.
>>There is no way to utilize it in Direct3D.
>
>Yet.
>
>(Although I'd expect it might be doable using alpha or
>z-buffer tricks. Don't know for certain, though.).
There are other ways to do it with varying performance hits. If someone can
prove me wrong on this one, let me know how.
>>I guess DirectX games will not have proper shadows,
>
>I guess not. Still, who'd want to do shadows with an
>emulated stencil-buffer?
See above list of hardware with this ability either now of by end of year.
>>only professional games will.
>
>It was this comment that made me choose to reply to this
>message.
>
>Maybe you should look up the term. See how many
>games are being released using OpenGL and
>stencil-buffer shadows? Zero. How many with OpenGL?
>Mostly just the Quake licensees. It seems that the
>professionals are using D3D.
If the consumer hardware is expected to be available in the next 6 months,
(common in 12
?) It would make sense to spend a little money and get a professional board
to develop you game, after 12 months of development you find that the cards
are now shipping with your required stencil buffer and you market your game.
Now with a Microsoft API, you first beg them for a Stencil buffer. If they
decide to add one you wait 12+ months for a beta API which you can use to
develop your game. Once you have it you begin development. After 12 months,
plus 1 for using a beta API you have a game ready to ship, but you are 13
months late to the market because you spent 25 months from start to finish.
>>OpenGL standard is forcing the IHV to implement a
>>common set of basic abilities.
>
>Yes. Mostly in software, since they can't fit an Onyx on
>a $30 chip. Is it a good idea forcing IHVs to
>write/beg/borrow/steal software OpenGL renderers?
No, I would like to see a standart software fallback engine for OpenGL.
Having each vendor write their own is a little bit of a mess.
>>If you want to use card specific features then check for
>>extensions.
>
>A good point, but what about determining which standard
>features are in hardware, and which aren't?
>
>Sure, you could time some rendering, but that would require
>an exponential number of tests.
This problem is no better (some would say worse) in DirectX. Just checking
the cap bits will not tell you if the feature is usable (fast enought) for
your game. Try trilineal filtering or blending on some cards.
>>And sometimes they still don't get it right. Windows 95/98
>>still routinly crashes.
>
>Really? Try different drivers and/or working hardware.
Have, I am being punished for having a high end caching SCSI card.
>>>And if I want an extension mechanism (which I'm not
>>>terribly interested in, I mean, it would be cool but it's
>>>not my priority), I'll let Microsoft know I want it.
>>
>>You must have much better luck than I. Asking for a
>>stable OS goes nowhere.
>
>Why? Win95/98 *is* stable. Sure, it can be crashed by
>anything trashing memory, but that's a necessity for
>DOS game support. If you want a _more_ stable OS,
>buy NT.
I do use NT, but then I cann't use DirectX. (With hardware)
>>Asking for OpenGL support goes nowhere.
>
>Really? OpenGL was supported the last time I looked.
>You have ICDs on both Win95 and NT. MCDs on NT.
The only one assisted by Microsoft was the NT MCD. This is the point of
contention. You argue that we do not have stable drivers, the you give Ms
credit for them when they have done nothing to make it happen. The even
tried to stop it by pulling their driver framework for 95.
>>Asking them to provide NT support to DirectX still is
>>not done.
>
>Depends what you ask for. NT4 has supported DDraw
>since it's release. NT4SP3 supports all of DX3 except
>HW 3d, AIUI (is that a MS limitation or a lack of NT
>drivers?)
This is an MS limitation. The hadrware driver model is not yet in place in
NT.
>>The most compelling argument to get OpenGL support is
>>to write a killer game that uses it.
>
>Like Quake/Quake 2/Hexen 2? They all sold well, but I
>still don't see drivers.
No, but all of the drivers started development around that time.
>>If you can produce a game good enough, I can guarantee
>>that the IHVs will provide whatever driver you need.
>
>Ah yes. QuakeGL.
>Just imagine the benefits: hundreds of subtly different
>'OpenGL' drivers for every combination of card and
>game.
That was not my point. Even if you use a completly diffrent API, if the
game is good enough you will get drivers for it.
>>To them they need to sell hardware and they can only do
>>that if they run the cool games.
>
>Yup. Which is why people use D3D - it provides support
>for *all* IHVs hardware.
Yes, but it is a little diffrent on each. From abilites supported to
rasterization quality. And there are no standards in place to fix that.
>>We are the game developers, its up to us to win or lose
>>this battle.
>
>And our part in this battle would be, what? Sitting around,
>waiting/hoping/praying/asking IHVs for OpenGL drivers?
>We *still* haven't got *first generation* OpenGL drivers,
>yet, and the initial releases are always flaky. How long
>before they are actually usable? Are you willing to risk
>everything on drivers hopefully being available by the
>time you ship? It's a big task to push onto an IHV, so what
>makes you think they'd:
> i) Take any notice
> ii) Make a good job of it
> iii) Do either of the above before you need to ship
You should talk to the IHVs. Many have told me that their is no longer any
reason to use DirectX unless you want to. Everyone serious about games has
a card from 3Dfx, nVidia, Rendition, or 3Dlabs. All of them have drivers in
beta or better. The one from nVidia and Rendition are looking very good at
this point. You can add the i740 and G200 to the above list. You had
better beleive that Real3D will ship good GL drivers and we will see what
Matrox does.
>PS - I still don't get why people think it's an either-or
>decision. Changing from one 3d API to another isn't
>exactly difficult. People have 3d cards with D3D
>support, so why not do both? Support your preferred
>API and your customers.
Because I have developed games with both. It takes me about three to four
times the effort and time to get something working on DirectX as it does
with OpenGL. That time is better spent working on a better product rather
than dealing with another broken MS api.
R. Jason Sams
Rob Rodgers
che...@netcom.com (Chris Hecker) wrote:
>This kind of thing has been gone over before in detail, but the key is
>you're asking the wrong question. You don't care if a feature is "in
>HW" or not.
Actually, I do care if my current render state is on a hardware path,
yes, indeed I do.
>You care if a feature meets some minimum [app-specific]
>performance requirement. The only robust way to figure this out is to
>time it.
This is secondary. By checking the hardware caps you can do a quick,
non-distracting first-pass cull of features that are _likely_ to cause
a slowdown. You can then build up from there.
The alternative is to test.. Let's see, how many possible combinations
are there for OpenGL? Two to the, what, tenth? fifteenth?
Plus, lets not kid outselves about this being unrealistic or invalid
-- the days of SW being faster than HW were an anomaly of S3's greed.
Rob Rodgers
"R. Jason Sams" <r...@ablecom.net> wrote:
>such it caries a large amount of baggage. Examples here are the lack of
>multi-texture, I know its in the works but OpenGL had it for a while now.
Uh, no. Multitexture is a part of Dx6. It's not a part of OpenGL
1.1, and is an extension (not required) in OpenGL 1.2.
Baggage is the incredibly slow performance of glCopyPixels or the
requirement that the hardware be fully immediate and include a
persistent zbuffer.
>DirectX lacks the ability to fully use geomitry acceleration. Projected
>Textures,
Do you even know what "projected textures" refers to or did you see
the picture in the red book and think it's special?
> Accumulation buffering, and Stencil Buffering. Stenciling will
>quickly become more important as multiple IHVs will release cards providing
>this ability. There is no way to utilize it in Direct3D.
Both are in dx6.
>That is the problem with this entire arguement. Many of the people arguing
>one side or another have limited or no knowledge of the APIs in question.
Oh my.
Matt Craighead
R. Jason Sams wrote:
> You should talk to the IHVs. Many have told me that their is no longer any
> reason to use DirectX unless you want to. Everyone serious about games has
> a card from 3Dfx, nVidia, Rendition, or 3Dlabs. All of them have drivers in
> beta or better. The one from nVidia and Rendition are looking very good at
> this point. You can add the i740 and G200 to the above list. You had
> better beleive that Real3D will ship good GL drivers and we will see what
> Matrox does.
No, the Rendition one is pretty broken. I'll attest to that.
> Because I have developed games with both. It takes me about three to four
> times the effort and time to get something working on DirectX as it does
> with OpenGL. That time is better spent working on a better product rather
> than dealing with another broken MS api.
Odd, D3D is pretty easy to me. And DX6 is supposed to be a LOT better.
For one thing, it supports your precious stencil buffers. Oh, and also
multitexture. I'm set to receive my beta soon...
Juan Carlos 'JCAB' Arevalo Baeza
On Fri, 15 May 1998 07:31:10 GMT, che...@netcom.com (Chris Hecker)
dignified this group by writing:
>you're asking the wrong question. You don't care if a feature is "in
>HW" or not. You care if a feature meets some minimum [app-specific]
>performance requirement. The only robust way to figure this out is to
>time it.
Yes. But sometimes that's not practical. Timing is an inherently
imprecise process, more so in a MT environment like Windows95/NT,
which doesn't have realtime capabilities. In order to make it precise,
it's required to repeat the tests over and over, forcing the user to
wait. That might be acceptable in some applications, but not in
others. I don't like it, and I don't do it.
There's another solution, which is not nice either, but also works,
which is what I used on Armor Command: let the user select which card
settings will be used. The game has been tested with most cards, and
knows how to handle each individual piece of HW. Knows what 'not to
trust' of each card's D3D caps. This was necessary on D3D, because of
the non-safe nature of the caps bits. On OpenGL, it would've been
because of performance. I the end, it just makes them both API's
equally nasty to deal with.
The nicest thing would've been of both API's to answer to requests
about the availability or performance of specific rendering states. No
games that I know of use all possible rendering states of the API they
use. Not even Glide-based games. With an extension like that, it would
be very easy for the developer to check which state combinations they
use aren't supported, so that they can either use less demanding
states, or gracefully refuse to run.
And most important: it'd be such trivial work for ISV's to support
it... And if I'm wrong in this, please, prove me so.
Juan Carlos 'JCAB' Arevalo Baeza
On Fri, 15 May 1998 01:37:31 GMT, Matt Craighead
<crai...@citilink.com> dignified this group by writing:
>certain FX, and so on). Now, OpenGL has a LOT of render states. D3D
>has less but still >50. Let's say you get a GL_FALSE return code (SW).
>What now? What do you start disabling? How can you find out what is
That's totally up to you. Personally, I'd have about 10-15
different render state combinations. Including
plaintextured-nonlit-nonfogged-nontransparent. If a certain mode is
not HW-supported, I'd use a less demanding one. It's extremely easy.
And it's reliable.
>valid without an O(2^n) search for boolean states (glEnable, glDisable)
>and more for other states (glBlendMode)?
Do you use all permutations? Evidently not. Then test only the
permutations that can appear in your app. Believe me. More than 15 is
unnecessarily excesive.
>Something like that will ENCOURAGE HW with exclusive caps, too -- the
>trilinear vs. multitexture, alpha vs. fog, and such.
Well... IHV's didn't seem to need much encouragement, did they? And
exclusive caps DO exist, and there are good reasons for them to exist,
and the HW check would take care of them. The caps bits don't, unless
you want to have as many bits as permutations of states.
>I would prefer a simple caps bit check. Enable the supported features,
>disable the unsupported features. If a crucial state is unsupported,
Yes, but... That gets ambiguous.
>skip it. And allow driver writers three return codes: GL_UNSUPPORTED,
>GL_EMULATED, GL_ACCELERATED. Make it so they don't HAVE to support
>everything! A rasterization-only OpenGL that actually had drivers
I totally agree with you there. Call it OpenGL-lite if you want :)
We game developers would be extremely happy with that. I'd add
GL_HWEMULATED (for multi-pass stuff, like the Voodoo's specular on
D3D).
>would be better than today's full OpenGL with questionable driver
>availability.
Definitely.
>As for locking the framebuffer, sure, HW guys don't like it, but it's
>essential if you're putting 2D on top of 3D! As long as you don't
>mix framebuffer locks and 3D rendering, you're fine.
Well... Essential... I wouldn't say that. There's already followups
discussing reasons. But it's extremely good for quick prototyping. The
reason we didn't use OpenGL at all in Armor Command was that we used
the FB lock extensively. That was caused because it was our whole
team's first non-DOS game, and our first experience with
hardware-accelerated 3D. We've learnt a lesson there, that's for sure.
FB locks are BAD. But just as bad as using them, is not supporting
them to at least in an emulated manner.
Juan Carlos 'JCAB' Arevalo Baeza
On 15 May 98 10:00:49 GMT, gl...@bullfrog.notanemaladdress (Glenn
Corpes) dignified this group by writing:
>Correct, avoid writing to the screen with the processor at all costs.
For a final product, yes, I agree. But it's nonsensical to disallow
it just on the basis of a final-product reason. It's like not having a
debugger because it slows your app down.
Direct FB access is extremely convenient for debugging purposes.
>One of D3D's strengths is that it allows access to hardware with non
>readable surfaces, for example the PowerVR's z-buffer, it will also work
>with future hardware with non readable screen RAM, AIUI openGL supposedly
Yes, it is. But its other strenght is to also support readable and
writable surfaces.
>simultaneously be subsets and supersets (extensions) of openGL which IMO,
>illustrates the point that while an openGL variant may have been a better
>API than D3D, standard, ARB controlled openGL itself wasn't.
It's basically not meant for this job. My personal opinion is that
OpenGL should be redesigned from scratch, in layers: Basic rendering,
advanced rendering, basic geometry, advanced geometry... But this is a
very personal opinion based on my own API development.
Juan Carlos 'JCAB' Arevalo Baeza
On Fri, 15 May 1998 16:09:41 GMT, rsro...@wam.umd.edu (Rob Rodgers)
dignified this group by writing:
>Plus, lets not kid outselves about this being unrealistic or invalid
That's right. Is there any valid reason NOT to do it?
Isn't OpenGL an 'open', 'extensible' API? Let's just make this an
extension, and see what happens... I seem to remember reading Chris
say this is how it's done.
Juan Carlos 'JCAB' Arevalo Baeza
On Fri, 15 May 1998 03:50:51 GMT, nos...@jet.es (Javier Arevalo)
dignified this group by writing:
>You see, my curent game even still uses execute buffers and I'm not
>ashamed. ;-)
Tu quoque, brother? :)
Juan Carlos 'JCAB' Arevalo Baeza
On Fri, 15 May 1998 07:45:00 GMT, che...@netcom.com (Chris Hecker)
dignified this group by writing:
>We game developers have the real power in this industry, but we get
>dicked around because it's a lot of work to organize. You can argue
Of course it is! The question is... is it worth it enough for
somebody to actually go and do it? Doesn't seem so, so far. The OpenGL
guys (namely Id and their followers) seem to be happy enough with what
they have.
>about whether OpenGL or D3D is better designed (although I think the
>vast majority of technical people would side with OpenGL), but you
It's cleaner... it's beautiful, in fact. But a full OpenGL
implementation is heavily underused when it's used for games. And
that's a design flaw, from my point of view: it imposes an unnecessary
stress on the IHV's, which is the reason why I think they are
providing QuakeGL-only implementations.
Now... What do you think about QuakeGL? Is it well designed from a
technical standpoint? What are its strenghts and weaknesses when
compared to D3D? When you start answering that, you'll have given your
first step towards talking with the game industry.
>can't reasonably argue that the API design ever had anything to do
>with which one Microsoft decided to force on the industry. That, in
Of course not! M$ is a business. D3D has to be a marketing
decision. Businesses don't operate on the basis of 'technical
perfection', do they?
>my opinion, is bad for our industry, and we have only ourselves to
>blame for not standing up to it.
Yes. It's very bad that there is no alternative to either evil...
>I'm not denying it's easier to just give up and support D3D; of course
It's easier and it makes sense to quite a few of us. I'm being
sincere here. I can't seem to be able to find anything realistic that
would make OpenGL worth the effort of pushing the IHV's hard enough.
>it is. However, I think it's worth it to take a little risk and try
>to make OpenGL successful because I feel strongly that it's better for
>the game industry. If we fail, at least we can say we made an effort
>to do the right thing.
Ok. When (if) you (or whoever) decide to go and do it, I'll be
watching. I would even lend help. What the heck, a choice of 2 API's
is always better than the 1.5 we have right now...
Juan Carlos 'JCAB' Arevalo Baeza
On Fri, 15 May 1998 13:03:59 +0100, "Russ Williams"
<ru...@algorithm.demon.co.uk> dignified this group by writing:
>Why? Win95/98 *is* stable. Sure, it can be crashed by
>anything trashing memory, but that's a necessity for
Actually, it's not stable. Nor is NT either, for that matter.
>DOS game support. If you want a _more_ stable OS,
>buy NT.
This is actually not accurate. I was amazed at the surprisingly
good DOS game support available in OS/2 v3+. I never understood how
it's possible that Microsoft never managed to emulate its own OS
properly in ANY Windows flavor, while IBM could. I remember playing
X-Wing on a window. Slow, but robust enough to support it.
Not that OS/2 was free of flaws itself...
David Springer
I can't believe this battle is still going on.
Look, it IS a driver model issue. I told you that. Alex told you that.
You game developers don't understand the problems in getting good
3D accelerators into the hands of the masses. OpenGL just didn't fit
the bill. It's too expensive and too fluid. We simply cannot deal
with those attributes in cost and time-to-market sensitive PCs that
are sold in the millions.
Dell and NVIDIA led the way and sold more outstanding D3D platforms to
consumers in the past 6 months than all the OpenGL platforms in history,
including 3DFX.
Now stop complaining about the API and start worrying about why there's
a few leading games and 5000 clones of the few leading games.
David Springer
Senior Engineer
Dimension Product Group
Dell Computer Corporation
David Springer
Well Chris, I guess it's pretty safe to say you still don't get it.
While you were away the last 6 months Dell sold more Riva 128 equipped
PCs to consumers than all the OpenGL platforms in history. Not a single
one left the factory with an accelerated OpenGL but they all had D3D.
Consumers, you know, the ones who buy PCs and play your games on them,
aren't demanding OpenGL. They only see the game and don't care how it
gets on the screen.
What they would like is something more than 3 good titles in 5 stale
game categories. Any chance of that ?
David Springer
ast...@bootnet.com wrote:
> -DirectX would remove driver headaches for developers. MAJOR WRONG.. it was
> a nice thought though...
>
Yeah, but it removed driver headaches for Microsoft, PC vendors, and most
importantly - customers - clearing the way for making reliable, consistent,
high performance game hardware a baseline attribute in untold millions of
personal computers.
The needs of the many must outweigh the needs of the few.
David Springer
Paul Hsieh (q...@chromatic.com) wrote:
>
> and they just don't inspire any sort of confidence. As much as I think of
> SGI as a completely screwed up company, they still have top notch engineers
> and the resiliance of OpenGL throughout all of this is a testimony of that.
>
Hey Paul, did you read about SGI suing NVIDIA, seeking an injunction to
stop shipments of Riva chips ?
I think the top notch engineers were replaced by top notch lawyers.
If you can't beat 'em, sue 'em...
-ds
David Springer
Juan Carlos 'JCAB' Arevalo Baeza (jc...@roningames.com) wrote:
> On Wed, 13 May 1998 14:17:51 -0700, q...@chromatic.com (Paul Hsieh)
Let's shed the light of reality on this technophile fest. There are four
things that get a graphics IHV the coveted spot on the motherboard (not
necessarily ON the motherboard but bundled with the PC):
1) price - it has to fit into the price band of the PC in question. Here
we're looking mostly at segments 2, 3, and 4 (roughly $1500-$3000 PC).
2) timing - it has to be DONE in time for major technology transitions
driven by Intel roughly twice a year. Done means tested, certified, and
in production including hardware and drivers. Certification is a long
laborious process which includes FCC and WHQL (Windows Hardware Quality Lab).
Testing also takes many weeks. In production means final silicon being
produced in volume.
3) volume - fab capacity ramped up to tens of thousands of units weekly.
4) benchmarks - the only ones that matter are Windows 2D and 3D benchmarks.
No large circulation trade magazines benchmark OpenGL on seg 2,3 and 4 PCs.
They ALL benchmark D3D. The benchmarks have to be in line with pricing
in the target segments.
Nobody of any import to the mass PC market is looking at the esoteric
features that are being hotly debated here.
I've tried to make this clear many times in the past but it just doesn't
seem to sink in.
Denial is more than just a river in Egypt. IHV's care about what gets
them design wins at the big four PC makers. Whether you admit it or not
game developers are not driving the IHV's.
Scott Le Grand
David Springer wrote:
> Well Chris, I guess it's pretty safe to say you still don't get it.
>
> While you were away the last 6 months Dell sold more Riva 128 equipped
> PCs to consumers than all the OpenGL platforms in history. Not a single
> one left the factory with an accelerated OpenGL but they all had D3D.
>
There ya go David with a good point but all those negative vibes. Dell,
Intergraph,Gateway, Acer, and every other OEM has to move a high end unit or
two for CAD
workstations. CAD demands OpenGL hence OpenGL remains. All that annoying
legacy graphics code like Pro/E, Microstation, Exceed, and a hundred other
apps too
boring and stodgy to mention here will remain a thorn in Mr. Bill's side for
another
ten years if not longer. It's even better than the Millennium Bug(tm)! Are
you actually
suggesting that Microsoft will give customers like Ford Motors, Lockheed,
and Boeing a
flaming middle finger to force them to dump their 10 year old going strong
OpenGL legacy
code for tasks like engine design? Sure, Direct3D moves the units, but NT's
penetration of
the unix workstation market dies the minute they dump OpenGL Ideologies
aside, the IHVs
all have significant staff dedicated to OpenGL support and optimization, and
they're still hiring
away (especially the aforementioned NVidia). Sheesh, IGDN's salary survey
even
shows OpenGL as the highest paying API to know. While it's been an amusing
war to watch Microsoft insist that OpenGL is irrelevant, they've never
really
had a choice but to support it IMO and the IHVs were way ahead of them.
> Consumers, you know, the ones who buy PCs and play your games on them,
> aren't demanding OpenGL. They only see the game and don't care how it
> gets on the screen.
>
Absolutely... Today's games suck, pretty much across the board IMO.
There'sno excitement, no life, just stale 3D FPS boredom.
> What they would like is something more than 3 good titles in 5 stale
> game categories. Any chance of that ?
Ya know, I've been kvetching about this for about 3 years now. If anything,
the situation keeps getting worse. But to be fair, most of the few really
creative
games of the past year (Galapagos, Creatures, Tetrisphere, etc) were just
plain awful despite all the great ideas that went into their designs.
But this year things have changed. Deer Hunter brought home the message
that low budget creativity sells. Now the same idiot savant^H^H^H^H^H
idiots
that brought us the 5 blessed game genres, the FMV plague, and the every
game must
be 3D and network bandwagon, are the same bozos plotting a response to the
success of
Deer Hunter. So far that response has been to add low budget hunting games
to the now 6 acceptable genres. Go team go! What WILL they think of next?
Scott
Phil Oliver
David Springer wrote in message <6jjj62$dp$1...@boris.eden.com>...
>Well Chris, I guess it's pretty safe to say you still don't get it.
>
>While you were away the last 6 months Dell sold more Riva 128 equipped
>PCs to consumers than all the OpenGL platforms in history. Not a single
>one left the factory with an accelerated OpenGL but they all had D3D.
From www.opengl.org:
STB has shipped a new Velocity128 accelerator with 8 MB RAM, great price, great
performance and support for OpenGL (see the the NVIDIA ICD driver). The new Velocity128
uses the RIVA128ZX chip from NVIDIA with a full OpenGL ICD.
:P
Phil Oliver
Javier Arevalo
"R. Jason Sams" <r...@ablecom.net> wrote:
>OpenGL standard is forcing the IHV to implement a common set of basic
>abilities. If you want to use card specific features then check for
>extensions.
No but if some IHV (say, S3 anyone?) does not implement that common
set yet their chip is popular, I need to support it as well.
>you do not have a in depth undestanding of BOTH APIs then you are not
>qualified to compare them on a technical basis.
Exactly what I am NOT doing. I am not saying "OpenGL API sucks" or
"D3D API sucks" or anything like that. I am talking from a broader
point of view. I am concerned with driver availability, evolution,
market support, etc etc which are NOT technical features of either D3D
or OpenGL.
If it were purely for technical quality of API design OpenGL would
have won hands over long ago. We all know that. That is not the issue,
at least not to me.
>>I'll let Microsoft know I want it.
>You must have much better luck than I. Asking for a stable OS goes nowhere.
>Asking for OpenGL support goes nowhere. Asking them to provide NT support
>to DirectX still is not done.
A stable OS is not their their 1st priority, OpenGL support is not
their strategy. I accept that, it wouldn't be mine either. NT support
is not just on the way, but in fact is THE way (the DirectX team is
not part of the NT systems group, if that's any indication). They
moved DX to NT when DX on NT started to make commercial sense.
>The most compelling argument to get OpenGL support is to write a killer game
>that uses it. If you can produce a game good enough, I can guarantee that
>the IHVs will provide whatever driver you need.
Yeah, but I am not here to prove anything or to preach anything or to
shape the world I want it to be regardless of anything else. If Quake
hasn't done it then nothing will. I am still waiting for those OpenGL
drivers. I hear today that they'll be there in 2-4 months, that's the
same thing I heard 1 year ago. 1 year has passed, and the need or
soundness of OpenGL support is less important than ever, with D3D
becoming better known and more robust, stable and feature-complete.
Greets
Javier Arevalo
http://web.jet.es/jare
change nospam to jare in the address to send email
Javier Arevalo
che...@netcom.com (Chris Hecker) wrote:
>I knew as soon as I posted it that using the term "lucky" was a
>mistake in the unforgiving world of r.g.p.
You got what you deserved. ;-)
>"we might
>get that choice if we, as game developers, work hard enough to make it
>happen."
But there's one thing I don't understand from your argument: you say
the "the dev. industry wants MS to ditch D3D and turn to OpenGL". I
don't see the industry asking that. You say the reason is the dev.
industry is not organized and united. I don't see that many people
begging for OpenGL, even in private and when asked directly. I see
some people like you or Carmack (not lately, huh) with a lot of vocal
power (don't get me wrong) stating that, and that's about it.
Think about this for a minute: if the D3D advocates like myself made
as much noise comparably to what OpenGL advocates like yourself, what
do you think would happen?
I see my colleagues being mostly concerned about driver support, the
troubles and pains of commodity hardware that takes shortcuts every 50
microns. OpenGL does not alleviate that. Of course jokes about COM and
cap bits are the norm, but that is not an indication that we want
OpenGL. If it was just the API, OpenGL would be the winner, but the
API design is not my 1st priority, and I'm thankful it is not MS's
priority as well.
David Springer
Phil Oliver (ph...@NOSPAMpoboxes.net) wrote:
>
> From www.opengl.org:
>
> STB has shipped a new Velocity128 accelerator with 8 MB RAM, great price, great
> performance and support for OpenGL (see the the NVIDIA ICD driver). The new Velocity128
> uses the RIVA128ZX chip from NVIDIA with a full OpenGL ICD.
>
>
I'll take some of the credit for that, thanks. It was my D3D wrapper that
motivated NVIDIA to release the uncertified OpenGL. Unfortunately NVIDIA
only designs the chips and supplies a reference driver to companies like
Diamond and STB. Even though there's been an OpenGL driver for the Riva
128 since December you haven't seen it shipping with a Riva 128 card. I
wanted it only to give Dell a leg up in game magazine reviews. Reviewers
will go out and get it and so will Quake players but Joe Average Consumer
won't. And while you might see it shipping with Dell Dimensions in the
future if NVIDIA ever gets it certified and STB or Diamond or whoever
supports it that doesn't translate to it being available on other graphics
cards. Also, its inclusion in consumer space still doesn't translate
to many extra PC sales. It was just luck that in this case that I happened
to think that it would be cool to have glQuake benchmarks for Dell
Dimensions and was in a position to make it happen. I didn't get any
kudos from my employer and indeed was mildly rebuked for distracting
NVIDIA from more important work.
David
Thomas Womack
David Springer <spri...@matrix.eden.com> wrote:
: won't. And while you might see it shipping with Dell Dimensions in the
: future if NVIDIA ever gets it certified and STB or Diamond or whoever
: supports it that doesn't translate to it being available on other graphics
: cards.
There are STB drivers dated around 15 April 1998 available on their
web site, which produce pretty impressive OpenGL on my friend's Dell
Dimension.
Tom
Russ Williams
R. Jason Sams wrote in message <6jhpvm$78v$1...@news6.ispnews.com>...
>>"Is developing" is worthless. They've been in perpetual
>>beta for many months.
>
>True, however they are nearing completion. At least from
>three of the companies.
Again, this has been touted as the case for many months.
I'll believe it when I see it, and not before.
>>MCD drivers are also useless - you only need to look at
>>the MCD vs beta ICD scores for Quake to see that.
>>They are simply too slow.
>
>MCDs are slower. However if you want ANY acceleration
>on NT OpenGL is your only choice.
Actually, I'd go for Glide as well. There's a lot of 3dfxen
out there.
>They were designed to make the life of the driver writer
>easier, not make performance better.
And have suceeded. Games, however, are (more often
than not) highly performance led.
>ICD should always win on performance.
The fact that there needs to be 'an easy way' for IHVs
suggests (to me, at least) that there's something wrong
with the API/driver model.
>>>It was designed as an API to work with crippled
>>>hardware.
>>
>>Which is still what is being shipped.
>>Is that going to change in the next year? Doubtful.
>>Sure, the hardware will improve, but I'll bet that in a year's
>>time we still don't have consumer hardware supporting
>>all of the required OpenGL render-states in hardware.
>
>Also true. However, the nVidia TNT, Matrox G200, s3
>Savage, and others will support most of the OpenGL
>rendering states. You still have to be aware of the costs
>of diffrent rendering modes.
Very true. I think you missed the i740 off the list, too.
Once most render states are in hardware, the API
choice won't matter much.
I'd say that D3D's rapid evolution will give it a better
chance of coping with the generation-after-next 3d cards,
though - as has been pointed out, OpenGL doesn't have
multitexture as more than an extension at the moment.
Not that big a deal, though - after all, textured/lit/alpha
blended triangles are all you really need for most
effects.
>>>As such it caries a large amount of baggage.
>>
>>Hehe. In comparison to an API that requires software
>>emulation of unsupported features, *D3D* has a lot
>>of baggage?
>
>By baggage I mean that once the hardware becomes more
>powerful, why not use a proven and robust api that works
>well with high end hardware. DirectX is continually playing
>catch up to the hardware.
True. Is there any other way, though? The hardware (at both
high and low ends) is in a state of flux. OpenGL has rode
this well, but (IMO), the ARB is simply too slow at making
decisions. There are extensions to make up for that, but
there is a limit to how far you can go without changing your
assumptions (e.g.: the rendering pipeline).
Also, is commodity hardware going to be 1:1 with older
high-end? I think it's likely to be considerably different
a hybrid of ex-high-end with state-of-the-art (like
multitexture). I can't really see 3d cards having enough
VRAM and processing power for display lists, for
example. (Not for a good few years, at least).
>>>Examples here are the lack of multi-texture,
>>
>>In DX6, I believe. That's coming in July.
>
>True, but I would rather not have to wait for Microsoft to
>add features that are already available to me using
>other means.
But a single controlling body makes things so much
easier. D3D has O(n) communications for IHVs,
compared to O(n^2) for OpenGL extensions (every
IHV must talk to the rest if they are to agree on a
common extension for a feature.
>>>DirectX lacks the ability to fully use geomitry acceleration.
>>
>>True. Do any consumer cards other than Diamond's FireGL
>>1000 Pro support that?
>
>Rendition will be shipping one soon acording to rumors on
>the web.
Cool.
Did I see someone else in the thread say "In DX6" for this?
[...]
>>>I guess DirectX games will not have proper shadows,
>>
>>I guess not. Still, who'd want to do shadows with an
>>emulated stencil-buffer?
>
>See above list of hardware with this ability either now of by
>end of year.
Yup. What of the 3dfx/Rendition/etc cards?
>>>only professional games will.
>>
>>It was this comment that made me choose to reply to this
>>message.
>>
>>Maybe you should look up the term. See how many
>>games are being released using OpenGL and
>>stencil-buffer shadows? Zero. How many with OpenGL?
>>Mostly just the Quake licensees. It seems that the
>>professionals are using D3D.
>
>If the consumer hardware is expected to be available in the
>next 6 months, (common in 12 ?) It would make sense to
>spend a little money and get a professional board to
>develop you game, after 12 months of development you
>find that the cards are now shipping with your required
>stencil buffer and you market your game.
Assuming that everything goes according to plan. If not,
you end up with a game that runs on a Permedia 2 and
runs at ~1fps on everything else. Not good.
>Now with a Microsoft API, you first beg them for a Stencil
>buffer. If they decide to add one you wait 12+ months for
>a beta API which you can use to develop your game.
>Once you have it you begin development. After 12 months,
>plus 1 for using a beta API you have a game ready to ship,
>but you are 13 months late to the market because you
>spent 25 months from start to finish.
The problem with this hypothesis is that DX6, with stencil
buffers, is largely preceeding stencil buffer hardware by
quite a long time. MS are adding features now that will
be in next-year's hardware.
My philosophy is to make the rendering as modular as
possible, so changing APIs isn't a huge task. After all,
neither D3D nor OpenGL is much use on a PlayStation.
>>>OpenGL standard is forcing the IHV to implement a
>>>common set of basic abilities.
>>
>>Yes. Mostly in software, since they can't fit an Onyx on
>>a $30 chip. Is it a good idea forcing IHVs to
>>write/beg/borrow/steal software OpenGL renderers?
>
>No, I would like to see a standart software fallback engine
>for OpenGL. Having each vendor write their own is a little
>bit of a mess.
That would be better. MCDs don't work well, though.
I still believe some sort of caps system is important.
If the ARB had allowed susbsetting of OpenGL, it
might have crushed D3D. Requiring that, say, an S3
Virge or ATI Rage supports the full range of OpenGL
rendering states is (IMO) ridiculous.
>>>If you want to use card specific features then check
>>>for extensions.
>>
>>A good point, but what about determining which standard
>>features are in hardware, and which aren't?
>>
>>Sure, you could time some rendering, but that would require
>>an exponential number of tests.
>
>This problem is no better (some would say worse) in DirectX.
>Just checking the cap bits will not tell you if the feature is
>usable (fast enought) for your game. Try trilineal filtering or
>blending on some cards.
'Fast enough' isn't really an issue now.
There should always be a 'fast/pretty' option in your game,
anyway.
[...]
>>>>And if I want an extension mechanism (which I'm not
>>>>terribly interested in, I mean, it would be cool but it's
>>>>not my priority), I'll let Microsoft know I want it.
>>>
>>>You must have much better luck than I. Asking for a
>>>stable OS goes nowhere.
>>
>>Why? Win95/98 *is* stable. Sure, it can be crashed by
>>anything trashing memory, but that's a necessity for
>>DOS game support. If you want a _more_ stable OS,
>>buy NT.
>
>I do use NT, but then I cann't use DirectX. (With hardware)
It's a bit of a bugger, that. Still, we probably only have to wait
a few months for NT5 (with DX6 :).
[...]
>>>If you can produce a game good enough, I can guarantee
>>>that the IHVs will provide whatever driver you need.
>>
>>Ah yes. QuakeGL.
>>Just imagine the benefits: hundreds of subtly different
>>'OpenGL' drivers for every combination of card and
>>game.
>
>That was not my point. Even if you use a completly diffrent
>API, if the game is good enough you will get drivers for it.
Yup. I remember the 69 different executables that appeared
for Tomb Raider. That has to be a logistical nightmare
keeping all those different versions in sync.
It's far better to have just a single version, like TR2. All an
IHV has to do to support that is write a working D3D driver.
No messing around writing custom versions (unlike
Quake 2).
>>>To them they need to sell hardware and they can only do
>>>that if they run the cool games.
>>
>>Yup. Which is why people use D3D - it provides support
>>for *all* IHVs hardware.
>
>Yes, but it is a little diffrent on each. From abilites supported
>to rasterization quality. And there are no standards in place
>to fix that.
AIUI, OpenGL doesn't specify anything about the image
output, either - that's purely down to the hardware (and/or
software fallbacks).
D3D has to vary the supported abilities - all cards are
not born equal.
>>>We are the game developers, its up to us to win or lose
>>>this battle.
>>
>>And our part in this battle would be, what? Sitting around,
>>waiting/hoping/praying/asking IHVs for OpenGL drivers?
>>We *still* haven't got *first generation* OpenGL drivers,
>>yet, and the initial releases are always flaky. How long
>>before they are actually usable? Are you willing to risk
>>everything on drivers hopefully being available by the
>>time you ship? It's a big task to push onto an IHV, so what
>>makes you think they'd:
>> i) Take any notice
>> ii) Make a good job of it
>> iii) Do either of the above before you need to ship
>
>You should talk to the IHVs. Many have told me that their is
>no longer any reason to use DirectX unless you want to.
>Everyone serious about games has a card from 3Dfx,
>nVidia, Rendition, or 3Dlabs. All of them have drivers
>in beta or better.
The problem is that it would be rather irresponsible to ship
beta drivers with a game ("Just install this buggy driver that
might completely f**k up your system and our game will
consider working").
Most customers don't go hunting for latest versions of
drivers, they just install the version that comes on the
CD. If it doesn't work, they go back and complain.
>The one from nVidia and Rendition are looking very good
>at this point. You can add the i740 and G200 to the above
>list. You had better beleive that Real3D will ship good GL
>drivers and we will see what Matrox does.
If you're prepared to take a chance on driver availability,
sure. Me, I'd wait until it became a certainty and then
port. That way, you don't get burned by mispredictions
of market state.
>>PS - I still don't get why people think it's an either-or
>>decision. Changing from one 3d API to another isn't
>>exactly difficult. People have 3d cards with D3D
>>support, so why not do both? Support your preferred
>>API and your customers.
>
>Because I have developed games with both. It takes me
>about three to four times the effort and time to get
>something working on DirectX as it does with OpenGL.
Which is, what, days instead of hours?
I'd be suprised if it would take more than a week or two
to go from OpenGL to D3D (assuming the code was
written to be portable).
Even if the driver support is there for both, the number of
sales you'd get for API comparisons would probably make
that worthwhile...
>That time is better spent working on a better product
>rather than dealing with another broken MS api.
What makes you think the two are distinct? Technical
perfection counts for less than you may think. Part of
making a good product is knowing the market.
Win95 is hardly what you'd call great technically, yet
it sells by the truck load. Why? Because it's right for
the consumer. Having a really nice, pretty game is a
useless if no-one can play the damn thing because
they don't have drivers.
---
Russ
Phil Oliver
David Springer wrote in message <6jkrb1$aom$1...@boris.eden.com>...
>I'll take some of the credit for that, thanks. It was my D3D wrapper that
>motivated NVIDIA to release the uncertified OpenGL.
Can you explain what D3D wrapper means in this context? If you mean
an OpenGL driver that uses D3D calls to do stuff, I've thought that this
was an interesting idea from the standpoint of portability -- OpenGL
would then be available on any D3D driver'ed card.
re: your previous comments about gamers being insignificant to sales
of video cards: Are you talking about game developers or people who play
video games? Focusing on the latter, why ELSE would anybody want a high
performance 3d card? Sales of 3d video cards are driven almost exclusively
by people who want to play high speed video games.
Phil Oliver
Javier Arevalo wrote in message <6jkgqv$9b2$1...@excalibur.flash.net>...
>If it was just the API, OpenGL would be the winner, but the
>API design is not my 1st priority, and I'm thankful it is not MS's
>priority as well.
What is your priority?
Sean T Barrett
Russ Williams <ru...@algorithm.demon.co.uk> wrote:
>>ICD should always win on performance.
>
>The fact that there needs to be 'an easy way' for IHVs
>suggests (to me, at least) that there's something wrong
>with the API/driver model.
No, it's due to the simple fact that if you want both
extreme flexibility and extremely high performance, you
need a very very large amount of code between the app
and the hardware--i.e. you want the driver to implement
the API "directly".
Saying "MCD is crippled" is about like saying "DX5 D3D
is crippled"--and that's ignoring the fact that the OpenGL
supports a broader, more useful API.
The direction we are going is towards hardware that
does support all the stuff OpenGL has had (i.e. that
D3D is adding). When that hardware supports everything,
you'll need an API with the breadth of OpenGL. If you
want maximal performance, you want that layer as thin
as possible. OpenGL ICDs are like that. D3D's execute
buffers were a flawed attempt at being like that.
If you and Dave Springer feel obliged to continue to
assault OpenGL, please stop with the "but there are
no drivers because OpenGL drivers are too hard to
write" (gee, do you perhaps recall a time when MS
_killed_ Win95 MCD support out from under IHV's) and
"if it has two different driver models it must be bad".
These are dead and disproved topics; please find a
different response to OpenGL's "technical superiorty"
if you feel the subject actually requires debate.
The debate about the actual existence of drivers in
the marketplace and the question of what API people
might want to consider using in today's market are
entirely separate; reread the previous paragraph and
note that all of this is argument about _inherent_
properties of OpenGL, not today's marketplace.
Sean
Matt Craighead
Sean T Barrett wrote:
> No, it's due to the simple fact that if you want both
> extreme flexibility and extremely high performance, you
> need a very very large amount of code between the app
> and the hardware--i.e. you want the driver to implement
> the API "directly".
NO! That is the _worst_ kind of driver. In fact, it's hardly a driver.
It causes severe interoperability problems. It is FAR better for a
layer to sit between drivers and apps, sending calls off to the
appropriate callbacks. This reduces work for driver developers, makes
it easier to add support for new features, like 3DNow, and, perhaps
most importantly, makes drivers independent of the API version.
> Saying "MCD is crippled" is about like saying "DX5 D3D
> is crippled"--and that's ignoring the fact that the OpenGL
> supports a broader, more useful API.
Oh, I really want and need feedback. (not!)
Every extra useless OpenGL feature is, to me, just another annoying
piece of a driver that every IHV has to worry about.
OpenGL is too big -- certainly far too big for a "raw implementation"
driver model!
> The direction we are going is towards hardware that
> does support all the stuff OpenGL has had (i.e. that
> D3D is adding). When that hardware supports everything,
> you'll need an API with the breadth of OpenGL. If you
> want maximal performance, you want that layer as thin
> as possible. OpenGL ICDs are like that. D3D's execute
> buffers were a flawed attempt at being like that.
Total BS. ICD is a _worthless_ driver model! D3D has a real driver
model. Execute buffers were wrong, yes, but I no longer concern
myself with execute buffers. They are irrelevant to me. Only DP is
relevant, and soon only DX6 and its vertex buffers and such will be
relevant (as soon as that CD arrives). The layer should minimize
driver development costs, not be as thin as possible. An extra call
statement is nothing compared to the cost of transforming, lighting,
clipping, and batching 1000 triangles.
> If you and Dave Springer feel obliged to continue to
> assault OpenGL, please stop with the "but there are
> no drivers because OpenGL drivers are too hard to
> write" (gee, do you perhaps recall a time when MS
> _killed_ Win95 MCD support out from under IHV's) and
> "if it has two different driver models it must be bad".
> These are dead and disproved topics; please find a
> different response to OpenGL's "technical superiorty"
> if you feel the subject actually requires debate.
I am arguing that ICD is, from a technical standpoint, ABSOLUTELY
TERRIBLE. I am arguing that driver size must be kept low to decrease
the amount of work that IHVs must perform. If they can't handle even
(relatively) simple DirectDraw and D3D drivers, how can they POSSIBLY
handle OpenGL ICDs?
As much of the API implementation should be kept in an OS DLL as
possible. As little as possible should be put into the driver.
> The debate about the actual existence of drivers in
> the marketplace and the question of what API people
> might want to consider using in today's market are
> entirely separate; reread the previous paragraph and
> note that all of this is argument about _inherent_
> properties of OpenGL, not today's marketplace.
I am arguing the inherent properties of ICD and saying they SUCK.
Direct API implementations are an absurd driver model for the PC.
They are suited for high-cost proprietary systems, on which the vendor
can actually afford the development and optimization for each one (so
SGIs are perfect targets for them). PCs? Try again.
D3D's driver model is _technically superior_ to OpenGL ICD.
David Springer
Thomas Womack (mert...@sable.ox.ac.uk) wrote:
>
> There are STB drivers dated around 15 April 1998 available on their
> web site, which produce pretty impressive OpenGL on my friend's Dell
> Dimension.
>
There is OpenGL support for the STB Velocity 128 at Dell's web site.
They were placed there less than 10 days ago. And only 8 months behind
the D3D drivers... better than nothing I guess.
Maybe next time OpenGL will be done before half a million machines ship
without it. Or do you think it would be preferable to delay shipping
new platforms for six months while waiting for certified OpenGL drivers
that maybe 1 of 500 customers care about ?
David Springer
--
*************** IGAMES INTERNET GAME LOBBY ****************
* *
* NOW SUPPORTING MICROSOFT DirectPlay 3 LOBBY STANDARD ! *
* *
* A real-time game lobby for the internet with many *
* exciting games and thousands of players. Game *
* developers, players, and ISP's can try it out at: *
* *
****************** http://www.igames.com ******************
R. Jason Sams
>NO! That is the _worst_ kind of driver. In fact, it's hardly a driver.
>It causes severe interoperability problems. It is FAR better for a
>layer to sit between drivers and apps, sending calls off to the
>appropriate callbacks. This reduces work for driver developers, makes
>it easier to add support for new features, like 3DNow, and, perhaps
>most importantly, makes drivers independent of the API version.
This does make developing the drivers easier but can reduce performance in
some cases.
>Oh, I really want and need feedback. (not!)
>
>Every extra useless OpenGL feature is, to me, just another annoying
>piece of a driver that every IHV has to worry about.
Just because you can't think of a use for a feature does not mean that
someone else wont. I want motion blur(accum buffer), realistic shadows
(stencil buffer), and water effects (texture matrix). Now these are just a
few uses I can think of. I am sure there are others. This reminds me of
the old argument that memory protection just slowed things down. That
Windows was just a useless GUI and dos was fine.
I you are content with what DirectX offers thats fine. Please do not make
an attempt to stop the rest of us from using the API that gives us what we
want.
>OpenGL is too big -- certainly far too big for a "raw implementation"
>driver model!
No its not. There is hardware like the Glint Gamma that bennifets greatly
from this model. What you are really arguing is that consumer hardware does
not currently bennifet. As these cards currently in the 2K price range
become consumer level soon (next year?) this model will help.
>Total BS. ICD is a _worthless_ driver model! D3D has a real driver
>model. Execute buffers were wrong, yes, but I no longer concern
>myself with execute buffers. They are irrelevant to me. Only DP is
>relevant, and soon only DX6 and its vertex buffers and such will be
>relevant (as soon as that CD arrives). The layer should minimize
>driver development costs, not be as thin as possible. An extra call
>statement is nothing compared to the cost of transforming, lighting,
>clipping, and batching 1000 triangles.
See above. Please talk to some of the hardware people before you make these
statements. If you are not in driver development please do not profess to
be an expert on the subject. OpenGL is an API not a driver model. MCD and
ICD are Microsoft attempts at a driver model to implement the API. Each has
advantages and disadvantages. I personally would like to see a replacement
for the MCD model. However, ICD are the wave of the future, esspically as
gemoitry acceleration becomes common.
Please think and don't simply tow the MS line.
>I am arguing that ICD is, from a technical standpoint, ABSOLUTELY
>TERRIBLE. I am arguing that driver size must be kept low to decrease
>the amount of work that IHVs must perform. If they can't handle even
>(relatively) simple DirectDraw and D3D drivers, how can they POSSIBLY
>handle OpenGL ICDs?
Since I develop OpenGL drivers I can say you are wrong. ICD are not
terrible, and yes we can handle our jobs just fine.
>As much of the API implementation should be kept in an OS DLL as
>possible. As little as possible should be put into the driver.
Only if you want to forever be limited by what MS will provide you in that
DLL.
>I am arguing the inherent properties of ICD and saying they SUCK.
Please make yor arguments form a technical standpoint. Why does giving the
IHV the ability to implement an API as efficiently as possible on their
hardware suck? Sure there will be IHV that screw up, but that is nothing
new or limited to an ICD.
>Direct API implementations are an absurd driver model for the PC.
>They are suited for high-cost proprietary systems, on which the vendor
>can actually afford the development and optimization for each one (so
>SGIs are perfect targets for them). PCs? Try again.
It does not take hundreds of people to write a driver. Less than six can do
the job just fine, and I would argue that 2-3 is the optimal team size. I
think an IHV can afford three good developers to write a driver.
>D3D's driver model is _technically superior_ to OpenGL ICD.
Please refrain from this argument unless you have developed drivers for
both. And hopefully used both APIs.
--Begin RANT--
Please lets limit a discussion about the merits of drivers model to those
who actually develop them. This is not a discussion for everyone that has
read a MS or SGI press release.
For those who want to discuss the API again please don't coment unless you
have developed a signifigant piece of software using both.
Lets make this an informed discussion.
--End Rant
Sean T Barrett
Matt Craighead <crai...@citilink.com> wrote:
>Sean T Barrett wrote:
>> No, it's due to the simple fact that if you want both
>> extreme flexibility and extremely high performance, you
>> need a very very large amount of code between the app
>> and the hardware--i.e. you want the driver to implement
>> the API "directly".
>
What, one with high performance?
[...]
>It is FAR better for a layer to sit between drivers and apps,
>sending calls off to the appropriate callbacks. This reduces
>work for driver developers [...]
There are other ways of sharing common code between drivers
than adding a mandatory intermediate layer.
>> Saying "MCD is crippled" is about like saying "DX5 D3D
>> is crippled"--and that's ignoring the fact that the OpenGL
>> supports a broader, more useful API.
>
>Oh, I really want and need feedback. (not!)
>
>Every extra useless OpenGL feature is, to me, just another annoying
>piece of a driver that every IHV has to worry about.
Ok, will you give me $10,000 for every "useless"
OpenGL feature that ends up in D3D? You make think it's
a knock against OpenGL, but GL's only competitor on the
PC is clearly heading in that direction--no surprise, since
the hardware itself is as well.
But I already posted that exact fact in another paragraph
in my original:
>> The direction we are going is towards hardware that
>> does support all the stuff OpenGL has had (i.e. that
>> D3D is adding). When that hardware supports everything,
>> you'll need an API with the breadth of OpenGL.
Which part of that paragraph didn't you understand?
>relevant (as soon as that CD arrives). The layer should minimize
>driver development costs, not be as thin as possible. An extra call
>statement is nothing compared to the cost of transforming, lighting,
>clipping, and batching 1000 triangles.
Provide a _reason_ why that should be so? And perhaps consider
that you totally ignored the thrust of my post, which was that
these are arguments for technical reasons, _setting aside_ business
reasons. "Driver development costs" is business.
I'm not saying we don't have to consider economic issues
when we come down on what's going on in the real world;
but I also don't think economic issues _are_ technical ones.
I don't understand why you people get so defensive about
it. OpenGL is technically superior, but you have to use
D3D, so you feel obliged to attack that technical superiority
with specious, question-begging arguments about driver
development costs? Call a spade a spade. "OpenGL is
technically better, but IHVs suck"--not doublethink like
"OpenGL is technically inferior because IHVs suck".
>I am arguing that driver size must be kept low to decrease
>the amount of work that IHVs must perform. If they can't handle even
>(relatively) simple DirectDraw and D3D drivers, how can they POSSIBLY
>handle OpenGL ICDs?
>
>As much of the API implementation should be kept in an OS DLL as
>possible. As little as possible should be put into the driver.
Why not put it all into a "generic driver" and give the source
code to the IHVs? Then they can accelerate those portions of
it that their hardware can accelerate, and yet not have to go
through a layer.
>I am arguing the inherent properties of ICD and saying they SUCK.
>
>Direct API implementations are an absurd driver model for the PC.
>They are suited for high-cost proprietary systems, on which the vendor
>can actually afford the development and optimization for each one (so
>SGIs are perfect targets for them). PCs? Try again.
>
>D3D's driver model is _technically superior_ to OpenGL ICD.
You seem to have confused "technically superior"
and "pragmatically superior".
Anyway, IHVs are in a competitive marketplace, where they
actually try to make (I know this is going to be difficult
for you to believe, but for once take my word for it) hardware
that *runs faster* than their competitors.
They *do* care about performance.
Feel free to have the last word; after all, all I'm
doing is repeating what I said in my original post;
if you insist on replying to posts which contain the
material that refutes your replies, well, I can just
save myself the trouble.
Sean
Russ Williams
Thomas wrote in message ...
>In article <6jl20m$flr$1...@usenet43.supernews.com> "Russ Williams"
<ru...@algorithm.demon.co.uk> writes:
>
> >They were designed to make the life of the driver writer
> >easier, not make performance better.
>
> And have suceeded. Games, however, are (more often
> than not) highly performance led.
>
>these days. For example, Quake II looked like it had nicer
>graphics, but it seemed like a worse game than Doom or
>Quake to me.
That's because id are pushing the technology, not the
gameplay. Compare Q2 with something like Daikatana,
Sin or some of the other licensees.
My point is that if you're doing a game that needs a 3d
card, throwing away 50% of your performance is not
a popular option.
Most of NT's 3d card support is through MCDs and
almost no 3d games run under NT. Coincidence?
---
Russ
Thomas Womack
David Springer <spri...@matrix.eden.com> wrote:
: Maybe next time OpenGL will be done before half a million machines ship
: without it. Or do you think it would be preferable to delay shipping
: new platforms for six months while waiting for certified OpenGL drivers
: that maybe 1 of 500 customers care about ?
I certainly wouldn't suggest that. I *would* be somewhat tempted, were
I enough of a lunatic to try competing with big companies in the sale
of PCs, to send out a CD quarterly to all customers which would
install new drivers, new utilities, etc. automatically. You have
control of the hardware, so you can be fairly sure which drivers are
needed, and the result is that even people who can't be bothered to
download drivers, or don't know what a driver is, will have ones at
most three months old.
'Tune-Up CD. Just put in the drive, wait for AutoPlay, and click 'Tune Up''!
Tom
Rob Rodgers
buz...@world.std.com (Sean T Barrett) wrote:
>write" (gee, do you perhaps recall a time when MS
>_killed_ Win95 MCD support out from under IHV's)
Best thing to ever happen to OpenGL's chances at being used in games.
If the MCD model had stuck around, everyone woul dhave shipped MCDs,
the SGI kit would never have happened, and OpenGL performance would
have been terrible.
Russ Williams
Sean T Barrett wrote in message ...
>Matt Craighead <crai...@citilink.com> wrote:
>>Sean T Barrett wrote:
>>> No, it's due to the simple fact that if you want both
>>> extreme flexibility and extremely high performance, you
>>> need a very very large amount of code between the app
>>> and the hardware--i.e. you want the driver to implement
>>> the API "directly".
>>
>>NO! That is the _worst_ kind of driver.
>
>What, one with high performance?
Relatively high performance. ICDs are no faster than D3D
drivers on the vast majority of 3d cards. The ICD model
imposes a big penalty with all those function calls. Sure,
you can use vertex arrays instead of glVertex, but when
you compare that to D3D's one function call for a primitive,
it's worse. Function calls may be relatively cheap, but on
a card capable of 1000000 triangles a second throughput,
even a single wasted clock per call is a noticable chunk
of CPU time - and indirect calls to a DLL take more than
a single clock...
>>Every extra useless OpenGL feature is, to me, just another
>>annoying piece of a driver that every IHV has to worry
>>about.
>
>Ok, will you give me $10,000 for every "useless"
>OpenGL feature that ends up in D3D?
Most of OpenGL is useless _at the moment_. When
commodity 3d hardware supports some of the more
esoteric functions *required* by OpenGL, that won't
be the case.
>You make think it's a knock against OpenGL, but GL's
>only competitor on the PC is clearly heading in that
>direction--no surprise, since the hardware itself is as
>well.
But it's not there yet. That's the problem.
[...]
>>I am arguing that driver size must be kept low to decrease
>>the amount of work that IHVs must perform. If they can't
>>handle even (relatively) simple DirectDraw and D3D
>>drivers, how can they POSSIBLY handle OpenGL ICDs?
>>
>>As much of the API implementation should be kept in an
>>OS DLL as possible. As little as possible should be put
>>into the driver.
>
>Why not put it all into a "generic driver" and give the source
>code to the IHVs? Then they can accelerate those portions of
>it that their hardware can accelerate, and yet not have to go
>through a layer.
Because you end up with a f**king huge version control
problem. D3D5 could use D3D3 drivers seamlessly. If
MS/SGI were to change the base source for the ICDs,
all the IHVs would have to incorporate those changes into
their modified versions. Major hassle.
---
Russ
Russ Williams
Sean T Barrett wrote in message ...
>>>ICD should always win on performance.
>>
>>The fact that there needs to be 'an easy way' for IHVs
>>suggests (to me, at least) that there's something wrong
>>with the API/driver model.
>
>extreme flexibility and extremely high performance, you
>need a very very large amount of code between the app
>and the hardware--i.e. you want the driver to implement
>the API "directly".
Actually, I'd say you want f**k-all code between the
app and the hardware. The driver layer should be as
thin as possible. I agree that it should implement the
API directly, though.
The API should provide a simple method for doing
things like drawing textured tris/quads and the driver
should only need to parse a few glFoo calls or a
single structure (better, IMO, but not too relevant).
Everything else should be optional.
If OpenGL drivers could have been written so that only
glBegin, glColor, glVertex, glTexCoord and glEnd were
needed, then D3D wouldn't have stood a chance.
>Saying "MCD is crippled" is about like saying "DX5 D3D
>is crippled"--and that's ignoring the fact that the OpenGL
>supports a broader, more useful API.
"More useful"... isn't... at the moment.
>The direction we are going is towards hardware that
>does support all the stuff OpenGL has had (i.e. that
>D3D is adding).
Yup. D3D is keeping up with the hardware.
>When that hardware supports everything, you'll need
>an API with the breadth of OpenGL.
Agreed. OpenGL's problem is that the functionality is
*required*. When D3D is expanded to the same
breadth, it will still offer a choice of whether things are
supported or not. It's a fundamental difference in the
philosophy.
>If you want maximal performance, you want that layer as
>thin as possible. OpenGL ICDs are like that. D3D's
>execute buffers were a flawed attempt at being like that.
True. D3D is as thin as ICDs, AIUI, but it doesn't have the
potential for geometry hardware (yet).
>If you and Dave Springer feel obliged to continue to
>assault OpenGL, please stop with the "but there are
>no drivers because OpenGL drivers are too hard to
>write"
Are you saying that's not the case?
>(gee, do you perhaps recall a time when MS _killed_
>Win95 MCD support out from under IHV's)
Yes. A couple of points:
i) Read the message from Paul Maritz (?) that StJohn
posted to restart this thread. Apparently, _SGI_
wanted MCDs canned.
ii) MCD performance is shite. If anything, pulling MCDs
might have saved OpenGL on the PC by removing
a whole load of crap drivers. There would have been
little incentive for IHVs to write ICDs if MCDs hadn't
been pulled from 95.
>and "if it has two different driver models it must be bad".
You don't consider that IHVs needing to block-copy
ICD code to be a remarkable waste of time?
Dare I say it? OpenGL is too bloated for current consumer
3d hardware.
---
Russ
Rob Rodgers
"Russ Williams" <ru...@algorithm.demon.co.uk> wrote:
>Relatively high performance. ICDs are no faster than D3D
>drivers on the vast majority of 3d cards. The ICD model
>imposes a big penalty with all those function calls.
The ICD model also lets the vendor optimize the activity of the
functions to their heart's content.
On the other hand, and this is the major problem, most vendors don't.
> Sure,
>you can use vertex arrays instead of glVertex, but when
>you compare that to D3D's one function call for a primitive,
>it's worse.
Uh, how? The sgGeoset node in y OpenGL-based scene graph draws an
entire triangle *strip* with a *single* function call (and the strip
is indexed, so vertex caching can reduct the avg vert/triangle down
below one).
>Most of OpenGL is useless _at the moment_. When
>commodity 3d hardware supports some of the more
>esoteric functions *required* by OpenGL, that won't
>be the case.
Actually, most of what's slow in OpenGL is worthless cruft that nobody
will ever use. All of the framebuffer functions are hideously slow on
what's out there and will be for the forseeable future. The
gluQuadrics are slow for realtime bt perfctly fast when display
listed. Display lists aren't a win or a loss but are simple to use.
Having a texture stack is both convenient and not a performance
penalty.
What did you have in mind when you mentioned "esoteric functions"?
Stenciling? If so, you'd better talk to MS about Direct3d 6.0.
>Because you end up with a f**king huge version control
>problem. D3D5 could use D3D3 drivers seamlessly. If
>MS/SGI were to change the base source for the ICDs,
>all the IHVs would have to incorporate those changes into
>their modified versions. Major hassle.
The bigger problem is that ICDs aren't modular. They're going to have
to ship and QA seperate drivers when the 3dNow! chips start coming
out.
Chris Hecker
gl...@bullfrog.notanemaladdress (Glenn Corpes) writes:
> Surely the fact that there is a stable D3D driver for every 3D chip
> while non-miniGL drivers are thin on the ground to say the least says
> something about the driver models?
Come on Glenn, you know the first-order effect there is that IHVs only
got started on OpenGL drivers relatively recently compared to D3D
drivers (and Microsoft only very recently stopped actively
discouraging IHVs from doing OpenGL drivers). There are definitely
differences between the driver models that it's possible to have a
pleasant technical discussion about (if such a thing is possible in
this newsgroup :), but they're second- or third-order effects compared
to the politics of the past couple years.
>One of D3D's strengths is that it allows access to hardware with non
>readable surfaces, for example the PowerVR's z-buffer, it will also work
>with future hardware with non readable screen RAM, AIUI openGL supposedly
>has to provide read access to this stuff, which is strange when you
>consider that QuakeII runs fine on PowerVR, this is because their driver
Support for scene-based rendering hardware is definitely one place
where OpenGL was weak. There is an extension that supports this,
however, which was developed jointly by a number of IHVs. I don't
recall if it made it into 1.2 or not.
Chris
Chris Hecker
rsro...@wam.umd.edu (Rob Rodgers) writes:
>This is secondary. By checking the hardware caps you can do a quick,
>non-distracting first-pass cull of features that are _likely_ to cause
>a slowdown. You can then build up from there.
>The alternative is to test.. Let's see, how many possible combinations
>are there for OpenGL? Two to the, what, tenth? fifteenth?
Hmm, I'd think performance would be primary (especially since you're
using HW as an estimate of whether the feature would be fast, while
knowing for sure would clearly be superior if it was free to figure
out).
Anyway, if we're going to actually talk about scalability and how APIs
should reveal the capabilities of the underlying hardware, let's move
to another thread, and let's keep it technical instead of inflamatory
(unless your game's renderer really is going to be able to use the
2^whatever states so you'd have to time them).
I think there are advantages and disadvantages to the way OpenGL and
D3D handle this problem. If we can actually keep the discussion
technical (in another thread) I'd be happy to discuss them.
Chris
Chris Hecker
Wow, I just meant to correct some technical nonsense Alex posted. I
didn't mean to have this thing flare up again.
nos...@jet.es (Javier Arevalo) writes:
>Think about this for a minute: if the D3D advocates like myself made
>as much noise comparably to what OpenGL advocates like yourself, what
>do you think would happen?
I'm going to state the obvious, but I think it answers the question of
why more people don't complain:
I believe (based on talking to hundreds of professional developers)
that if OpenGL and D3D suddenly had equal driver-support, everyone
(well, over 95%) would switch overnight. I think you posted something
agreeing with this, so I'll assume you agree (if not, the rest of my
paragraph isn't going to be very convincing ;). Now, from that group
you get the smaller number who care enough to speak about it in
public. And from that smaller group, you get an even smaller group
that are willing to spend their time doing something about it. This
is human nature, and shouldn't surprise anybody...look at the low
percentages of voter turnout (which doesn't even cost much time or any
money compared to supporting the underdog API).
So, in answer to your question, if Microsoft picked OpenGL there
simply wouldn't be any Direct3D advocates (well, okay, this is usenet,
you can find people who'll advocate anything...I mean professional
developers). There are a small number of vocal OpenGL advocates
because there are a large number of people who would rather use it.
The same is not true of Direct3D; people use it because it's there and
supported while OpenGL is not, yet. Those are fine and defensible
reasons, but they're simply pragmatic and don't foster any advocacy.
Now, hopefully the interesting parts of this thread (like scalability
and driver models) will calve off and this one will die. If we're
lucky. :)
Chris
Chris Hecker
"Russ Williams" <ru...@algorithm.demon.co.uk> writes:
>Relatively high performance. ICDs are no faster than D3D
>drivers on the vast majority of 3d cards. The ICD model
>you can use vertex arrays instead of glVertex, but when
>you compare that to D3D's one function call for a primitive,
>it's worse.
Huh? You can submit data to OpenGL just as efficiently as to
Direct3D, and in fact more efficiently in most cases. OpenGL's data
flow is a superset of Direct3D's, so this is provably the case, end of
discussion.
The real discussion is about monolithic drivers versus layered
drivers. There are well known advantages and disadvantages to both.
Some of those advantages and disadvantages are provably true and some
are just conventional wisdom (and not necessarily true).
Sadly, even when "driver models" were the de rigueur response to
OpenGL from Microsoft, there was never a good technical discussion of
these advantages and disadvantages. It is not at all clear to me (and
I've debugged more than my share of bad display drivers while I was at
Microsoft and thought about this issue a lot) that a monolithic model
_has_ to be more error prone than a layered model, while it seems
clear that monolithic models have the performance advantage and the
flexibility advantage. We could do something completely revolutionary
and actually have a measured technical discussion about this right
here in this group, if anybody's actually interested in that sort of
thing anymore.
> MCD performance sucks
This actually didn't have to be the case. In fact, I believe
Rendition had their MCD outperforming their D3D drivers pretty early
on. MCD may have had problems, but the fact that it was killed did
more to make people not optimize it than anything inherent in the
model.
Chris
Rob Rodgers
che...@netcom.com (Chris Hecker) wrote:
>rsro...@wam.umd.edu (Rob Rodgers) writes:
>>This is secondary. By checking the hardware caps you can do a quick,
>>non-distracting first-pass cull of features that are _likely_ to cause
>>a slowdown. You can then build up from there.
>>The alternative is to test.. Let's see, how many possible combinations
>>are there for OpenGL? Two to the, what, tenth? fifteenth?
>
>Hmm, I'd think performance would be primary (especially since you're
Performance of the rendering profiler counts, too. I don't want to
wait three minutes to do a fair estimate of performance (who knows
what other tasks are doing) and find an ideal rendering setting every
time I install an app. That kind of profiling should have been placed
into the API in the first place (isfast on a practical scale).
R. Jason Sams
>$2K to $100 in a year? Computers move fast, but not that fast.
You should see at least one consumer card with geomitry acceleration this
summer in the under $200 range.
>Why can't D3D (in theory) handle geometry? It should be a matter of
>allowing the driver to take LVERTEX (or whatever they're doing with FVF
>now) and have the matrices set inside the driver.
You can in theory add any feature you want. The point being it is in a
continual state of flux. Writing a game for directX is aiming for a moving
target.
>This would allow drivers to ignore geometry and pass it off to MS if
>they feel like it, and if they had acceleration, they would be able
>to receive untransformed data.
There are ways to do this in an OpenGL driver. Unfortinatly the MS models
make it difficuly to impossible.
>If a card does not support geometry, it should not be forced into
>having an implementation of it!
It has to be done somewhere. In many cases it is more efficient to do it in
the card driver than in an OS layer. I will explan some more latter.
>Explain why they're not released yet. There's been PLENTY of time, and
>SGI's base code supposedly made it possible to make a rasterization-
>accelerating driver in just 6 weeks.
My guess is that with a proper code base it would take more like 6 months to
produce an acceptable driver. This will vary with the level of experience
of the team.
>You really think they're going to go through all of it and optimize it?
>Do they really want to deal with the possible testing complications of
>that? Hint: \windows\system\opengl32.dll is 733,296 bytes, opengl.dll
>1,214,464 bytes, and the full OpenGL for Rendition (alpha) is 819,712
>bytes. That's a lot to optimize. The best approach is to allow the
>IHVs to entirely ignore the parts of the API they have no ability to
>natively optimize. If MS or SGI gets to optimize the rest of it, the
>end result will probably be better than the IHV's optimization attempts,
>since it will be focused on all the emulation paths.
The bulk of that code is non critical paths (for games). There is little
need optimize the feedback or selection paths. The accumulation buffer code
would most likely be considered a low priority for optimization.
However, ICD offer one area of optimization than an MCD or DirectX driver do
not offer. OpenGL is an implementation agnostic API. This mean the driver
is free to manipulate the data paths any way it wants to achieve the optimal
performance. The driver can make decisions on how to store textures in
memory. This allows the driver to take advantage of any compression of DME
features a card might have. OpenGL does not restrict the internal Z buffer
formats. This allows a card to implement other types of depth buffers such
as floating point implementations.
Once geomitry acceleration becomes common more optimization options open up.
A big win then becomes vertex arrays. Pieces of geomitry can be sent to the
card once, then following drawing operation need only send a matrix
describing the position of the object. This greatly reduces both the CPU
and bus load. ( I do not know the time frame for cards with this ability. )
Another option is partial acceleration of render states. With OpenGL it is
possible to partially accelerate a feature. This can occur when the
hardware cannot directly support the feature, but it can be faked while
still taking advantage of some acceleration. I beleive the PCX2 driver does
some of this for Quake2.
An ICD model provides the IHV the ability to make the most of their
hardware. It is not the easiest way to develop the driver, but it has the
potiental to lead to the most efficient.
>The problem is that you're not developing a driver for your card.
>You're developing a driver for a _platform_. The only thing in common
>between many of the computers you will be targeting is the OS. It's
>possible for SGI to optimize their OpenGL for a specific model (O2,
>say). That's because it's _one computer_!
When you do optimizations you have to make assumptions on the hardware you
will run on. The most important factors here are the CPU, system bus, and
memory. Today you assume the CPU is a PII (No offense to AMD). Depending
of the driver you may need to make some assumptions on the but (66 vs
100mhz) and memory is pretty much standard (32+mb).
>I haven't written a line of driver code, but I've used both APIs.
>However, I can put forth a very clear scenario in which it is better to
>have at least a somewhat indirect implementation.
>
>For cards that don't have a geometry processor, geometry must be done
>on the processor. Soon, the K6-2 will be released, and it will be
>capable of heavily improving performance of CPU geometry. So what will
>happen to drivers when it comes out? There are several cases.
>
>1. The API has a module that handles geometry, passing the results on
> to the driver. In this case, the OS vendor simply needs to replace
> that one module with a new module that has K6-2-accelerated code.
> No new drivers. No new driver bugs. Low dev costs. (this is the
> D3D position)
Two assumptions here. One is that MS can write optimized code. I would
rather take chances on any IHV over them. The IHV have a stake in writing
efficient code while MS does not. Regardless of how efficient the API or
driver is their OS sales will not change. The second is that it is
difficult to add processor specific geomitry code to a GL driver, it is not.
My guess is a week or less given the proper tools.
>2. Drivers are direct API implementations, all built off the same base
> code. In this case, whoever made the base code must change it to
> handle the K6-2. This is not a problem, but it is a problem to
> merge the updated code back into all the drivers. This increases
> development costs (merging is not necessarily easy), makes new
> drivers _necessary_, and runs the risk of new bugs to annoy users.
> (this is the ICD position)
You run the risk of adding new bugs regardless if it is the OS layer
(Microsoft) or the driver (IHV) adding them. Here again I have some more
faith in the IHVs because you can switch to another IHV, but you are pretty
much stuck with the OS.
>3. Drivers are direct API implementations, not from the same base code,
> or with heavily modified base code. In this case, it will be a huge
> pain to add anything. This will make it the hardest. (this is a
> possible result of ICD if IHVs try to optimize too much)
No, this is completly wrong. In the driver I am working on the time
critical portion of the code is all in one file. Its less than 10k of
source. Making changes or optimization to that file is not difficult. All
I would need is a instruction set spec (3Dnow or Katami), a compiler that
would support it, and about a week.
>As Russ mentioned, it is also a good thing that DX5 can still use DX3
>drivers. Sure, the performance isn't the best, but at least it works.
>It also means that users don't need to wait until drivers are out
>before using the new API. Developers can use the API immediately, and
>as drivers are released, the performance will improve.
If you don't need to change the API every year to keep up with the hardware
then backwards compatibility is not as important. This is a side effect of
DirectX not having all of the features we want from the start. DirectX has
gone through 5 versions in the same time OpenGL has gone through one. It
still does not have the same feature set as GL. This means you would have
to write 5 DirectX drivers for every one GL driver.
>I still don't see any OpenGL 1.2 drivers, much less OpenGL 1.1 drivers.
>I see this as evidence that SOMETHING is preventing the drivers from
>being developed and released. Without inside information, I cannot be
>sure, but I would guess that the problem is that OpenGL is bloated and
>that IHVs are _required_ to use ICD.
1.2 is less than two months old. Every popular card has a publicly
available 1.1 driver. They are not all complete, but most work (to varying
degrees). This is a partially a result of Microsoft's obstruction tactics.
They have done almost everything possible to delay OpenGL drivers. This has
only recently stoped.
R. Jason Sams
David Springer
Thomas Womack (mert...@sable.ox.ac.uk) wrote:
>
> There are STB drivers dated around 15 April 1998 available on their
> web site, which produce pretty impressive OpenGL on my friend's Dell
> Dimension.
>
Well I'll be damned. It's on Dell's website in the support library
too. Placed there less than 10 days ago. Not bad. Only 8 months
behind the D3D drivers...
David Springer
Jon Leech
In article <checkerE...@netcom.com>,
Chris Hecker <che...@netcom.com> wrote:
>Support for scene-based rendering hardware is definitely one place
>where OpenGL was weak. There is an extension that supports this,
>however, which was developed jointly by a number of IHVs. I don't
>recall if it made it into 1.2 or not.
It did not. Such limited information as I've seen on next-generation
region-based architectures (NEC, Gigapixel, Raycer, S3) suggests that
they're mostly wrapping the weirdnessesdown of the architectures to where
it's no longer visible at the API level.
The PowerVR talk I went to at CGDC was interesting; they looped over the
set of problematic features (framebuffer readbacks, fancy blending modes,
etc.) saying for each one
"Here's feature X. It isn't supported in the current PowerVR
hardware. You shouldn't use it anyway, because <various
rationalizations inserted here, like ``you don't need it'' or ``it
looks bad''>. However, feature X is supported perfectly in the
next-generation hardware."
Jon Leech
Silicon Graphics
Matt Craighead
R. Jason Sams wrote:
> >Oh, I really want and need feedback. (not!)
> >
> >piece of a driver that every IHV has to worry about.
>
> someone else wont. I want motion blur(accum buffer), realistic shadows
> (stencil buffer), and water effects (texture matrix). Now these are just a
> few uses I can think of. I am sure there are others. This reminds me of
> the old argument that memory protection just slowed things down. That
> Windows was just a useless GUI and dos was fine.
I'm not arguing that accumulation/stencil/texture matrix effects are
useless. They're quite useful, in fact. I'm arguing something else.
I'm arguing that if hardware doesn't support accumulation, then the
IHV guys should not have to concern themselves with it. The same for
stencil buffers and texture matrices. In general, hardware doesn't
support those right now. So, the solution is one of two things.
1. The API does not require emulation paths, and so the drivers can
just ignore, say, stencil render states if it's not supported.
This is ideal for markets where features must be cut to keep the
price target in reach (consumer, games).
2. The API does require emulation paths, but an interface exists
between it and the hardware so that the drivers do not need to
implement features they will only be able to emulate. This is the
best for markets where supporting all the features is essential,
even if the price has to go up (professional, CAD and such).
Note that DX6 supports stenciling. Why now and not before? Well, it
is in the next year that the top consumer hardware is aiming for
stenciling as a key feature (Riva TNT and all).
> >OpenGL is too big -- certainly far too big for a "raw implementation"
> >driver model!
>
> No its not. There is hardware like the Glint Gamma that bennifets greatly
> from this model. What you are really arguing is that consumer hardware does
> not currently bennifet. As these cards currently in the 2K price range
> become consumer level soon (next year?) this model will help.
$2K to $100 in a year? Computers move fast, but not that fast.
When comsumer hardware has geometry, it should be trivial for D3D to
support it.
> >Total BS. ICD is a _worthless_ driver model! D3D has a real driver
> >model. Execute buffers were wrong, yes, but I no longer concern
> >myself with execute buffers. They are irrelevant to me. Only DP is
> >relevant, and soon only DX6 and its vertex buffers and such will be
> >relevant (as soon as that CD arrives). The layer should minimize
> >driver development costs, not be as thin as possible. An extra call
> >statement is nothing compared to the cost of transforming, lighting,
> >clipping, and batching 1000 triangles.
>
> See above. Please talk to some of the hardware people before you make these
> statements. If you are not in driver development please do not profess to
> be an expert on the subject. OpenGL is an API not a driver model. MCD and
> ICD are Microsoft attempts at a driver model to implement the API. Each has
> advantages and disadvantages. I personally would like to see a replacement
> for the MCD model. However, ICD are the wave of the future, esspically as
> gemoitry acceleration becomes common.
Why can't D3D (in theory) handle geometry? It should be a matter of
allowing the driver to take LVERTEX (or whatever they're doing with FVF
now) and have the matrices set inside the driver.
This would allow drivers to ignore geometry and pass it off to MS if
they feel like it, and if they had acceleration, they would be able
to receive untransformed data.
If a card does not support geometry, it should not be forced into
having an implementation of it!
> >I am arguing that ICD is, from a technical standpoint, ABSOLUTELY
> >TERRIBLE. I am arguing that driver size must be kept low to decrease
> >the amount of work that IHVs must perform. If they can't handle even
> >(relatively) simple DirectDraw and D3D drivers, how can they POSSIBLY
> >handle OpenGL ICDs?
>
> Since I develop OpenGL drivers I can say you are wrong. ICD are not
> terrible, and yes we can handle our jobs just fine.
Explain why they're not released yet. There's been PLENTY of time, and
SGI's base code supposedly made it possible to make a rasterization-
accelerating driver in just 6 weeks.
> >As much of the API implementation should be kept in an OS DLL as
> >possible. As little as possible should be put into the driver.
>
> Only if you want to forever be limited by what MS will provide you in that
> DLL.
They're doing a pretty good job at it.
> >I am arguing the inherent properties of ICD and saying they SUCK.
>
> Please make yor arguments form a technical standpoint. Why does giving the
> IHV the ability to implement an API as efficiently as possible on their
> hardware suck? Sure there will be IHV that screw up, but that is nothing
> new or limited to an ICD.
You really think they're going to go through all of it and optimize it?
Do they really want to deal with the possible testing complications of
that? Hint: \windows\system\opengl32.dll is 733,296 bytes, opengl.dll
1,214,464 bytes, and the full OpenGL for Rendition (alpha) is 819,712
bytes. That's a lot to optimize. The best approach is to allow the
IHVs to entirely ignore the parts of the API they have no ability to
natively optimize. If MS or SGI gets to optimize the rest of it, the
end result will probably be better than the IHV's optimization attempts,
since it will be focused on all the emulation paths.
> >Direct API implementations are an absurd driver model for the PC.
> >They are suited for high-cost proprietary systems, on which the vendor
> >can actually afford the development and optimization for each one (so
> >SGIs are perfect targets for them). PCs? Try again.
>
> It does not take hundreds of people to write a driver. Less than six can do
> the job just fine, and I would argue that 2-3 is the optimal team size. I
> think an IHV can afford three good developers to write a driver.
The problem is that you're not developing a driver for your card.
You're developing a driver for a _platform_. The only thing in common
between many of the computers you will be targeting is the OS. It's
possible for SGI to optimize their OpenGL for a specific model (O2,
say). That's because it's _one computer_!
> >D3D's driver model is _technically superior_ to OpenGL ICD.
>
> Please refrain from this argument unless you have developed drivers for
> both. And hopefully used both APIs.
I haven't written a line of driver code, but I've used both APIs.
However, I can put forth a very clear scenario in which it is better to
have at least a somewhat indirect implementation.
For cards that don't have a geometry processor, geometry must be done
on the processor. Soon, the K6-2 will be released, and it will be
capable of heavily improving performance of CPU geometry. So what will
happen to drivers when it comes out? There are several cases.
1. The API has a module that handles geometry, passing the results on
to the driver. In this case, the OS vendor simply needs to replace
that one module with a new module that has K6-2-accelerated code.
No new drivers. No new driver bugs. Low dev costs. (this is the
D3D position)
2. Drivers are direct API implementations, all built off the same base
code. In this case, whoever made the base code must change it to
handle the K6-2. This is not a problem, but it is a problem to
merge the updated code back into all the drivers. This increases
development costs (merging is not necessarily easy), makes new
drivers _necessary_, and runs the risk of new bugs to annoy users.
(this is the ICD position)
3. Drivers are direct API implementations, not from the same base code,
or with heavily modified base code. In this case, it will be a huge
pain to add anything. This will make it the hardest. (this is a
possible result of ICD if IHVs try to optimize too much)
---
As Russ mentioned, it is also a good thing that DX5 can still use DX3
drivers. Sure, the performance isn't the best, but at least it works.
It also means that users don't need to wait until drivers are out
before using the new API. Developers can use the API immediately, and
as drivers are released, the performance will improve.
I still don't see any OpenGL 1.2 drivers, much less OpenGL 1.1 drivers.
I see this as evidence that SOMETHING is preventing the drivers from
being developed and released. Without inside information, I cannot be
sure, but I would guess that the problem is that OpenGL is bloated and
that IHVs are _required_ to use ICD.
--
Chris Hecker
Matt Craighead <crai...@citilink.com> writes:
>I'm arguing that if hardware doesn't support accumulation, then the
>IHV guys should not have to concern themselves with it. The same for
You could be saying one of two things here (if you're saying something
else, sorry about assuming, and post what you actually meant :): 1) HW
doesn't support it so the API shouldn't have it, or 2) HW doesn't
support it so the driver shouldn't have to do it. There are problems
with both:
#1 is shortsighted, especially when features are proven generally
useful by the test of time and they don't necessarily have to have HW
support. There are many cases where a useful feature is still useful
even if it's in software, and especially so if you're using the API
for both your tools and your runtime. All of our tools are in OpenGL,
and we can share rendering code with our runtime where it's
appropriate. This is very nice.
#2 ignores the case where you need to have intimate access with the
entire pipeline to make the feature work, and it also doesn't allow
for partial acceleration of the feature where possible. If you let
the driver hook as much as it wants, lots of times people will hook as
much as they can to get control and you're back where you started.
>Note that DX6 supports stenciling. Why now and not before? Well, it
>is in the next year that the top consumer hardware is aiming for
>stenciling as a key feature (Riva TNT and all).
I think the cause and effect here is slightly more complicated than
this. Had D3D had stenciling from the beginning I'd bet everybody
else would have had it sooner as well. I think, for better or for
worse, D3D drives a lot of HW design (which is why IHVs like OpenGL,
because it has extensions so they can differentiate). D3D didn't have
stencil because everyone thought stencil was for CAD, which gets back
to why didn't SGI educate people about why OpenGL was designed the way
it was, but let's not go there. :)
Chris
Phil Oliver
R. Jason Sams wrote in message <6jolbu$s88$1...@news7.ispnews.com>...
>You should see at least one consumer card with geomitry [sic]
> acceleration this summer in the under $200 range.
Look at the Permedia-2 based boards from Diamond and Creative Labs.
Geometry and 2d acceleration plus full, stable OpenGL drivers.
About $170 street for cards with 8 megs.
Jon Leech
In article <6jov27$eve$1...@bolivia.it.earthlink.net>,
Phil Oliver <ph...@NOSPAMpoboxes.net> wrote:
>R. Jason Sams wrote in message <6jolbu$s88$1...@news7.ispnews.com>...
>> acceleration this summer in the under $200 range.
>
>Geometry and 2d acceleration plus full, stable OpenGL drivers.
Permedia 2 only does triangle setup. Geometry processing is much more
complex.
Jon Leech
Silicon Graphics
Adam S.
Your original point was that one or two cards supporting OpenGL
doesn't constitute broad support. But don't you think that based
on insistence from developers to support OGL and now pressure from
competing cards who (as of 10 days ago :) provide it...
Don't you think there is now a stronger impetus among IHVs to provide
OpenGL support? Do you think this marketplace pressure will
result in the fruition of drivers, and if so what time scale?
Just curious.
--
A.
M-x rule-world
Javier Arevalo
"Phil Oliver" <ph...@NOSPAMpoboxes.net> wrote:
>>If it was just the API, OpenGL would be the winner, but the
>>API design is not my 1st priority, and I'm thankful it is not MS's
>>priority as well.
> What is your priority?
Support, support, support. Drivers, drivers, drivers. Consumer
hardware (ALL of it). Opportunity for evolution.
Greets
Javier Arevalo
http://web.jet.es/jare
change nospam to jare in the address to send email
Michael I. Gold
Juan Carlos 'JCAB' Arevalo Baeza wrote:
>
> On 15 May 98 10:00:49 GMT, gl...@bullfrog.notanemaladdress (Glenn
> Corpes) dignified this group by writing:
>
> >Correct, avoid writing to the screen with the processor at all costs.
>
> For a final product, yes, I agree. But it's nonsensical to disallow
> it just on the basis of a final-product reason. It's like not having a
> debugger because it slows your app down.
>
> Direct FB access is extremely convenient for debugging purposes.
Well, hell, if its for debugging you can use glReadPixels and
glDrawPixels to read/write the color and depth buffers. It doesn't have
to be fast, it just has to work so you can debug. There is no good
reason to expose the framebuffer directly just for debugging when
reasonable alternatives exist.
Michael I. Gold
> Best thing to ever happen to OpenGL's chances at being used in games.
> If the MCD model had stuck around, everyone woul dhave shipped MCDs,
> the SGI kit would never have happened, and OpenGL performance would
> have been terrible.
In fact a member of the Microsoft D3D team once said to me "The best
thing we could have done to kill OpenGL would have been to ship the MCD
kit for Win95."
I still have mixed feelings on this one. The MCD for i740 seems pretty
decent, so its not clear that the MCD model itself is terrible. It
seems like the intent of many IHV's was to write an MCD first to meet
the market demand, and write an ICD later when there was time enough to
do it right. In any case there is no doubt in my mind that for better
or worse, every shipping card would have a full MCD by now, had the
Win95 MCD support materialized.
Where then would have been the impetus to write an ICD?
1) Performance
2) Extensibility
3) Did I mention Performance?
The 3Dlabs ICD has excellent triangle rates, better than any MCD could
ever hope to achieve. (Too bad the Permedia2 has crappy fill
performance.)
Michael I. Gold
[Editor's note: everything stated below is the opinion of the author and
is not necessarily shared by his employer.]
Matt Craighead wrote:
>
> I'm arguing that if hardware doesn't support accumulation, then the
> IHV guys should not have to concern themselves with it. The same for
> stencil buffers and texture matrices. In general, hardware doesn't
> support those right now. So, the solution is one of two things.
Ironically, its _not_ necessary for IHV's to emulate accumulation
buffers. Since ICD pixel formats are merged with the software pixel
formats provided by Microsoft's opengl32.dll, the ICD doesn't need to
advertise accumulation buffer support. Any application which requests
accumulation will therefore select one of the software pixel formats
instead. Is this useful?
I think not. This is a decision I weighed when implementing the NVIDIA
driver. It turns out that accumulation buffer support is really easy,
and is somewhat orthogonal to supporting accelerated triangle
rasterization. So I left accumulation support in the driver. If you
are using accumulation to anti-alias a scene, you render it multiple
times with a "jitter". The rendering itself is still accelerated so the
total time to render an anti-aliased scene is a lot faster than a pure
software implementation. And if the application has a switch to
enable/disable anti-aliasing, you don't have to use pure software when
AA is disabled, nor do you have to switch between two different
contexts, one for anti-aliasing and one for fast rendering.
> 1. The API does not require emulation paths, and so the drivers can
> just ignore, say, stencil render states if it's not supported.
> This is ideal for markets where features must be cut to keep the
> price target in reach (consumer, games).
There you go, segmenting the market. I dunno, feedback I get indicates
that people _like_ developing content and testing / developing games on
the same machine. Many (most?) content development tools are written in
OpenGL, and take advantage of features in the API not currently employed
in games. And the programmer who writes tools _and_ works on the game
doesn't have to learn two API's which solve essentially the same
problem.
Then there's the short-sightedness of your argument. Last year everyone
was criticizing OpenGL for supporting stencil. Now stencil is part of
DX6 and consumer hardware is being built to support it. Gee, if you
started writing your title to use stencil last year, you could take
advantage of this year's new hardware features. Oh well, you can always
follow the market next year instead of leading this year.
> When comsumer hardware has geometry, it should be trivial for D3D to
> support it.
Haw! That's rich. Its only a total rewrite of the driver. And with
the current DX5 driver model, IHV's don't have any exposure to the
geometry pipeline so will have to learn that part of the business from
scratch. Fortunately, the OpenGL teams at your favorite IHV's have
experience with implementing geometry pipelines so can help their D3D
counterparts come up to speed.
> Why can't D3D (in theory) handle geometry? It should be a matter of
> allowing the driver to take LVERTEX (or whatever they're doing with FVF
> now) and have the matrices set inside the driver.
LVERTEX? You want to perform object-space lighting, and _then_ pass it
to the hardware for transformation? Egads, you might as well skip the
hardware front end by that point. No, this is not trivial stuff.
> This would allow drivers to ignore geometry and pass it off to MS if
> they feel like it, and if they had acceleration, they would be able
> to receive untransformed data.
>
> If a card does not support geometry, it should not be forced into
> having an implementation of it!
Except that owning the pipeline allows IHV's to innovate in ways that
cannot be done with the current D3D driver model. Case in point:
EXT_point_parameters. You could not implement such an extension in D3D
without having hooks into the geometry pipe. Oh never mind, D3D doesn't
have an extension mechanism anyway. Owning the geometry pipe allows you
to pass data to the hardware in whatever format you wish, rather than
the format some software guy in Redmond dictates.
> Explain why they're not released yet. There's been PLENTY of time, and
> SGI's base code supposedly made it possible to make a rasterization-
> accelerating driver in just 6 weeks.
I'd love to see the source of your "6 weeks" promise.
NVIDIA's ICD is released for Win95 and WinNT. There has been a
conformant beta for months prior to the release.
3DFx just released a new beta, which is reported to be conformant as
well.
That's the lion's share of the market for high-end cards.
> The problem is that you're not developing a driver for your card.
> You're developing a driver for a _platform_. The only thing in common
> between many of the computers you will be targeting is the OS. It's
> possible for SGI to optimize their OpenGL for a specific model (O2,
> say). That's because it's _one computer_!
I don't follow this argument.
There are three configurations which must be supported today for most
IHV's. Win9x PCI, Win9x AGP, and WinNT PCI. Between these three, 99%
of the code is common. Its one port, not many. Furthermore, most of
the difficult part of bringing up an ICD is platform independent. This
driver can be the basis for drivers for the next generation hardare, as
well as ports to Linux, etc. I can guarantee you that RIVA TNT will
have a full OpenGL driver the day it ships.
> > >D3D's driver model is _technically superior_ to OpenGL ICD.
[snip]
> I haven't written a line of driver code, but I've used both APIs.
Go write a few drivers and then get back to us. We're talking about
driver models, right?
> For cards that don't have a geometry processor, geometry must be done
> on the processor. Soon, the K6-2 will be released, and it will be
> capable of heavily improving performance of CPU geometry. So what will
> happen to drivers when it comes out? There are several cases.
>
> 1. The API has a module that handles geometry, passing the results on
> to the driver. In this case, the OS vendor simply needs to replace
> that one module with a new module that has K6-2-accelerated code.
> No new drivers. No new driver bugs. Low dev costs. (this is the
> D3D position)
And likely the OpenGL position as well.
> 3. Drivers are direct API implementations, not from the same base code,
> or with heavily modified base code. In this case, it will be a huge
> pain to add anything. This will make it the hardest. (this is a
> possible result of ICD if IHVs try to optimize too much)
A wise man one told me, "there's not much sense in optimizing code that
isn't executed millions of times". The bulk of the driver is going to
be written in C, for both API's. The performance-sensitive parts may or
may not be written in assembly, depending on the implementation. These
are generally isolated pieces of code (e.g. xform a batch of vertices)
that can be easily patched for various ISA's. There only difference
between the two API's in this regard is that Microsoft will provide one,
and the IHV will provide the other.
> As Russ mentioned, it is also a good thing that DX5 can still use DX3
> drivers. Sure, the performance isn't the best, but at least it works.
> It also means that users don't need to wait until drivers are out
> before using the new API. Developers can use the API immediately, and
> as drivers are released, the performance will improve.
That's neat. You can also use MCD's today, and when the ICD's are
released, the performance will improve.
> I still don't see any OpenGL 1.2 drivers, much less OpenGL 1.1 drivers.
Probably because the spec for OpenGL 1.2 was only recently finalized.
> I see this as evidence that SOMETHING is preventing the drivers from
> being developed and released. Without inside information, I cannot be
> sure, but I would guess that the problem is that OpenGL is bloated and
> that IHVs are _required_ to use ICD.
Sadly, some IHV's wasted a lot of time and effort developing MCD's which
were obsoleted by Microsoft's "Meltdown Surprise". Then they tried to
fill the gap by developing QuakeGL drivers to meet the immediate market
demand. These two false starts were a significant timesink.
Fortunately NVIDIA never went the mini-driver route, and is now the
first to market with a full ICD for Win95 and WinNT (aside from 3Dlabs,
who have done OpenGL for years). It seems they have all gotten the
message though, and AFAIK nobody is continuing to enhance their QuakeGL
driver.
I can't speak for the competition, but personally I am quite pleased
with the flexibility afforded by the ICD model, and the starter code
from SGI.
[Editor's note: everything stated above is the opinion of the author and
is not necessarily shared by his employer. Then again, maybe it is.]