D3D disappoints again (D3D 'setup' in DX6)
Angus Dorbie
According to WAVE Report on Digital Media #728
(wa...@fourthwave.com) it looks like the much
anticipated DirectX 6.0 release will not include D3D
support for transformation and lighting calculations
(a.k.a. Setup) slated as a potential improvement
in the aforementioned release.
As a result, HW accelerators supporting D3D will
not be able to accelerate geometry processing when
using that API forcing applications to waste
valuable CPU time on this stage of rendering.
In stark contrast OpenGL Installable Client Drivers
can facilitate geometry acceleration. This is a
pressing requirement as low end card designs are
beginning to incorporate low cost parts to accelerate
geometry processing. It may yet transpire that
Microsofts move to drop MCD support for Windows 95
will have inadvertantly helped OpenGL by forcing some
IHVs to develop OpenGL Installable Client Drivers.
This setback for D3D is disapointing for IHVs and
ISVs using D3D given Microsofts pledge of bestowing
further technological advances on the industry at
a recent Meltdown conference. The reality is that
D3D in DX6 will still trail the API technology
curve by a long way, and Microsofts failure to deliver
on basic features like geometry acceleration does not
bode well for their API catchup strategy.
Cheers,Angus.
Angus Dorbie
Carl Mueller wrote:
>
> Angus Dorbie <dorbie...@asd.sgi.com> wrote:
> >[...] it looks like the much
> >anticipated DirectX 6.0 release will not include D3D
> >support for transformation and lighting calculations
> >(a.k.a. Setup) slated as a potential improvement
> >in the aforementioned release.
>
> transformation and lighting calculations. Setup is something
> different. Setup is the next phase, wherein the transformed and
> lit vertices are converted into whatever format the rasterizer
> needs to start producing pixels. The exact process varies
> depending upon the rasterizer hardware.
Thanks for the correction. I've been hearing the whole
front end processing stage called "setup" in some circles
hence I misused it here. Personally I'm used to using
"geometry processing" to incluge model transformation,
projection, lighting, backface culling and clipping.
Cheers,Angus.
Carl Mueller
Angus Dorbie <dorbie...@asd.sgi.com> wrote:
>[...] it looks like the much
>anticipated DirectX 6.0 release will not include D3D
>support for transformation and lighting calculations
>(a.k.a. Setup) slated as a potential improvement
>in the aforementioned release.
No no no, it's not called "Setup". It's called geometric
transformation and lighting calculations. Setup is something
different. Setup is the next phase, wherein the transformed and
lit vertices are converted into whatever format the rasterizer
needs to start producing pixels. The exact process varies
depending upon the rasterizer hardware.
>In stark contrast OpenGL Installable Client Drivers
>can facilitate geometry acceleration. This is a
>pressing requirement as low end card designs are
>beginning to incorporate low cost parts to accelerate
>geometry processing.
Which card designs?
The only ones I'm aware of are those that include the 3DLabs Gamma
chip, and these cards aren't cheap (yet). I also remember some
annoucement of another (Japanese?) company that also introduced a
geometry chip, but I haven't heard of any products using it.
Not that I'm disagreeing with your basic points.
Angus Dorbie
Jak Crow wrote:
>
> On Wed, 22 Oct 1997 21:34:39 -0700, Angus Dorbie
> <dorbie...@asd.sgi.com> wrote:
>
> >According to WAVE Report on Digital Media #728
> >anticipated DirectX 6.0 release will not include D3D
> >support for transformation and lighting calculations
> >(a.k.a. Setup) slated as a potential improvement
> >in the aforementioned release.
>
> time. The hardware vendors really don't have anything out that can
> perform these features yet. And so far, doesn't it seem like the
> hardware doesn't and won't need it for a while? Besides, it isn't a
> good idea to design hardware around one software product, right?
>
It is a chicken an egg circular argument.
What you can say with certainty is that for
anyone interested in HW geometry processing at
whatever level, OpenGL or a proprietary interface
are now the only options.
If you look at where the low end HW is heading you'll
get a good indicator of what will makes sense in the
immediate future. Bear in mind that for lower end
cards you are likely talking about slower CPUs in
addition to upgrading installed systems, this makes
HW geometry more attractive.
Consider how you might use the CPU to improve scene
visibility processing or other application processing
while the GL card DMAs a display list, or between
much faster IM calls on HW with even a modest FIFO.
Cheers,Angus.
Per Burstrom
Carl Mueller wrote:
..........
> Which card designs?
>
> The only ones I'm aware of are those that include the 3DLabs Gamma
> chip, and these cards aren't cheap (yet). I also remember some
> annoucement of another (Japanese?) company that also introduced a
> geometry chip, but I haven't heard of any products using it.
>
Pinolite is the name of Fujitsu's geometry processor. And as far as
3DLabs Gamma concerns, I haven't seen any cards using it yet. Actually
there is no info about Gamma on 3DLabs web besides the old pressrelease.
One would think they're having trouble with finishing Gamma!
But what about AMD K6-3D, IDT C6+ and the new Cyrix "Cayenne" core (all
introduced at Microprocessor forum). Will there be any support in DX6
(and drivers for OpenGL) for them? Cyrix claims five times the
performance of a P2 when doing 3D.
/Per, Sweden
Gary Tarolli
Angus Dorbie wrote:
>
> According to WAVE Report on Digital Media #728
> (wa...@fourthwave.com) it looks like the much
> anticipated DirectX 6.0 release will not include D3D
> support for transformation and lighting calculations
> (a.k.a. Setup) slated as a potential improvement
> in the aforementioned release.
>
> not be able to accelerate geometry processing when
> using that API forcing applications to waste
> valuable CPU time on this stage of rendering.
You are correct, but as others have pointed out, it's
not that big of a deal. Very few PC chipsets support
hardware geometry processing (many are and will be
supporting setup, ie. gradient computations). Intel
CPUs are getting very very very fast, and you can get
quite good results, especially in games, with CPU
driven geometry. No doubt it would (or should) run
faster with hardware geometry, but I wouldn't say it's
a pressing need.
For CAD type applications, where you have millions of
small triangles and lots of lights, it would be good
to have hardware geometry exposed. But for entertainment
applications (aka. games), it's not that necessary.
A little assembly code in the transformation and lighting
stages can go a long way....
Angus Dorbie
...and does, but we're comparing apples with apples, you are
arguing that more geometry performance is possible but games
won't need it, only CAD in situations where there is
a geometry bottleneck.
For a reasonable number of polygons the geometry processing
is an onerous load on the CPU which could be spent
performing other tasks particularly on game class PCs which
have only one processor. The geometry burden is subtracted
from the resource available for application i/o and scene
description processing.
You could argue that geometry setup isn't cost effective
below some watershed where you might free the CPU but have
less effective 3D FP, it might still be a big win for most
applications but your benchmark will be lower for stuff
like CDRS, in anycase the premise is weak, FP dedicated
to 3D geometry processing is cheaper/more effective than
using a general purpose processor.
Simply reserving good geometry performance for CAD
applications is an very unconvincing argument.
CAD is synonomous with High End on the PC because
that's seems to be where $s get spent on more capable
cards, it also tends to be heavily geometry limited
but games have their own demands and good artists will
balance the geomtric complexity against available fill
performance. Microsoft (and Alex St John in particular)
originally labelled OpenGL as the CAD API for misguided
reasons, again because it is perceived as a high end
market instead of any sound technical rationale.
My background is in real-time visual simulation, this
is the market which is possibly closest to the demands
of real-time games and the geometry requirements are hefty,
in fact a lot of the optimisation effort is spent on
geometry oriented processing to enhance the scene
complexity even on relatively sparse databases
because the required frame rates tend to be high.
Scenes are always very non linear in their ballance of
geometry and fill performance even with large FIFOs,
but you can't easily exploit this even if present when
using the CPU, you'll always be heavily geometry limited
when drawing some portions of your scene with real databases.
This is in the context of high resolution procurement
specs and often high depth complexity, so fill limitations
are ever present, but we still need good geometry
performance. The problem doesn't go away simply because
you are fill limited on balance.
The benefits of significant CPU processing for scene graph
optimisations are also substantial, including traversals
which can serve to maximise fill performance and minimise
hardware state changes. All of this processing requires
compute resources and these are squandered without HW
acceleration.
Cheers,Angus.
David Springer
In rec.games.programmer Gary Tarolli <tar...@3dfx.com> wrote:
: You are correct, but as others have pointed out, it's
: not that big of a deal. Very few PC chipsets support
: hardware geometry processing (many are and will be
: supporting setup, ie. gradient computations). Intel
: CPUs are getting very very very fast, and you can get
: quite good results, especially in games, with CPU
: driven geometry. No doubt it would (or should) run
: faster with hardware geometry, but I wouldn't say it's
: a pressing need.
I think you left off a couple of "verys" in very very very
fast, Gary. :-)
300mhz Deschutes is shipping right now and these will very
quickly be available in flavors up to 450mhz. Intel won't
sit still while there's any high volume demand for more
MIPS and FLOPS in the baseline PC.
There's always a race between dedicated processors and x86
horsepower and usually the race in the low end is won by
the x86 while the higher profit margin high end can live
with the low volume dedicated processor solutions.
: For CAD type applications, where you have millions of
: small triangles and lots of lights, it would be good
: to have hardware geometry exposed. But for entertainment
: applications (aka. games), it's not that necessary.
: A little assembly code in the transformation and lighting
: stages can go a long way....
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 ******************
Angus Dorbie
Gary Tarolli wrote:
>
> Angus Dorbie wrote:
> >
> > > For CAD type applications, where you have millions of
> > > small triangles and lots of lights, it would be good
> > > to have hardware geometry exposed. But for entertainment
> > > applications (aka. games), it's not that necessary.
> > > A little assembly code in the transformation and lighting
> > > stages can go a long way....
> >
> > arguing that more geometry performance is possible but games
> > won't need it, only CAD in situations where there is
> > a geometry bottleneck.
>
>
> > For a reasonable number of polygons the geometry processing
> > is an onerous load on the CPU which could be spent
> > performing other tasks particularly on game class PCs which
> > have only one processor. The geometry burden is subtracted
> > from the resource available for application i/o and scene
> > description processing.
>
> find that in many cases much more time is spent doing
> other things...you could argue that scene description
> processing should go into hardware...
>
> > You could argue that geometry setup isn't cost effective
> > below some watershed where you might free the CPU but have
> > less effective 3D FP, it might still be a big win for most
> > applications but your benchmark will be lower for stuff
> > like CDRS, in anycase the premise is weak, FP dedicated
> > to 3D geometry processing is cheaper/more effective than
> > using a general purpose processor.
> > Simply reserving good geometry performance for CAD
> > applications is an very unconvincing argument.
> > is the market which is possibly closest to the demands
> > of real-time games and the geometry requirements are hefty,
> > in fact a lot of the optimisation effort is spent on
> > geometry oriented processing to enhance the scene
> > complexity even on relatively sparse databases
> > because the required frame rates tend to be high.
>
> entertainment. I find fill rate much more important than
> geometry requirements and that current CPUs can handle a
> reasonable polygon load.
>
> > Scenes are always very non linear in their ballance of
> > geometry and fill performance even with large FIFOs,
> > but you can't easily exploit this even if present when
> > using the CPU, you'll always be heavily geometry limited
> > when drawing some portions of your scene with real databases.
>
> apps can reduce polygon count for framerate.
As I've said elsewhere this is circular argument, it's not
a desirable thing, it's artists making do with what they have.
>.. Current Intel
> CPUs provide hundreds of thousands of sustained polygons/second
> in a game. My argument is not that you cannot get more with
> dedicated hardware, it is that you can get very good results
> without dedicated hardware.
>
> If by non linear you mean you get a few big polygons and
> then a lot of small ones, there are ways to handle this in
> hardware such that the hardware can overlap filling while the
> CPU is crunching the small polygons.
>
> This is an age old argument, going back to 1989 when I worked
> on Indigo Entry. Machines without geometry processing tend
> to cost less, yet require more CPU horsepower to handle heavy
> polygon loads. This is a tradeoff. Sometimes, if an app
> is CPU bound, it pays to throw all the money at the CPU
> and do the geometry processing there (offloading 10% of the CPU
> workload won't do much). Different machines are good at
> different workloads. I believe graphics without geometry
> are still valid contendors for many workloads. Note, I did not
> say all.
I agree with most of this, the same topics do keep
getting revisited. I will say that geometry
acceleration will clearly wind up in hardware before
scene graph processing. And the distinction between
geometry in CPU vs HW certainly doesn't lie with games,
if anything games are a justification for HW geometry
acceleration. CAD on the other hand is much more likely
to better utilise CPU performance due to the typically
low overhead of scene processing at interactive frame
rates (until you start getting smart with an API like
optimizer). So let's not confuse the need for more
performance driving HW purchases with what's the
balanced thing to do for an application on limited
resources.
You say the HW can overlap filling while the CPU is
crunching, but to make this work well you need a large
FIFO and it doesn't help where you have large numbers
small polys. It's also hard for an application to exploit
the CPU during significantly fill limited portions of
the scene once the graphics blocks.
Cheers,Angus.
sumatose
In group rec.games.programmer, Steve says...
> Here's some quotes from Tom's HW page from his visit to the 'Microprocessor
> Forum 1997':
>
> After the introduction, which didn't really supply us with any new insights,
> Peter was going into 3D processing detail. As you all know, currently the
> FPU of the used microprocessor is of paramount importance for the 3D
> performance of a system, even if 3D accelerators are used. This is shown
> fairly extremely if you benchmark systems with 3D Winbench 97. Now Peter's
> opinion as well as mine is to move the FPU intensive geometry calculations
> from the main CPU to the graphic processor on the 3D accelerator. Peter says
> on slide 31 "Fundamentally, however, the CPU is the wrong place to do
> geometry processing." Now you can imagine that this is not exactly in the
> interest of Intel. The strong FPU of Intel CPUs is one reason why Intel CPUs
> are the best ones to use for 3D applications. If the FPU is losing its
> importance in 3D geometry processing, Intel's competitors would look much
> better in 3D applications than they do now.
That's a lot of crap. Intel's competitor have much better FPU
performance (PPC, ALPHA), this is irrelevant. Not everything in
this world comes down to a conspiracy, agent Mulder.
I'm sure the workstations of a few years ago benefitted greately
from a seperated cards handeling the 3D math. But today, the
CPUs are so fast, I can't see how a 3D card could outperform it
without being as expensive as the main CPU itself. There is a
lot of technology that goes in an intergrated CPU/FPU, the
catching, ect. Having your CPU basicly *waiting all the time*
for the 3D card to finish its stuff isn't something I'm not
looking forward to.
You may also be interested to know also that Cyrix is comming out
with a Dual FPU/Dual MMX CPU next year, if you insist on the
competitor arguement.
I don't see 3D performance getting better with a CPU upgrade as
being a problem. %-)
David Matiskella
Raist wrote:
> Jak Crow <fa...@devnull.com> wrote in article
> <344f0d5c...@nntp.best.com>...
> > On Wed, 22 Oct 1997 21:34:39 -0700, Angus Dorbie
> > <dorbie...@asd.sgi.com> wrote:
> >
> > >According to WAVE Report on Digital Media #728
> > >(wa...@fourthwave.com) it looks like the much
> > >anticipated DirectX 6.0 release will not include D3D
> > >support for transformation and lighting calculations
> > >(a.k.a. Setup) slated as a potential improvement
> > >in the aforementioned release.
> >
> > I think it's a bit blown out of proportion at this point in
> > time. The hardware vendors really don't have anything out that can
> > perform these features yet. And so far, doesn't it seem like the
> > hardware doesn't and won't need it for a while?
>
> Completely untrue. Permedia 2, NVIDIA 128 and even the Rendition can do
> this
> feat.
Not a single chip you mentioned does lighting or transformations. They
do triangle setup ( gradients for the edges). They don't do matrix
multiplication. There are a couple of compnies promising transformation and
lighting (3dlabs gamma chip pyrimad 3d come to mind) but I don't think they
are shipping yet. As you move away from just dumping triangle through a
rendering pipeline the advantages of hardware geometry aren't as great since
your processor is going to have to handle surface subdivision and the like
anyhow. I would much rather they spent the transistors adding stencil buffers
and multipass texturemapping. IMHO
--
David Matiskella
Howard Stroyan
Per Burstrom (per.bu...@esavionics.se) wrote:
: Carl Mueller wrote:
: ...........
: > Which card designs?
The new HP Kayak XW PC workstation includes a pair of geometry processors
on it's VISUALIZE Fx4 graphics card.
<http://hpcc923.external.hp.com/vectra/Products/kayak/graphics/Visualise_m.html>
--
Howard Stroyan (970)229-3317
Hewlett-Packard fax (970)229-6318
WSY Graphics Products Lab (GPL) hstr...@fc.hp.com
Gary Tarolli
Angus Dorbie wrote:
> You say the HW can overlap filling while the CPU is
> crunching, but to make this work well you need a large
> FIFO and it doesn't help where you have large numbers
> small polys. It's also hard for an application to exploit
> the CPU during significantly fill limited portions of
> the scene once the graphics blocks.
Our current 3Dfx hardware does quite well at this.
Obviously there's a limit, but we can hold either a
large portion of one frame, or multiple simple frames
in our fifos. The total retail cost of the hardware
(not just the fifos) is between $100 and $200 and
still dropping.
Obviously, once the gfx engine blocks, the CPU is sort
of stuck. But the trick is to not have the graphics
engine block very often. There are various ways to
do this.
sumatose
In group rec.games.programmer, Raist says...
> > time. The hardware vendors really don't have anything out that can
> > perform these features yet. And so far, doesn't it seem like the
> > hardware doesn't and won't need it for a while?
>
> Completely untrue. Permedia 2, NVIDIA 128 and even the Rendition can do
> this feat.
No They Do Not. You're the one lying.
THAT'S GEOMETRY _SETUP_.
Angus Dorbie
Jak Crow wrote:
>
> On 24 Oct 1997 01:45:22 GMT, "Raist" <rai...@mcs.com> wrote:
>
> >It is coming. PowerVR already has it. Rendition is about to release it.
> >We would all have had OpenGL already if M$ decided to support
> >it right from the beginning, a year and a half ago.
>
> This has been repeated before, but the performance of a MCD
> isn't going to cut it in Win95, and not because of of MS.
>
I think he's talking about the bigger picture, not the
relatively recent demise of MCD. Having spoken to some
of the victims who were affected by this decision it's
clear that the alledgedly poor MCD performance was not
the motivation.
You don't suddenly wake up and realise that the performance
you are getting from your MCD implementations is too slow.
The drivers had been in the pipeline for months with
IHVs waiting for the goahead. The MCD support would have
made a large direct impact on the availability of HW
accelerated OpenGL drivers and textured fill performance
in particular. The explanation of poor performance in Win95
just doesn't wash, it's ridiculous. What's doubly silly
is that to say this alledged slowness wasn't because of
Microsoft. You must have eaten a file of Microsoft press
releases for breakfast.
Cheers,Angus.
Angus Dorbie
David Matiskella wrote:
> > > On Wed, 22 Oct 1997 21:34:39 -0700, Angus Dorbie
> > > <dorbie...@asd.sgi.com> wrote:
> > >
> > > >According to WAVE Report on Digital Media #728
> > > >(wa...@fourthwave.com) it looks like the much
> > > >anticipated DirectX 6.0 release will not include D3D
> > > >support for transformation and lighting calculations
> > > >(a.k.a. Setup) slated as a potential improvement
> > > >in the aforementioned release.
> > >
> > > time. The hardware vendors really don't have anything out that can
> > > perform these features yet. And so far, doesn't it seem like the
> > > hardware doesn't and won't need it for a while?
> >
> > Completely untrue. Permedia 2, NVIDIA 128 and even the Rendition can do
> > this
> > feat.
>
> do triangle setup ( gradients for the edges). They don't do matrix
> multiplication. There are a couple of compnies promising transformation and
> lighting (3dlabs gamma chip pyrimad 3d come to mind) but I don't think they
> are shipping yet. As you move away from just dumping triangle through a
> rendering pipeline the advantages of hardware geometry aren't as great since
> your processor is going to have to handle surface subdivision and the like
> anyhow. I would much rather they spent the transistors adding stencil buffers
> and multipass texturemapping. IMHO
The cases being made for CPU based geometry processing are a little
wierd, here we have scene subdivision, presumably for parametric
surfaces or other higher order representation rendering, not that
people are moving away from more conventional approaches. I think
geometry acceleration is still a big win for real applications,
this has been true for years, it's simply more cost effective, the
CPU does less work even if it has other stuff to do. If the time
spent tesselating is this large in relation to geometry load then
there's probably something wrong with the approach.
Your need for stencil is interesting, OpenGL allows you to use stencil
buffers today, and low end hardware supports this, try the OpenGL
implementation on the Permedia 2 card for example. I've heard there
are also patents involved. At least some property is protected from
simply being copied by anyone playing catchup with another API.
Cheers,Angus.
Angus Dorbie
Again I agree, it's certainly desirable and possible
but it can be hard for an application to deal with and
the details vary across cards. It is still desirable
to send polygons to a modest FIFO in front of a geometry
engine than perform the geometry processing in the CPU.
Cheers,Angus.
Steve
Bugger! Looks like Intel got to 'em.
Jak Crow
>According to WAVE Report on Digital Media #728
>(wa...@fourthwave.com) it looks like the much
>anticipated DirectX 6.0 release will not include D3D
>support for transformation and lighting calculations
>(a.k.a. Setup) slated as a potential improvement
>in the aforementioned release.
I think it's a bit blown out of proportion at this point in
time. The hardware vendors really don't have anything out that can
perform these features yet. And so far, doesn't it seem like the
hardware doesn't and won't need it for a while? Besides, it isn't a
good idea to design hardware around one software product, right?
Jak
Email headers are false.
Please use:
jakcrow (at) werewolves (dot) org
Gary Tarolli
somewhat correct...
apps can reduce polygon count for framerate. Current Intel
David Springer
In rec.games.programmer Angus Dorbie <dorbie...@asd.sgi.com> wrote:
[incorrect rumors about DX6 clipped]
: In stark contrast OpenGL Installable Client Drivers
: can facilitate geometry acceleration. This is a
: pressing requirement as low end card designs are
: beginning to incorporate low cost parts to accelerate
: geometry processing. It may yet transpire that
: Microsofts move to drop MCD support for Windows 95
: will have inadvertantly helped OpenGL by forcing some
: IHVs to develop OpenGL Installable Client Drivers.
Unfortunately this is just wishful thinking as there's still
no indication that this massive driver development effort
by IHV's in pursuit of OpenGL ICDs for their products
is anything more than smoke and mirrors from SGI pundits.
It isn't true Angus that if you say something enough times
it will come true.
The check is STILL in the mail... and the mail is running
damned awful slow.
: This setback for D3D is disapointing for IHVs and
: ISVs using D3D given Microsofts pledge of bestowing
: further technological advances on the industry at
: a recent Meltdown conference. The reality is that
: D3D in DX6 will still trail the API technology
: curve by a long way, and Microsofts failure to deliver
: on basic features like geometry acceleration does not
: bode well for their API catchup strategy.
Setback ? What the HELL are you smoking ? D3D is deployed
and working fine on every card that makes any claim whatsoever
to 3D acceleration while OpenGL has no acceleration support
under Win95 for even the best of the best like Riva 128.
Anyone that made the reasonable decision to support D3D
with a game shipping this year can run on virtually every 3D
accelerator card imaginable while anyone unfortunate enough
to have picked OpenGL is sweating bullets.
Angus Dorbie
David Springer wrote:
>
> In rec.games.programmer Angus Dorbie <dorbie...@asd.sgi.com> wrote:
>
> [incorrect rumors about DX6 clipped]
This is misdirection, the information in thw wave
article and now from 3Dfx is that it's dropped
from DX6.
I think the information is accurate.
If you have a source of contrary information then
let's hear it.
>
> : In stark contrast OpenGL Installable Client Drivers
> : can facilitate geometry acceleration. This is a
> : pressing requirement as low end card designs are
> : beginning to incorporate low cost parts to accelerate
> : geometry processing. It may yet transpire that
> : Microsofts move to drop MCD support for Windows 95
> : will have inadvertantly helped OpenGL by forcing some
> : IHVs to develop OpenGL Installable Client Drivers.
>
> Unfortunately this is just wishful thinking as there's still
> no indication that this massive driver development effort
> by IHV's in pursuit of OpenGL ICDs for their products
> is anything more than smoke and mirrors from SGI pundits.
So, you haven't seen a 3Dlabs or 3Dfx based card recently?
This is a large share and it's not even the full picture, it
does however indicate that the wishfull thinking is yours.
>
> It isn't true Angus that if you say something enough times
> it will come true.
>
> The check is STILL in the mail... and the mail is running
> damned awful slow.
For many the check is already banked.
>........ D3D is deployed
> and working fine on every card that makes any claim whatsoever
> to 3D acceleration while OpenGL has no acceleration support
> under Win95 for even the best of the best like Riva 128.
> Anyone that made the reasonable decision to support D3D
> with a game shipping this year can run on virtually every 3D
> accelerator card imaginable while anyone unfortunate enough
> to have picked OpenGL is sweating bullets.
>
More fantasy, the choice of D3D severely restricts what one
is capable of achieving graphically, but then we've been
there and done that several times.
Cheers,Angus.
Steve
Here's some quotes from Tom's HW page from his visit to the 'Microprocessor
Forum 1997':
After the introduction, which didn't really supply us with any new insights,
Peter was going into 3D processing detail. As you all know, currently the
FPU of the used microprocessor is of paramount importance for the 3D
performance of a system, even if 3D accelerators are used. This is shown
fairly extremely if you benchmark systems with 3D Winbench 97. Now Peter's
opinion as well as mine is to move the FPU intensive geometry calculations
from the main CPU to the graphic processor on the 3D accelerator. Peter says
on slide 31 "Fundamentally, however, the CPU is the wrong place to do
geometry processing." Now you can imagine that this is not exactly in the
interest of Intel. The strong FPU of Intel CPUs is one reason why Intel CPUs
are the best ones to use for 3D applications. If the FPU is losing its
importance in 3D geometry processing, Intel's competitors would look much
better in 3D applications than they do now. One of the keys to the enabling
of 3D processors doing the work of geometry processing instead of the CPU
and hence supplying the FPU power needed for this topic is the 3D API that's
used, since it has to allow this kind of 'work load sharing'. The most
important 3D API today is Direct3D and this will most likely stay this way.
Microsoft is currently deciding if they want allow the shift of the geometry
processing from the CPU to the 3D chip whilst planning their next version of
DirectX, revision 6.0. Obviously the decision of Microsoft will take place
tomorrow, October 14th, and so far the favors seem to lie at not supporting
3D chips processing geometry instead of the CPU. This may be based on
Microsoft's close relationship to Intel, at least it doesn't seem too hard
to guess. I guess that most of you would prefer competitors of Intel to be
able performing well in 3D applications as well, particularly as it seems
possible. Peter Glaskowsky's words were "if you've got any influence on
Microsoft's decisions, please tell them to implement the 3D chip's geometry
processing support into Direct3D 6.0. The CPU shouldn't have to do this
calculations." I think I'm doing what I can to influence this decision as
good as I can by asking you to let Microsoft know what you think. If you
want to give non-Intel CPUs, that might have a weaker FPU, a chance in the
future, then let Microsoft know that you want them to implement the geometry
processing support of 3D chips.
Peter also shares my concerns about the insufficiency of the AGP
architecture. He demands that textures should be processes from the local
graphic memory, since the bandwidth of local graphic memory is still much
higher than what AGP offers. It's actually even worse than what you could
read in my 'AGP - The Theory', section 'Critical Thoughts'. Even with x4
mode (probably not available before 1999) there's one peculiar problem.
Whilst the AGP device can read from main memory with 512 MB/s (x2 mode) or
even 1 GB/s (x4 mode), the CPU can only write to the AGP device via a 66 MHz
PCI like technique, offering not more than 264 MB/s bandwidth. If the x2 or
x4 modes shall be used, the CPU would have to write the e.g. geometry data
first to main memory, let the AGP device know that it's there and then the
AGP device has to read it from main memory via the x2 or x4 mode. That is
obviously kind of crazy and jeopardizes the whole idea of the fast x2 or x4
modes.
Raist
Carl Mueller <mue...@cs.unc.edu> wrote in article
<62mppl$q...@watt.cs.unc.edu>...
> Angus Dorbie <dorbie...@asd.sgi.com> wrote:
[stuff deleted]
>
> >In stark contrast OpenGL Installable Client Drivers
> >can facilitate geometry acceleration. This is a
> >pressing requirement as low end card designs are
> >beginning to incorporate low cost parts to accelerate
> >geometry processing.
>
> Which card designs?
The NVIDIA Riva 128 chipset has reportedly an incredible geometry
processor.
But unfortunately for now looks like it is being toss away. Damn.
- Raist
>
> The only ones I'm aware of are those that include the 3DLabs Gamma
> chip, and these cards aren't cheap (yet). I also remember some
> annoucement of another (Japanese?) company that also introduced a
> geometry chip, but I haven't heard of any products using it.
>
Raist
David Springer <spri...@matrix.eden.com> wrote in article
<62odq1$83i$1...@boris.eden.com>...
> In rec.games.programmer Angus Dorbie <dorbie...@asd.sgi.com> wrote:
>
[stuff del]
>
> : This setback for D3D is disapointing for IHVs and
> : ISVs using D3D given Microsofts pledge of bestowing
> : further technological advances on the industry at
> : a recent Meltdown conference. The reality is that
> : D3D in DX6 will still trail the API technology
> : curve by a long way, and Microsofts failure to deliver
> : on basic features like geometry acceleration does not
> : bode well for their API catchup strategy.
>
> Setback ? What the HELL are you smoking ? D3D is deployed
> and working fine on every card that makes any claim whatsoever
> to 3D acceleration
Well, the problem is that no, it is not running fine.
> while OpenGL has no acceleration support
> under Win95 for even the best of the best like Riva 128.
It is coming. PowerVR already has it. Rendition is about to release it.
We would all have had OpenGL already if M$ decided to support
it right from the beginning, a year and a half ago.
> Anyone that made the reasonable decision to support D3D
> with a game shipping this year can run on virtually every 3D
> accelerator card imaginable while anyone unfortunate enough
> to have picked OpenGL is sweating bullets.
Id is surely not sweating bullets. Why? 3DFX has been widely
accepted and is among the very few to have enough performance to run
Quake decently.
>
> David Springer
> --
- Raist
Steve
sumatose wrote in message ...
>In group rec.games.programmer, Steve says...
>> Here's some quotes from Tom's HW page from his visit to the
'Microprocessor
>> Forum 1997':
[snip]
>That's a lot of crap. Intel's competitor have much better FPU
>performance (PPC, ALPHA), this is irrelevant. Not everything in
>this world comes down to a conspiracy, agent Mulder.
We're talking about DirectX 6 here. i.e. PC's. Workstations aren't really
even conmpetors. How many games do you play on your Alpha 21264?
>I'm sure the workstations of a few years ago benefitted greately
>from a seperated cards handeling the 3D math. But today, the
>CPUs are so fast, I can't see how a 3D card could outperform it
>without being as expensive as the main CPU itself. There is a
>lot of technology that goes in an intergrated CPU/FPU, the
>catching, ect. Having your CPU basicly *waiting all the time*
>for the 3D card to finish its stuff isn't something I'm not
>looking forward to.
The CPU won't be "waiting" for the 3D card, it'll be doing other
computations such as AI. Taking some of the burdon off the CPU would help
games (which is the main reason for DirectX) out quite a bit.
>You may also be interested to know also that Cyrix is comming out
>with a Dual FPU/Dual MMX CPU next year, if you insist on the
>competitor arguement.
That may help NT users but not Win95/98 users.
>I don't see 3D performance getting better with a CPU upgrade as
>being a problem. %-)
Sure, why not run the modem and the sound card off the CPU too. Intel tried
that a couple of years ago and it didn't fair too well.
Jak Crow
On 24 Oct 1997 01:45:22 GMT, "Raist" <rai...@mcs.com> wrote:
>It is coming. PowerVR already has it. Rendition is about to release it.
>We would all have had OpenGL already if M$ decided to support
>it right from the beginning, a year and a half ago.
This has been repeated before, but the performance of a MCD
isn't going to cut it in Win95, and not because of of MS.
Jak
sumatose
In group rec.games.programmer, Steve says...
> >with a Dual FPU/Dual MMX CPU next year, if you insist on the
> >competitor arguement.
>
>
> That may help NT users but not Win95/98 users.
That's not 'dual processor'. That _one_ processor having two FPU
built-in.
Raist
sumatose <suma...@NOSPAM.usa.net> wrote in article
<MPG.eb9d3a0d...@news.videotron.net>...
> In group rec.games.programmer, Raist says...
> > Jak Crow <fa...@devnull.com> wrote in article
> > > I think it's a bit blown out of proportion at this point in
> > > time. The hardware vendors really don't have anything out that can
> > > perform these features yet. And so far, doesn't it seem like the
> > > hardware doesn't and won't need it for a while?
> >
> > Completely untrue. Permedia 2, NVIDIA 128 and even the Rendition can
do
> > this feat.
>
> No They Do Not. You're the one lying.
>
> THAT'S GEOMETRY _SETUP_.
>
>
Yep, I confused things. So I take it back.
- Raist
Daron Myrick
|The NVIDIA Riva 128 chipset has reportedly an incredible geometry
|processor.
|But unfortunately for now looks like it is being toss away. Damn.
Noooo, you missed it completely.
DirectX 5 and 6 is using and will use RIVA's geometry processor.
Matter of fact, RIVA's geometry processor was built with DirectX in mind,
taking raw data
direct from DirectX with no conversion and extra calculation needed which
all other current
chips need.
Also, no video card I know of does actual 3D geometry processing to the
point of being able to render
and entire world from a list of objects, just the actual triangle geometric
setup.
Jeff Atwood
Hardware 3D geometry setup is a load of crap if you ask me. The cards that
"have" this feature are no faster than 3dfx anyway, so a fat lot of good it
does. I've never seen a 3D game to date that was geometry-limited-- meaning
the 3D models are so detailed that the CPU choked.
Jeff
sumatose wrote in message ...
Jeff Atwood
Angus,
The critical problem here is that even if geometry acceleration was
worthwhile on the PC (which isn't a given since the cards that "have" this
feature aren't faster than 3dfx under OpenGL), how could you design a game
with two totally different model sets? One super high polygon model set for
those cards that have geometry acceleration and another set of low polygon
models for cards that don't?
This would seem to require LOD management... I haven't seen a single game
with dynamic LOD management, where the 3D models get less detailed (less
polygons) as they are viewed from a distance and more detailed (more
polygons) when they are viewed up close. A modified form of this would be
required to accomodate geometry acceleration.
And even then, I'd bet that a fast Intel CPU would give the same performance
as a geometry accerator.
Jeff
Angus Dorbie wrote in message <344F16...@asd.sgi.com>...
>Jak Crow wrote:
>>
>> On Wed, 22 Oct 1997 21:34:39 -0700, Angus Dorbie
>> <dorbie...@asd.sgi.com> wrote:
>>
>> >According to WAVE Report on Digital Media #728
>> >(wa...@fourthwave.com) it looks like the much
>> >anticipated DirectX 6.0 release will not include D3D
>> >support for transformation and lighting calculations
>> >(a.k.a. Setup) slated as a potential improvement
>> >in the aforementioned release.
>>
>> I think it's a bit blown out of proportion at this point in
>> time. The hardware vendors really don't have anything out that can
>> perform these features yet. And so far, doesn't it seem like the
>> hardware doesn't and won't need it for a while? Besides, it isn't a
>> good idea to design hardware around one software product, right?
>>
>
>It is a chicken an egg circular argument.
>What you can say with certainty is that for
>anyone interested in HW geometry processing at
>whatever level, OpenGL or a proprietary interface
>are now the only options.
>If you look at where the low end HW is heading you'll
>get a good indicator of what will makes sense in the
>immediate future. Bear in mind that for lower end
>cards you are likely talking about slower CPUs in
>addition to upgrading installed systems, this makes
>HW geometry more attractive.
>Consider how you might use the CPU to improve scene
>visibility processing or other application processing
>while the GL card DMAs a display list, or between
>much faster IM calls on HW with even a modest FIFO.
>
>Cheers,Angus.
>
Daniel Phillips
rai...@mcs.com says...
>
>David Springer <spri...@matrix.eden.com> wrote...
>>...while OpenGL has no acceleration support under Win95 for even the best
>
>We would all have had OpenGL already if M$ decided to support
>
>- Raist
Is there a good reason why Microsoft's antics re OpenGL should not be
added to the growing list of anti-competitive complaints being levelled
at Microsoft by the DOJ? In other words, does the promotion of D3D and
suppression of OpenGL amount to an attempt to gain control of the 3D
game market?
Maybe the problem is there's nobody in the games industry willing to
risk challenging Microsoft. It's perfectly clear by now that Microsoft's
response to Carmack's open letter and the follow-up open letter is a big
fat zero.
Maybe this kind of activity doesn't fit the definition of an anti-trust
activity exactly. But it sure is harmful, and it sure does feel like an
abuse of a monopoly.
--
Daniel Phillips
phil...@dowco.com
Steve
sumatose wrote in message ...
>In group rec.games.programmer, Steve says...
>> >You may also be interested to know also that Cyrix is comming out
>> >with a Dual FPU/Dual MMX CPU next year, if you insist on the
>> >competitor arguement.
>>
>>
>> That may help NT users but not Win95/98 users.
>
>That's not 'dual processor'. That _one_ processor having two FPU
>built-in.
Yeah, oops. I guess I read that a little too fast.
Angus Dorbie
Jeff Atwood wrote:
>
> Angus,
>
> The critical problem here is that even if geometry acceleration was
> worthwhile on the PC (which isn't a given since the cards that "have" this
> feature aren't faster than 3dfx under OpenGL), how could you design a game
> with two totally different model sets? One super high polygon model set for
> those cards that have geometry acceleration and another set of low polygon
> models for cards that don't?
>
> This would seem to require LOD management... I haven't seen a single game
> with dynamic LOD management, where the 3D models get less detailed (less
> polygons) as they are viewed from a distance and more detailed (more
> polygons) when they are viewed up close. A modified form of this would be
> required to accomodate geometry acceleration.
>
> And even then, I'd bet that a fast Intel CPU would give the same performance
> as a geometry accerator.
>
> Jeff
I've seen games with LOD control, even very old examples, I find your
observation surprising, and I'm certainly aware of developers using
this in games. Also as I said before this is a circular argument, good
artists will exploit available resources. Differentiated offerings may
leverage improved sales if applications are able to exploit this.
I want to reiterrate that games will be able to exploit improved
geometry processing including occlusion culling to eliminate overdraw,
I think games will see an immediate benefit with well designed
geometry processing in HW and this differentiation will improve as
developers exploit this.
This is not just about geometry performance there is also the rest
of the work you'd like to perform with the CPUs, and it's not just
about performance in a new machine, there is adding grephics cards
to older systems, a largely fruitless task without a geometry
acceleration.
Cheers,Angus.
David Springer
In rec.games.programmer Marco Al <ma...@simplex.nl> wrote:
: Raist wrote:
: > The NVIDIA Riva 128 chipset has reportedly an incredible geometry
: > processor.
: > But unfortunately for now looks like it is being toss away. Damn.
: >
: > - Raist
: Only for geometry setup, not transformation. Its a bit overengineered
: in my opinion, a PII cannot even max out its trianglesetup and thats
: in a benchmark where it isnt even doing anything else :)
I asked in a separate thread if anyone had any idea what speed
PII would max it out but no one answered. I know it's still
not maxed out at 333mhz but the PII will be available in 450mhz
pretty soon. Is it -still- overengineered in that environment ?
David Springer
Ross Cunniff
Thomas Womack (mert...@sable.ox.ac.uk) wrote:
> Marco Al wrote in message <3450842D...@simplex.nl>...
> >Only for geometry setup, not transformation. Its a bit overengineered
> >in my opinion, a PII cannot even max out its trianglesetup and thats
> >in a benchmark where it isnt even doing anything else :)
> Over-engineering, or future-proofing?
> If you want over-engineering, have a look at HP's Visualize4fx board;
> 2.4GFLOPS in the geometry processors alone, which is eight times the
> theoretical peak speed of a P2/300.
It depends on your target customers whether you call that
"over-engineering" or "beating the pants off the competition". The
Visualize fx4 is emphatically not targeted at the games market; it's
aimed at professional CAD, architectural, vis sim, and digital studio
type apps, which tend to push geometry a lot more than a game which must
sell well to the millions of people who don't have good floating point.
The fx4 was designed not to slow down too much, even when rendering a
scene with 8 positional lights, 6 model clipping planes, spherical
texture coordinate generation, etc. And the system cost with fx4
graphics, dual 300 MHz Pentium II, 512Mb RAM, etc. is less than $20K,
which is very competitive with the other "professional" workstations out
there.
Additionally, the rasterization backend of the fx4 can handle a
theoretical peak of around 8 million lit triangles per second; tell
me when the CPU will be able to keep up with that while still leaving
a few cycles for the application? Not by the year 2000, at least.
Ross Cunniff
Hewlett-Packard Graphics Products Lab
cun...@fc.hp.com
Marco Al
Raist wrote:
> The NVIDIA Riva 128 chipset has reportedly an incredible geometry
> processor.
> But unfortunately for now looks like it is being toss away. Damn.
>
> - Raist
Only for geometry setup, not transformation. Its a bit overengineered
in my opinion, a PII cannot even max out its trianglesetup and thats
in a benchmark where it isnt even doing anything else :)
Marco
Marco Al
Jeff Atwood wrote:
>
> Hardware 3D geometry setup is a load of crap if you ask me. The cards that
> "have" this feature are no faster than 3dfx anyway, so a fat lot of good it
> does. I've never seen a 3D game to date that was geometry-limited-- meaning
> the 3D models are so detailed that the CPU choked.
>
> Jeff
Brian hook seems to disagree with you:
"It seems the big performance killer is triangle setup -- the Voodoo lacks a
full triangle setup core, so lots of polygons (which Quake2 has) hurt almost
as bad as lots of pixels. The SLI board isn't lacking in fill rate, but its
triangle throughput could stand some work."
He was under some misconceptions about the board at the time, it actually was
a more powerfull configuration than he thought at the time. But it does indi-
cate that Brian Hook thinks geometry setup is quite important.
BTW all games wich arent fillrate limited are limited by geometry and game
processing. Wich are pretty much all games apart from Quake.
Marco
Thomas Womack
Marco Al wrote in message <3450842D...@simplex.nl>...
Over-engineering, or future-proofing?
If you want over-engineering, have a look at HP's Visualize4fx board;
2.4GFLOPS in the geometry processors alone, which is eight times the
theoretical peak speed of a P2/300.
Tom
Raist
Daniel Phillips <phil...@dowco.com> wrote in article
<62ph17$fs2$1...@usenet.kornet.nm.kr>...
> rai...@mcs.com says...
> >
[stuff deleted]
> >
> >- Raist
>
> Is there a good reason why Microsoft's antics re OpenGL should not be
> added to the growing list of anti-competitive complaints being levelled
> at Microsoft by the DOJ? In other words, does the promotion of D3D and
> suppression of OpenGL amount to an attempt to gain control of the 3D
> game market?
>
> Maybe the problem is there's nobody in the games industry willing to
> risk challenging Microsoft. It's perfectly clear by now that Microsoft's
> response to Carmack's open letter and the follow-up open letter is a big
> fat zero.
>
> Maybe this kind of activity doesn't fit the definition of an anti-trust
> activity exactly. But it sure is harmful, and it sure does feel like an
> abuse of a monopoly.
Hmmm.. of course they want to control.. but in this particular case, I
guess
M$ has the right what to put in their OS. So I don't think this woudl be
evidence.
However, if there is evidence that M$ on purpose hampered other 3D API's
development for Windows (in an active way) my guess is that then yeah.
But I am not a lawyer so...
- Raist
>
> --
> Daniel Phillips
> phil...@dowco.com
>
>
Cathryn Mataga
This is a multi-part message in MIME format.
--------------1A5209B9A599983C1D1FFB03
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> Hardware 3D geometry setup is a load of crap if you ask me. The cards that
> "have" this feature are no faster than 3dfx anyway, so a fat lot of good it
> does. I've never seen a 3D game to date that was geometry-limited-- meaning
> the 3D models are so detailed that the CPU choked.
We're still early in the cycle for 3d accelerated computer games. I wouldn't
judge anything by the products that have been banged over from Playstation
conversions.
--------------1A5209B9A599983C1D1FFB03
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Cathryn Mataga
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Cathryn Mataga
n: Mataga;Cathryn
org: Junglevision Software
adr: 1432 University Ave.;;;Berkeley;California;94702;US of A
email;internet: cat...@junglevision.com
title: Chief Executioner
tel;work: 510-848-5211
tel;fax: 510-649-0452
tel;home: 510-841-7435
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------1A5209B9A599983C1D1FFB03--
Angus Dorbie
Well, much of this is just plane inaccurate but it's
history.
I'm not interested in large contorting summaries of
who is wearing the white hats and who is wearing the
black. It's meaningless, unrealistic and irrelevant.
I do object to the revisionism which surrounds the
scurrilous Windows 95 MCD decision. Your willingness
to just swallow the spin put on this by Microsoft is
dismal.
Cheers,Angus.
Raist
Jak Crow <jak...@shell3.ba.best.com> wrote in article
<62r3ec$9p4$1...@nntp2.ba.best.com>...
> In comp.sys.ibm.pc.hardware.video Angus Dorbie
<dorbie...@asd.sgi.com> wrote:
[stuff del]
> with a patch for the Renditon cards. Great, wonderful. Then Carmack plays
> with Direct3D and decides he doesn't like it. He takes a 3Dfx card, and
> plays around with GL, and it turns out to work. All of a sudden,
> everyone's jumping on the bandwagon saying that OpenGL with do everything
> from graphics to running your microwave.
This is very simple Jak:
* Go to your local library (Borders/Barnes N' Nobles, etc.) and pick up a
programming
book on OpenGL and Direct 3D
* Read them
* Try to code something simple in both.
* Compare the functionality of both.
The whole point is that OpenGL has been time tested, is robust, is
computer-widely
industry accepted and has *BETTER* features than even the current Direct 3D
5.0.
Now, I understand that M$ wanted to do D3D originally- the point where the
ear turns
deaf is when developers get together and ask M$ for leaving them a *CHOICE*
of
which API's to use, but M$ blatantly ignores them.
They even try to convince everybody that D3D is "as good as OpenGL" with
the totally
misleading "D3D Quake Demo." Misleading of course because they compared
the framerates of two different card technologies.
This is quite simple, a lot of developers have been asking M$ to provide
infrastructure
to support OpenGL on Win 95 but M$ has refused. So we get stuck with a 3D
API which has LESS features than OpenGL, provides for LESS hardware driver
optimizations and is much harder to develop for.
> SGI employees a spouting on
> newsgroups about it's virtues, acting like unofficial offical
> spokespeople, saying how D3D is 'ripping Open GL off', blaming MS for the
> lack of GL support in Win95, yet little was forthcoming about how SGI
> would be supporting GL in Win95. We had and have Quake parrot/groupies
> mimicing Carmack on his statements about D3D and saying that GL is the
way
> to go without really knowing what they're talking about, just as long as
> it was coming from someone at id, but of course things were taken
> completely out of context or just plain not said.
Certainly iD carries a certain amount of wait, being at the state of the
art that they are.
However, Carmack did write a very long explanation of why he chose OpenGL..
It think
maybe you might want to read it.
> Then there were/all these "when" and "ifs" about various GL drivers
> coming out at some time or another, what cards are going to have them and
> so forth, and still only one other card other than the Voodoo has gotten
a
> driver, and only 2 games have come out supporting GL
PoweVR supports GL, as Permedia and Voodoo. Rendition is around the corner
and Riva 128's is too.
> and the others that
> are coming out in the next few months are the same "game engine" and
still
> there are going to be very few cards to support even these.
What few cards? Permedia 2, PowerVR2, Riva, 3DFX and REndition covers a
lot
of territory. The only other worthy contender here would be ATI Xpert @
play I guess.
Other than that, what do you want to run something like Quake in? S3's
Virge GX?
Matrox Mystique?
Cards that severely lack botht he horsepower and 3D features?
> Meanwhile,
> there are a number of D3D titles I can go get right now,
Which for the most part, blow flying twinkies. Monster Truck Madness? Heh,
what
a joke.
Unreal will be probably very good, as Forsaken and Jedi Knight. Try
running those
on an S3 or Mystique - or hey, the Cirrus Laguna! That should be great
playing those
games there right?
> a the most recent
> are already using DirectX 5 which has helped development considerably.And
> yet, what's happening with GL other than anything that uses the quake
> engine? What's SGI doing now that they've gotten some attention from the
> game market? It would appear, so far, nothing except jumping on and
> encouraging bandwagoning, for what appears to be no other reason than
> because it's against MS.
While there are many people that might go with this, I am not one of the,
nor do I think
iD software is one of them.
> Botton line: the customers don't give a crap what's under the
> "hood" of the game, as long as it's running on their systems with
> their hardware.
I do care because I want quality products with nice effects and graphics.
The harder it is for the developer to develop these games, the more prone
to bugs,
more delays, more expensive the game will be.
And hey, we are talking about using D3D 5.0 now that it has been released.
Anything
before that is pretty useless. So what you expected iD software to do?
Wait
for D3D to become stable? heh.
> This "discussion" has crossed into developer territory and
> should be taken elsewhere I think. It's reached the end of it's
> usefulness.
- Raist
sumatose
In group rec.games.programmer, Daniel Phillips says...
> Is there a good reason why Microsoft's antics re OpenGL should not be
> added to the growing list of anti-competitive complaints being levelled
> at Microsoft by the DOJ? In other words, does the promotion of D3D and
> suppression of OpenGL amount to an attempt to gain control of the 3D
> game market?
Yeah, sure, Phillips, let's put everyone that you don't like in
jail.
This is America. A company has the right to make a product, like
an API, and promote it. It's not anti-competive - it's
competition. OpenGL has no more rights to be The 3D API than
other 3D API.
Angus Dorbie
Mark Kilgard wrote:
>
> In article <62qqt8$j...@fcnews.fc.hp.com>, cun...@fc.hp.com (Ross Cunniff) writes:
> |>
> |> Additionally, the rasterization backend of the fx4 can handle a
> |> theoretical peak of around 8 million lit triangles per second; tell
> |> me when the CPU will be able to keep up with that while still leaving
> |> a few cycles for the application? Not by the year 2000, at least.
>
> has the transformation speed to indeed transform and supply that
> rate of polygons. (The theoretical peak polygon setup and rasterization
> rate for InfiniteReality is over 11 million polygons/sec.) InfiniteReality
> also has on-board display list memory (15 megabytes worth) meaning that
> you really could sustain the transformation rate that you speak of and have
> the CPU basically unloaded.
Lets not forget that the display list was mainly a win for
the ONYX, the ONYX2 XTOWN connector has the bandwidth to
sustain pipe busying bandwidth from the host memory, allowing
huge databases to be drawn without graphics performance
degradation.
>
> The system's R10000 processor does "keep up" by offloading all the graphics
> floating point transformations to 4 GE11 floating point processors
> (540 megaflops/processor).
>
> Perhaps you meant to say "Not before the year 1996, for sure." :-)
>
> Beyond that, today's Onyx2 system architecture can scale to 128
> processors (and beyond) and can support up to 8 InfiniteReality pipelines
> in a single system (SGI's RealityMonster configuration). Because Onyx2
> can scale graphics throughput *and* CPU to graphics bandwidth *and* the number
> of CPUs all at once, you can use mulit-pipe compositing to combine the
> rendering power of multiple InfiniteReality pipelines for rendering
> rates well beyond the polygon throughput of a single InfiniteReality
> pipeline.
Monster update FYI,
a customer phoned up an engineer here today and he was gushing
with enthusiasm. He's got an 8 pipe monster and it's achieving
50 million lit polygons /sec *sustained in his application*.
This is on a database which is between 1 and 2 gigabytes in
size (it won't fit in display list memory). He was heard
enthusiastically saying things like "I've got the fastest
graphics system on the planet.", honestly. Ofcourse he was
wrong, it's not the only 8 pipe reality monster out there.
Cheers,Angus.
Angus Dorbie
sumatose wrote:
>
> In group rec.games.programmer, Allen Akin says...
> > Glenn Corpes <gle...@cix.co.uk.notthisbityoumoron> wrote:
> > | ...Which is why there still isn't a consumer card with anything but a
> > | Quake driver...
> >
> > I think Microsoft's decision to withdraw the MCD-based DDK is the main
> > reason consumer-level cards don't have full drivers yet. I see that
> > 3Dfx issued a beta release of its full driver, so vendors are
> > recovering from that setback.
> >
> > Allen
>
> I disagree. The main reason why consumer-level cars don't have
> full drivers is that 1) nobody cared about OpenGL before Carmack
> 'saved' it and
Ofcourse they cared, lots of them cared enough to have MCDs
underway or completed. They were ummm... disapointed with
Microsoft when the MCD was dropped.
John Carmack helped a lot by waking people up to the fact
that D3D had no clothes, but there was already disquiet amoung
the IHVs, they already knew and even back then OpenGL drivers
were in the pipeline. Carmack was interested in pushing what
was possible rather than subsisting on whatever second rate
3D offering Microsoft doled out. He's been criticised for this
by some (amazingly enough) but you have to admire his pioneering
spirit.
> 2) the cards being made two years ago were way to
> weak for opengl anyway.
This is strange considering the availability of 3Dfx cards
running glide, clearly some HW was out there.
..... Also, AFAIK
> the 3DFX beta release of a full driver is for SGI OpenGL's, not
> MS-OpenGL.
Please explain what you mean this statement, OpenGL
support is OpenGL support. Are you talking about wiggle on
some cards or are you saying something else... 3Dfx have
added some very cool extensions of their own implementations.
They have an ICD, and further I think they committed to ICD
earlier than most and it's their own implementation, ie not
derived from SGI's code. Unless you count the OpenGL SDK
from Microsoft which is basically the SGI standard
implementation.
Cheers,Angus.
sumatose
In group rec.games.programmer, Angus Dorbie says...
> sumatose wrote:
> > I disagree. The main reason why consumer-level cars don't have
> > full drivers is that 1) nobody cared about OpenGL before Carmack
> > 'saved' it and
>
> Ofcourse they cared, lots of them cared enough to have MCDs
> underway or completed. They were ummm... disapointed with
> Microsoft when the MCD was dropped.
If you are going to make a driver for an API, you need to a have
consumer demand for it; you need to have software that people use
in the market. There was nothing using OpenGL two years ago
except Softimage. The focus for CAD was doing a Heidi and
Autocad driver only.
> John Carmack helped a lot by waking people up to the fact
> that D3D had no clothes, but there was already disquiet amoung
> the IHVs, they already knew and even back then OpenGL drivers
> were in the pipeline. Carmack was interested in pushing what
> was possible rather than subsisting on whatever second rate
> 3D offering Microsoft doled out. He's been criticised for this
> by some (amazingly enough) but you have to admire his pioneering
> spirit.
Carmack did GLQuake so that it could run on his Intergraph and on
SGI machine. They were quite surprised when 3DFX said they could
make it work on their hardware. I think you're blury about the
story of the whole thing. Now, of course, OpenGL is indeed the
3D Hardware interface for quake. That kind of 'happened'.
I don't believe it's right to say that Carmack wanted to push 3D
API evolution and put down Direct3D. He was quite exited - and
cited in early Direct3D press releases - about D3D. When he
played with it though, he hated it, and said prefered OpenGL much
more. I don't really think he had a master plan in mind, he just
reacted to what he saw as a programmer.
> > 2) the cards being made two years ago were way to
> > weak for opengl anyway.
>
> This is strange considering the availability of 3Dfx cards
> running glide, clearly some HW was out there.
3DFX cards haven't been available for that long. It looks like a
long time on the internet, but in fact, you're bluring the
history of the whole thing. Remember also that we are talking
about two years ago and more, as software/drivers aren't written
in a week-end.. 8-)
> ..... Also, AFAIK
> > the 3DFX beta release of a full driver is for SGI OpenGL's, not
> > MS-OpenGL.
>
> Please explain what you mean this statement, OpenGL
> support is OpenGL support. Are you talking about wiggle on
> some cards or are you saying something else... 3Dfx have
> added some very cool extensions of their own implementations.
>
> They have an ICD, and further I think they committed to ICD
> earlier than most and it's their own implementation, ie not
> derived from SGI's code. Unless you count the OpenGL SDK
> from Microsoft which is basically the SGI standard
> implementation.
The beta driver is being presented as a SGI OpenGL For Windows
driver. This doesn't sound like an ICD (..possibly based on the
SGI OpenGL code), but a driver for SGI's implementation.
As far as the extentions that 3DFX have added, I only know about
the ones in Quake II's mini-driver (an opengl replacement).
It's confusing because there is 1) the GLQuake mini-driver 2)
3dfxGL 3) and SGI OpenGL driver, and you say there is 4) an
future ICD.
It all looks the same, but they are very different. An OpenGL
driver, for example, isn't called 'opengl32.dll'. That's
_replacing_ opengl, not providing a driver for it to use. The
level of OpenGL possible compliance also varies.
Sean Cavanaugh
Wilbur Streett wrote in message <3450e45d...@news.monmouth.com>...
>"Steve" <abra...@pilot.msu.edu> wrote:
>
>>Peter also shares my concerns about the insufficiency of the AGP
>>architecture. He demands that textures should be processes from the local
>>graphic memory, since the bandwidth of local graphic memory is still much
>>higher than what AGP offers. It's actually even worse than what you could
>>read in my 'AGP - The Theory', section 'Critical Thoughts'. Even with x4
>>mode (probably not available before 1999) there's one peculiar problem.
>>Whilst the AGP device can read from main memory with 512 MB/s (x2 mode) or
>>even 1 GB/s (x4 mode), the CPU can only write to the AGP device via a 66
MHz
>>PCI like technique, offering not more than 264 MB/s bandwidth. If the x2
or
>
>Do you understand that 264 MB/s bandwidth is about 8 times that of full
>screen uncompressed broadcast video? Do you know that Broadcast quality is
>being done with compression at 3.4 MB/s? Considering the user population
>that watches Cable everyday, I think that 8X the uncompressed bandwidth of
>Broadcast video is plenty.
>
>Wake up already.
>
>Wilbur
I think you are forgetting a few key features. First, current broadcast
video (at least in North America) is analog. Going to digital ups the scale
of bandwith immensley, due to a few small things: our current color depth
representation taking 4 bits per pixel for true color (basically 1 byte
wasted per pixel when used to render a final image), much sharper images
than broadcast television (even 640x480, but definitely 800x600+), and
refresh rates higher than 30mhz (broadcast television 60hz interlaced).
Someone correct me if I'm wrong but I seem to recall the highest spec'ed
DTV resoloution at around 1920x1200. Which I think is around 15x the
surface area of current analog TV.
- Sean
=====
The opinions expressed in this message are my own personal views
and do not reflect the official views of the Microsoft Corporation.
=====
Angus Dorbie
sumatose wrote:
>
> In group rec.games.programmer, Angus Dorbie says...
> > sumatose wrote:
> > ..... Carmack was interested in pushing what
> > was possible rather than subsisting on whatever second rate
> > 3D offering Microsoft doled out. He's been criticised for this
> > by some (amazingly enough) but you have to admire his pioneering
> > spirit.
>
> I don't believe it's right to say that Carmack wanted to push 3D
> API evolution and put down Direct3D.
I don't think it's right to say that either so I didn't. But
I stand by what I did say, reffer to the above for clarification.
>
> > > 2) the cards being made two years ago were way to
> > > weak for opengl anyway.
> >
> > This is strange considering the availability of 3Dfx cards
> > running glide, clearly some HW was out there.
>
> 3DFX cards haven't been available for that long. It looks like a
> long time on the internet, but in fact, you're bluring the
> history of the whole thing. Remember also that we are talking
> about two years ago and more, as software/drivers aren't written
> in a week-end.. 8-)
Drivers can be produced in large part as part of the the
design. And low cost 3Dfx boards have been around for
longer than you claim but perhaps not 2 years (but only
because I don't have dates).
The time to produce a driver isn't relevant to the claim
that the HW 2 years ago wasn't up to OpenGL. Not that this
is even a sensible claim in the first place. Consider that
this started with a comparrison with D3D and Microsoft would
still have you believe the line that HW isn't up to OpenGL
and D3D is the game API..
>
> > ..... Also, AFAIK
> > > the 3DFX beta release of a full driver is for SGI OpenGL's, not
> > > MS-OpenGL.
> >
> > Please explain what you mean this statement, OpenGL
> > support is OpenGL support. Are you talking about wiggle on
> > some cards or are you saying something else... 3Dfx have
> > added some very cool extensions of their own implementations.
> >
> > They have an ICD, and further I think they committed to ICD
> > earlier than most and it's their own implementation, ie not
> > derived from SGI's code. Unless you count the OpenGL SDK
> > from Microsoft which is basically the SGI standard
> > implementation.
>
> The beta driver is being presented as a SGI OpenGL For Windows
> driver. This doesn't sound like an ICD (..possibly based on the
> SGI OpenGL code), but a driver for SGI's implementation.
>
> As far as the extentions that 3DFX have added, I only know about
> the ones in Quake II's mini-driver (an opengl replacement).
>
> It's confusing because there is 1) the GLQuake mini-driver 2)
> 3dfxGL 3) and SGI OpenGL driver, and you say there is 4) an
> future ICD.
See there you go again, you take some inference out of context
in your brain turn it into fact.
Why is this confusing? If it's confusing just do what the
shrink wrap says, you shouldn't be messing with the dlls.
You presented this as an either SGI or MS situation. This
is a false distinction which was my point, see below.
> It all looks the same, but they are very different. An OpenGL
> driver, for example, isn't called 'opengl32.dll'. That's
> _replacing_ opengl, not providing a driver for it to use. The
> level of OpenGL possible compliance also varies.
You say very different then you cite a dll file name ?!
SGI's software driver has a different file name and it was
only done this way to appease MS support concerns,
not for differences in OpenGL functionality. Specifically it
was done so it wouldn't replace the MS library should a user
make a mistake and replace the MS file with the SGI, quite
the opposite of your interpretation. If you rename the file
chances are it will work (the glu dll from SGI calls the sgi
ogl lib so you have to use the ms glu if required). Chances
are this will work just dandy on an OpenGL program.
You are inferring an inaccurate technical distinction from
what was largely a decision about support. The SGI sdk could
be used to produce an normal OpenGL ICD which is as
compatible as any other ICD.
The issues of cards which output an auxiliary video
naturally complicate things, you might be using OpenGL on
your desktop or have an OpenGL card installed. Just use the
drivers supplied for the auxiliary card or redistributed
with the game.
It's still OpenGL from the standpoint of a program which
wants to use the card although selecting a context on the
card is naturally a different process, it's got nothing
to do with OpenGL or the merits of the driver story, it's
the nature of the product you bought.
Cheers,Angus.
Cathryn Mataga
This is a multi-part message in MIME format.
--------------04158174790B5F0B2665488B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jak Crow wrote:
> Sheesh...D3D and OGL are free for use. "Control" of the 3D game
> market isn't going to go to who owns the API, it's going to go to the
> company that has the best 3D games, or at least the most 3D games (since
> when has quality mattered?)
I think the OpenGL vs D3D war matters most to video card manufacturers
in the long term. We'll probably see Microsoft buy out the chipset
that wins the war or build their own card -- and then incorporate new
features in their card and DX12,13... simultaneously -- screwing over
the other chipset makers who have to wait for new drivers. Talk to
omeone in the joystick business to see how it's going to work.
--------------04158174790B5F0B2665488B
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Cathryn Mataga
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Cathryn Mataga
n: Mataga;Cathryn
org: Junglevision Software
adr: 1432 University Ave.;;;Berkeley;California;94702;US of A
email;internet: cat...@junglevision.com
title: Chief Executioner
tel;work: 510-848-5211
tel;fax: 510-649-0452
tel;home: 510-841-7435
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------04158174790B5F0B2665488B--
Cathryn Mataga
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Raist wrote:
> What few cards? Permedia 2, PowerVR2, Riva, 3DFX and REndition covers a
> lot
> of territory. The only other worthy contender here would be ATI Xpert @
> play I guess.
>
> Other than that, what do you want to run something like Quake in? S3's
> Virge GX?
> Matrox Mystique?
Riva 128 and Verite' have Windows 95 OpenGL drivers coming? Has this
been announed? OpenGL drivers for these two chipsets pretty much
will end the 'no hardware support' issue, imo. If Nvidia and Renditions
both support OpenGL, I suspect ATI will fall in line.
Btw, my prediction is that games based on the Quake engine
and other OpenGL games will outsell Direct3d games in total units
sold in 1998.
--------------022894B6BD6729B4D2CAD410
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Cathryn Mataga
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Cathryn Mataga
n: Mataga;Cathryn
org: Junglevision Software
adr: 1432 University Ave.;;;Berkeley;California;94702;US of A
email;internet: cat...@junglevision.com
title: Chief Executioner
tel;work: 510-848-5211
tel;fax: 510-649-0452
tel;home: 510-841-7435
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------022894B6BD6729B4D2CAD410--
Raist
Jak Crow <fa...@devnull.com> wrote in article
<344f0d5c...@nntp.best.com>...
> On Wed, 22 Oct 1997 21:34:39 -0700, Angus Dorbie
> <dorbie...@asd.sgi.com> wrote:
>
> >According to WAVE Report on Digital Media #728
> >(wa...@fourthwave.com) it looks like the much
> >anticipated DirectX 6.0 release will not include D3D
> >support for transformation and lighting calculations
> >(a.k.a. Setup) slated as a potential improvement
> >in the aforementioned release.
>
> I think it's a bit blown out of proportion at this point in
> time. The hardware vendors really don't have anything out that can
> perform these features yet. And so far, doesn't it seem like the
> hardware doesn't and won't need it for a while?
Completely untrue. Permedia 2, NVIDIA 128 and even the Rendition can do
this
feat.
> Besides, it isn't a
> good idea to design hardware around one software product, right?
No, in fact, it should be the other way around. And it could be the other
way
around. OpenGL provides this kind of infrastructure, whereas Direct 3D does
not.
- Raist
>
> Jak
>
> Email headers are false.
> Please use:
>
> jakcrow (at) werewolves (dot) org
>
Raist
David Matiskella <dav...@netscape.com> wrote in article
<344FFDFC...@netscape.com>...
>
>
> Raist wrote:
>
[stuff del]
> >
> > Completely untrue. Permedia 2, NVIDIA 128 and even the Rendition can
do
> > this
> > feat.
>
> Not a single chip you mentioned does lighting or transformations.
They
> do triangle setup ( gradients for the edges). They don't do matrix
> multiplication. There are a couple of compnies promising transformation
and
[stuff del]
> anyhow. I would much rather they spent the transistors adding stencil
buffers
> and multipass texturemapping. IMHO
>
> --
> David Matiskella
I take it back.. I confused geometry with the other stuff.
- Raist
Raist
Jak Crow <fa...@devnull.com> wrote in article
> On 24 Oct 1997 01:45:22 GMT, "Raist" <rai...@mcs.com> wrote:
>
> >It is coming. PowerVR already has it. Rendition is about to release
it.
> >We would all have had OpenGL already if M$ decided to support
> >it right from the beginning, a year and a half ago.
>
> This has been repeated before, but the performance of a MCD
> isn't going to cut it in Win95, and not because of of MS.
Again, M$ could have provided support for making OpenGL doable on M$.
The ICD's and support for hardware companies. IF it was like you said,
would
it make sense that iD was one of the software companies leading the
peatition
for M$ to support OpenGL on Windows 95?
Marco Al
Thomas Womack wrote:
> Over-engineering, or future-proofing?
Considering its fill-rate with small triangles I would definitely say over-
engineered.
Marco
Wilbur Streett
Carl Mueller
WStr...@shell.monmouth.com (Wilbur Streett) wrote:
>"Steve" <abra...@pilot.msu.edu> wrote:
>>[...]
>>Whilst the AGP device can read from main memory with 512 MB/s (x2 mode) or
>>even 1 GB/s (x4 mode), the CPU can only write to the AGP device via a 66 MHz
>>PCI like technique, offering not more than 264 MB/s bandwidth. If the x2 or
>
>Do you understand that 264 MB/s bandwidth is about 8 times that of full
>screen uncompressed broadcast video? Do you know that Broadcast quality is
>being done with compression at 3.4 MB/s? Considering the user population
>that watches Cable everyday, I think that 8X the uncompressed bandwidth of
>Broadcast video is plenty.
And no computer will ever need more than 64K of main memory!
You've got remember: it can take more information to put together a
complex scene than there are pixels in it.
If we consider 264 MB/s and suppose that we want 26.4 FPS, then that
leaves us with 10MB in order to describe a scene. If we suppose that
a single polygon requires 100 bytes of description, then we can have
100K polys. That might be an interesting scene, but you can be sure
that such a limit will already cramp somebody's style.
Of course, 264 MB/s is also a PEAK figure, not a constant rate. You'll
probably be lucky to get half of that.
David Springer
In rec.games.programmer Carl Mueller <mue...@cs.unc.edu> wrote:
: WStr...@shell.monmouth.com (Wilbur Streett) wrote:
: >"Steve" <abra...@pilot.msu.edu> wrote:
: >>[...]
: >>PCI like technique
What makes you think that ?
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 ******************
Steve
Wilbur Streett wrote in message <3450e45d...@news.monmouth.com>...
>"Steve" <abra...@pilot.msu.edu> wrote:
>
>>Peter also shares my concerns about the insufficiency of the AGP
>>architecture. He demands that textures should be processes from the local
>>graphic memory, since the bandwidth of local graphic memory is still much
>>higher than what AGP offers. It's actually even worse than what you could
>>read in my 'AGP - The Theory', section 'Critical Thoughts'. Even with x4
>>mode (probably not available before 1999) there's one peculiar problem.
>>Whilst the AGP device can read from main memory with 512 MB/s (x2 mode) or
>>even 1 GB/s (x4 mode), the CPU can only write to the AGP device via a 66
MHz
>>PCI like technique, offering not more than 264 MB/s bandwidth. If the x2
or
>
>Do you understand that 264 MB/s bandwidth is about 8 times that of full
>screen uncompressed broadcast video? Do you know that Broadcast quality is
>being done with compression at 3.4 MB/s? Considering the user population
>that watches Cable everyday, I think that 8X the uncompressed bandwidth of
>Broadcast video is plenty.
>
>Wake up already.
>
>Wilbur
That's not really relevant. We're talking about 3d here. And the real
point is that even though AGP can read from main memory much faster than
PCI, the CPU can only write to AGP as fast as PCI. So AGP may just be one
big crock of shit anyway. (Until the 100Mhz bus comes out anyway, but it
still won't deliver 2x write capability) So it looks like we'll still need
plenty of on-card video memory.
Jak Crow
: you are getting from your MCD implementations is too slow.
: The drivers had been in the pipeline for months with
: IHVs waiting for the goahead. The MCD support would have
: made a large direct impact on the availability of HW
: accelerated OpenGL drivers and textured fill performance
: in particular. The explanation of poor performance in Win95
: just doesn't wash, it's ridiculous. What's doubly silly
: is that to say this alledged slowness wasn't because of
: Microsoft. You must have eaten a file of Microsoft press
: releases for breakfast.
: Cheers,Angus.
Well, it always seem to be the norm that when people refer to
previous information that is even in the slightest bit pro-MS, said person
must be a MS lacky. Well, if the MCD statement isn't true, what's true
Angus? Since your are posting from SGI, perhaps you could enlighten us as
to what the "truth" about this matter? Can you objectively speak on this
matter without your affiliation with SGI getting in the way?
Let me tell you what I see here: MS started working on Direct 3D
for 3D graphics on Win95, hardware vendors were just coming out with the
first 3D cards to use Direct3D and their custom APIs. Games were slow in
coming, MS was late with D3D, hardware vendors wanted it ASAP. There were
some problems with the first games using D3D, expected. Custom API games
were starting to show some impressive stuff. New D3D games came out and a
few were really starting to look good. At no point was OpenGL mentioned
for accelerated hardware support on these game cards. Then Quake came out,
with a patch for the Renditon cards. Great, wonderful. Then Carmack plays
with Direct3D and decides he doesn't like it. He takes a 3Dfx card, and
plays around with GL, and it turns out to work. All of a sudden,
everyone's jumping on the bandwagon saying that OpenGL with do everything
from graphics to running your microwave. SGI employees a spouting on
newsgroups about it's virtues, acting like unofficial offical
spokespeople, saying how D3D is 'ripping Open GL off', blaming MS for the
lack of GL support in Win95, yet little was forthcoming about how SGI
would be supporting GL in Win95. We had and have Quake parrot/groupies
mimicing Carmack on his statements about D3D and saying that GL is the way
to go without really knowing what they're talking about, just as long as
it was coming from someone at id, but of course things were taken
completely out of context or just plain not said.
Then there were/all these "when" and "ifs" about various GL drivers
coming out at some time or another, what cards are going to have them and
so forth, and still only one other card other than the Voodoo has gotten a
driver, and only 2 games have come out supporting GL and the others that
are coming out in the next few months are the same "game engine" and still
there are going to be very few cards to support even these. Meanwhile,
there are a number of D3D titles I can go get right now, a the most recent
are already using DirectX 5 which has helped development considerably.And
yet, what's happening with GL other than anything that uses the quake
engine? What's SGI doing now that they've gotten some attention from the
game market? It would appear, so far, nothing except jumping on and
encouraging bandwagoning, for what appears to be no other reason than
because it's against MS.
Botton line: the customers don't give a crap what's under the
"hood" of the game, as long as it's running on their systems with
their hardware. This "discussion" has crossed into developer territory and
Jak Crow
In comp.sys.ibm.pc.hardware.video Jak Crow <jak...@shell3.ba.best.com> wrote:
: This "discussion" has crossed into developer territory and
: should be taken elsewhere I think. It's reached the end of it's
: usefulness.
Correction: I didn't see that this was being crossposted. I
apologize for the above statement.
sumatose
I think this is because the polygone count of games is still
pretty low as of now. And quake seems to be the only benchmark
people trust!
Anyway, looks like this DX6 thread has become another 50 message
a day nightmare; this is my last message! 8-)
In group rec.games.programmer, Jeff Atwood says...
> Hardware 3D geometry setup is a load of crap if you ask me. The cards that
> "have" this feature are no faster than 3dfx anyway, so a fat lot of good it
> does. I've never seen a 3D game to date that was geometry-limited-- meaning
> the 3D models are so detailed that the CPU choked.
>
> Jeff
>
> sumatose wrote in message ...
> >THAT'S GEOMETRY _SETUP_.
Jak Crow
In comp.sys.ibm.pc.hardware.video Daniel Phillips <phil...@dowco.com> wrote:
: Is there a good reason why Microsoft's antics re OpenGL should not be
: at Microsoft by the DOJ? In other words, does the promotion of D3D and
: suppression of OpenGL amount to an attempt to gain control of the 3D
: game market?
Sheesh...D3D and OGL are free for use. "Control" of the 3D game
Nicholas Wilt
sumatose wrote in article ...
>In group rec.games.programmer, Raist says...
>> Jak Crow <fa...@devnull.com> wrote in article
>>
>> Completely untrue. Permedia 2, NVIDIA 128 and even the Rendition can do
>> this feat.
>
>No They Do Not. You're the one lying.
>
>THAT'S GEOMETRY _SETUP_.
"Transform and lighting" is the process of transforming and lighting
vertices in model space (with the aid of device state) into screen space.
"Triangle setup" is the process of computing the parameters required to
interpolate the screen-space positions, colors, and texture coordinates
across the triangle.
Some hardware takes the start points and deltas needed for this
interpolation as input. This means the host processor typically spends >50%
of the time in the 3D accelerator's driver computing these parameters and
shoveling them across the bus. Hardware that incorporates triangle setup can
take the raw screen space vertices, colors, and texture coordinates for a
triangle and compute the start points and deltas with no help from the host
processor. This conserves bus bandwidth as well as CPU clock cycles.
Direct3D supports accelerators that incorporate triangle setup.
Hardware transform and lighting incurs a much higher hardware cost to
implement than triangle setup, so it will be some time before this becomes
common in the volume PC accelerator space. Also, it's not obvious that
hardware vendors will spend their gate budgets pulling Direct3D's geometry
pipeline into their hardware. They might implement bigger caches or more
complex rasterization pipelines instead.
--Nick
Sean Cavanaugh
Steve wrote in message <62quo1$r...@snews3.zippo.com>...
>
>That's not really relevant. We're talking about 3d here. And the real
>point is that even though AGP can read from main memory much faster than
>PCI, the CPU can only write to AGP as fast as PCI. So AGP may just be one
>big crock of shit anyway. (Until the 100Mhz bus comes out anyway, but it
>still won't deliver 2x write capability) So it looks like we'll still need
>plenty of on-card video memory.
>
I would say you probably don't have to write directly to the AGP
video card very often, other than to do 'simple' things such as set video
modes, refresh rates, palettes, memory mappings etc, process IRQ hits, etc.
Anything larger would ideally be shoved into system memory and the AGP card
could then read it and act on it at 2x (100mhz as well) speed, bypassing
shoving a ton of stuff directly to an AGP card.
I think you forgot the point of AGP was that the CPU could work with
system memory instead of video memory, and the video card would have a
relatively decent bus to the system memory as well. And the AGP card's
arent necessarily to using the system memory strictly for 3d textures . . .
Daniel Phillips
jak...@shell3.ba.best.com says...
Way off. The same argument could have been made for PC apps vs MSDos
back when nobody but Bill Gates realized that controlling Dos would
eventually allow him to control all the apps as well. (At the time, Lotus
123, Word Perfect and dBase seemed unstoppable. Free or not free isn't
the issue - it's who controls the technology base.
Mark Kilgard
In article <62qqt8$j...@fcnews.fc.hp.com>, cun...@fc.hp.com (Ross Cunniff) writes:
|>
|> Additionally, the rasterization backend of the fx4 can handle a
|> theoretical peak of around 8 million lit triangles per second; tell
|> me when the CPU will be able to keep up with that while still leaving
|> a few cycles for the application? Not by the year 2000, at least.
InfiniteReality can sustain that rasterization rate today and actually
has the transformation speed to indeed transform and supply that
rate of polygons. (The theoretical peak polygon setup and rasterization
rate for InfiniteReality is over 11 million polygons/sec.) InfiniteReality
also has on-board display list memory (15 megabytes worth) meaning that
you really could sustain the transformation rate that you speak of and have
the CPU basically unloaded.
The system's R10000 processor does "keep up" by offloading all the graphics
floating point transformations to 4 GE11 floating point processors
(540 megaflops/processor).
Perhaps you meant to say "Not before the year 1996, for sure." :-)
Beyond that, today's Onyx2 system architecture can scale to 128
processors (and beyond) and can support up to 8 InfiniteReality pipelines
in a single system (SGI's RealityMonster configuration). Because Onyx2
can scale graphics throughput *and* CPU to graphics bandwidth *and* the number
of CPUs all at once, you can use mulit-pipe compositing to combine the
rendering power of multiple InfiniteReality pipelines for rendering
rates well beyond the polygon throughput of a single InfiniteReality
pipeline.
- Mark
Daniel Phillips
dir...@microsoft.com says...
>Hardware transform and lighting incurs a much higher hardware cost to
>implement than triangle setup, so it will be some time before this becomes
>common in the volume PC accelerator space. Also, it's not obvious that
>hardware vendors will spend their gate budgets pulling Direct3D's geometry
>pipeline into their hardware. They might implement bigger caches or more
>complex rasterization pipelines instead.
>
>--Nick
1) From the above, those hardware vendors who *want* to do hardware
transform and lighting with Direct3D are out of luck.
2) When it becomes available, applications will have to be rewritten to
take advantage of it.
Direct3D is an abortion.
--
Daniel Phillips
phil...@dowco.com
Rob Rodgers
suma...@NOSPAM.usa.net (sumatose) wrote:
>> I think Microsoft's decision to withdraw the MCD-based DDK is the main
>I disagree. The main reason why consumer-level cars don't have
>full drivers is that 1) nobody cared about OpenGL before Carmack
>weak for opengl anyway.
3) If MS hadn't scuttled MCD, nobody would give a rat's ass about
OpenGL hardware _today_.
Take a look at the MCDs on NT4. They all suck. The men in white coats
would be picking up SGI.com posters if they continued to claim that
OpenGL "is as fast as Direct3d" if MCDs were shipping. There are two
things keeping OpenGL alive as a possible games API for future use:
QuakeGl and Microsoft nuking MCD on 95.
>Also, AFAIK
>the 3DFX beta release of a full driver is for SGI OpenGL's, not
>MS-OpenGL.
That's a good thing, actually. It's a pain in the ass switching back
and forth between the Debug and 3dfxdebug configs in vc5. It'll be
nice to be able to just have one common binary.
----
http://www.wam.umd.edu/~rsrodger
"I did not get my Spaghetti-O's, I got spaghetti! I want the
press to know this." - Thomas Grasso, executed (OK) 3/20/95
Glenn Corpes
suma...@NOSPAM.usa.net (sumatose) wrote:
>
> > John Carmack helped a lot by waking people up to the fact
> > that D3D had no clothes, but there was already disquiet amoung
> > the IHVs, they already knew and even back then OpenGL drivers
> > was possible rather than subsisting on whatever second rate
> > 3D offering Microsoft doled out. He's been criticised for this
> > by some (amazingly enough) but you have to admire his pioneering
> > spirit.
>
> SGI machine. They were quite surprised when 3DFX said they could
> make it work on their hardware. I think you're blury about the
> story of the whole thing. Now, of course, OpenGL is indeed the
> 3D Hardware interface for quake. That kind of 'happened'.
>
> cited in early Direct3D press releases - about D3D. When he
> played with it though, he hated it, and said prefered OpenGL much
> more. I don't really think he had a master plan in mind, he just
> reacted to what he saw as a programmer.
And realised that Quake was so big that he could use it to push GL,
which is a completely fair thing to do IMO, what pisses me off is the
fact that DrawPrimitive addressed most of his problems with D3D and he
arrogantly refused to evaluate it, he just said something like 'it sucks
less but it still sucks', this is because he's ceased to be objective
and knew that he was the major force in GL ever becoming a game API, his
agenda changed.
-=< gco...@ea.com, Project Leader Bullfrog >=-
Mats Lofkvist
Jak Crow <jak...@shell3.ba.best.com> writes:
> Botton line: the customers don't give a crap what's under the
> "hood" of the game, as long as it's running on their systems with
> their hardware.
This is completely true, but also one of the big problems. In most cases
the customers don't care simply because they don't know better. It would
be a good thing if more customers listened to the developers. After all,
forcing the developers to use an inferior api will only make fewer and
worse applications in the future. This is hard for customers to see because
when all applications they try are based on the same crap, they don't
understand things could be better.
This is even more a problem because of microsofts dominance on software
for personal computers. Competition is the only way better technology
can prove itself superior. If microsoft succeeds killing opengl on the
pc, the customers will continue believing d3d is giving them the ultimate
applications for a long time.
_
Mats Lofkvist
m...@algonet.se
Thomas Womack
Rob Rodgers wrote in message <34515e06...@news.wam.umd.edu>...
>suma...@NOSPAM.usa.net (sumatose) wrote:
>>> I think Microsoft's decision to withdraw the MCD-based DDK is the main
>>> reason consumer-level cards don't have full drivers yet.
>3) If MS hadn't scuttled MCD, nobody would give a rat's ass about
>OpenGL hardware _today_.
>
>Take a look at the MCDs on NT4. They all suck.
I'm glad someone has had the same experience as me ...
Does anyone here know whether the mucked-up lighting (everything full
brightness, coloured lights appearing solid rather than colouring the
textures below them) in GLQuake2 on the Riva under NT4 is due to bugs in the
MCD, or in Quake2, or in the card implementation?
Tom
jim schaefer
David Springer (spri...@matrix.eden.com) wrote:
: In rec.games.programmer Angus Dorbie <dorbie...@asd.sgi.com> wrote:
: [incorrect rumors about DX6 clipped]
: : In stark contrast OpenGL Installable Client Drivers
: : can facilitate geometry acceleration. This is a
: : pressing requirement as low end card designs are
: : beginning to incorporate low cost parts to accelerate
: : geometry processing. It may yet transpire that
: : Microsofts move to drop MCD support for Windows 95
: : will have inadvertantly helped OpenGL by forcing some
: : IHVs to develop OpenGL Installable Client Drivers.
:
: Unfortunately this is just wishful thinking as there's still
: no indication that this massive driver development effort
: by IHV's in pursuit of OpenGL ICDs for their products
: is anything more than smoke and mirrors from SGI pundits.
: It isn't true Angus that if you say something enough times
: it will come true.
: The check is STILL in the mail... and the mail is running
: damned awful slow.
: : This setback for D3D is disapointing for IHVs and
: : ISVs using D3D given Microsofts pledge of bestowing
: : further technological advances on the industry at
: : a recent Meltdown conference. The reality is that
: : D3D in DX6 will still trail the API technology
: : curve by a long way, and Microsofts failure to deliver
: : on basic features like geometry acceleration does not
: : bode well for their API catchup strategy.
: Setback ? What the HELL are you smoking ? D3D is deployed
: and working fine on every card that makes any claim whatsoever
: to 3D acceleration while OpenGL has no acceleration support
: under Win95 for even the best of the best like Riva 128.
: Anyone that made the reasonable decision to support D3D
: with a game shipping this year can run on virtually every 3D
: accelerator card imaginable while anyone unfortunate enough
: to have picked OpenGL is sweating bullets.
except for id software, who seems rather confident that opengl will work
for them. actually it's pretty neat seeing as how many chipsets are
making opengl drivers just for quake =)
: *************** IGAMES INTERNET GAME LOBBY ****************
Rob Rodgers
"Thomas Womack" <mert...@sable.ox.ac.uk> wrote:
>Does anyone here know whether the mucked-up lighting (everything full
>brightness, coloured lights appearing solid rather than colouring the
>textures below them) in GLQuake2 on the Riva under NT4 is due to bugs in the
>MCD, or in Quake2, or in the card implementation?
Oh, god, tons of the MCD and ICD OpenGL drivers that are out there
have lots of bugs despite the glory of conformance testing they should
have received when they embraced by His Immaculate API, OpenGL.
Forget the old 3dlabs drivers which fell apart when glquake tried to
run on them (all sorts of texture anamolies, etc.). The Permedia2
still (at least on NT4) has texture map bugs, almost every MCD (like
the Riva) has real stability problems.
Sigh.
Actually, it's not that bad. At least the driver bugs can be
specifically classified as bugs and not as implementation details or
areas that are unclear in the spec. OpenGL just needs better tests,
but at least it has _something_.
(I'm a little annoyed because I've spent all morning porting from a
glut-based boilerplate to a Windows based boilerplate and for some
reasoning texture mapping is dead (the only code change involved
ripping out the glut init and replacing it with a normal windows bp
with a few calls to initgl) and I'm getting NO ERRORS AT ALL.. That's
one nice thing about d3d -- a plethora of error conditions, all
reported from almost every call...)
Paul Miller
Glenn Corpes wrote:
> which is a completely fair thing to do IMO, what pisses me off is the
> fact that DrawPrimitive addressed most of his problems with D3D and he
> arrogantly refused to evaluate it, he just said something like 'it sucks
> less but it still sucks', this is because he's ceased to be objective
> and knew that he was the major force in GL ever becoming a game API, his
> agenda changed.
Having looked at DrawPrimitive I would tend to agree with Carmack - it
does indeed "suck less", but it's ugly and still far from elegant.
If Carmack is already using an API he likes and that works for him then
why should he bother to look at it?
--
Paul Miller | st...@fxtech.com
David Springer
In rec.games.programmer jim schaefer <min...@wwa.com> wrote:
It's even neater seeing how my drivers are "being made" (check is in
the mail) and how many drivers are actually "done and working" (check has
been cashed).
Regardless, you're absolutely wrong about OpenGL drivers just for
Quake. None of them are OpenGL drivers. They are GLQuake
drivers. They are unsupported subsets of OpenGL that implement only
the functions that GLQuake actually uses.
Ask SGI if this is what they'd like to see happen to OpenGL. They
are shooting themselves in the foot (again). OpenGL is now nothing
more than a cheap hack to support Quake in the Win95 arena. This
does not bode well for OpenGL in general which is a very good
API for workstation applications.
Interestingly (embarassingly if your email address ends with sgi.com)
it appears that Id Software, while having far less influence on IHVs than
Microsoft, has more influence over IHVs than does SGI. This is uproariously
funny. Some IHVs are shoving out unsupported GLQuake drivers for Win95
while blithely ignoring SGI's fanciful wishes for fully compliant,
certified OpenGL drivers.
This dance by SGI and Id, were it not for the extra work they are
causing people, would be a classic comedy of errors. While the majority
of the world moves on and D3D is embraced as the de-facto standard for
3D game API these clowns keep up their dance, pretending that OpenGL
is a game developers API.
David Springer
--
Ross Cunniff
Mark Kilgard (m...@woodsy.engr.sgi.com) wrote:
: In article <62qqt8$j...@fcnews.fc.hp.com>, cun...@fc.hp.com (Ross Cunniff) writes:
: |>
: |> Additionally, the rasterization backend of the fx4 can handle a
: |> theoretical peak of around 8 million lit triangles per second; tell
: |> me when the CPU will be able to keep up with that while still leaving
: |> a few cycles for the application? Not by the year 2000, at least.
: InfiniteReality can sustain that rasterization rate today and actually
: has the transformation speed to indeed transform and supply that
: rate of polygons. (The theoretical peak polygon setup and rasterization
: rate for InfiniteReality is over 11 million polygons/sec.) InfiniteReality
: also has on-board display list memory (15 megabytes worth) meaning that
: you really could sustain the transformation rate that you speak of and have
: the CPU basically unloaded.
Uhh, Mark, I think you missed my point. I was saying that CPUs are not
going to be able to transform and light that many polygons any time
soon, and that's why hardware geometry processors have a lot of value.
We are violently agreeing.
By the way, Visualize fx4 *system* cost starts at $14000; how much is an
Infinite Reality :-)
Ross Cunniff
Hewlett-Packard Graphics Products Lab
cun...@fc.hp.com
Glenn Corpes
jat...@a.crl.com (Jeff Atwood) wrote:
> Hardware 3D geometry setup is a load of crap if you ask me. The cards
> that
> "have" this feature are no faster than 3dfx anyway, so a fat lot of go
> od it
Voodoo does have partial setup, there is a huge range in what the 3D
hardware actually takes, some can only draw horizontal scanlines so the
D3D or openGL driver would have to do all the work of a software
renderer except the actual scan conversion, others can only draw
trapezoids with horizontal tops and bottoms, the driver has to feed it a
start and end x and setup two slope DDAs for the edges (requiring lots
of divides) and usually needing two to draw a triangle. Others draw
triangles but the slope and DDA setup has to be done with the CPU (I
think this is where the voodoo fits), others, like permedia+delta just
take a predefined vertex structure and the hardware takes it from there,
the Riva takes this further by using D3D TLVertices directly and saving
a conversion.
> does. I've never seen a 3D game to date that was geometry-limited-- me
> aning
> the 3D models are so detailed that the CPU choked.
That's because everybody is still slightly scared of using too many
polygons because they still want to support some of the shite hardware.
Even on native glide apps, people seem to be keener to use loads of
alpha layers rather than lots of polygons, this reflects the Voodoos
real strength (awesome fill rate). Our tests under D3D seem to suggest
that Riva is almost twice as fast as Voodoo for throughput while being
only about 10% faster for fill rate. Permedia II is a similar story,
significantly slower than voodoo on fill rate but faster on throughput.
Glenn Corpes
phil...@dowco.com (Daniel Phillips) wrote:
Why?, you write an app using D3D's geometry and when the drivers can
handle geometry acceleration, your app will exploit it. The no hardware
support thing is a driver writer's issue, not a game developer's, MS are
waiting until a few more IHVs decide how they are going to do it in
hardware before they work out a way (with the IHVs) of extending D3D's
drivers to support the hardware without making the driver writers task a
huge ICD like PITA.
> Direct3D is an abortion.
You are about as in touch with D3D as Angus who posted a huge load of
ant D3D propaganda without even appreciating the difference between
geometry and setup. BTW Daniel, how's the 3D hardware support coming
along in MGL?
Glenn Corpes
abra...@pilot.msu.edu (Steve) wrote:
> DirectX, revision 6.0. Obviously the decision of Microsoft will take p
> lace
> tomorrow, October 14th, and so far the favors seem to lie at not suppo
> rting
> 3D chips processing geometry instead of the CPU. This may be based on
> Microsoft's close relationship to Intel, at least it doesn't seem too
> hard
> to guess. I guess that most of you would prefer competitors of Intel t
> o be
> able performing well in 3D applications as well, particularly as it se
> ems
Paranoid Bullshit, i've spoken to one of Intel's competitors (x86
compatible) who have added floating point matrix stuff to their next
generation processor and already have a version of DX5's geometry using
their new instructions.
sumatose
In group rec.games.programmer, Paul Miller says...
MS does still have plenty of things to fix with Direct3D, indeed.
What gets to me the most, is the startup; i.e. enumerating and
chosing the driver. Anyone who knows what 'drvmgr.cpp' is can't
but agree with this. I mentionned in another thread that DirectX
should have a 'glut', but it needs it even more than OpenGL. If
MS doesn't do anything about this in DX6, they'll still be making
excuses for the year to come.
Allen Akin
In article <3451821b...@nntp.best.com>,
Jak Crow <go-...@blow-me.com> wrote:
|
| ...SGI. The fact of the matter is, SGI was -silent- about Open
| GL for 3D game acceleration until someone outside SGI did something
| with it....
As a matter of fact, several of us at SGI spoke out about OpenGL for
games after the D3D evangelists began misrepresenting OpenGL during
their early marketing campaigns. It should be fairly easy to find my
posts on the subject if you're curious; check DejaNews.
SGI wasn't the only source, either. For example, as David Springer has
mentioned, he posted many notes suggesting subsetting and/or extending
OpenGL for games. Check the archives; it was a hot topic for a while.
Allen
Michael Maxie
David Springer <spri...@matrix.eden.com> writes:
<SNIP>
>
> Permedia 2 isn't even shipping yet and if you go read the press releases
> they're comparing its performance to a Millenium II. Its performance is
> way less than the Riva 128 (which is shipping) and its price isn't
> significantly less. I don't think Permedia 2 is going to make many
> waves. Regardless of that, you're still talking about OGL drivers that
> DO NOT exist. No one has a certified accelerated OGL driver for Win95
> and only PowerVR, Voodoo, and Voodoo Rush have even the unsupported
> QuakeGL drivers which are useless for any real OpenGL app as they
> are incomplete, uncertified, and unsupported.
>
I'm running a Permedia II (Leadtek L2300) at this moment on a 95 system.
I've yet to benchmark it, but plan on reporting some results when I get
a chance.
<SNIP>
--
Michael Maxie ma...@alf.dec.com
Software Development Tools Support 1-800-354-9000
Digital Equipment Corporation DTN: 8-343-0120
sumatose
In group rec.games.programmer, Angus Dorbie says...
> sumatose wrote:
> > 3DFX cards haven't been available for that long. [..]
>
> Drivers can be produced in large part as part of the the
> design. And low cost 3Dfx boards have been around for
> longer than you claim but perhaps not 2 years (but only
> because I don't have dates).
>
> The time to produce a driver isn't relevant to the claim
> that the HW 2 years ago wasn't up to OpenGL. Not that this
> is even a sensible claim in the first place. Consider that
> this started with a comparrison with D3D and Microsoft would
> still have you believe the line that HW isn't up to OpenGL
> and D3D is the game API..
What you say is not factual. No one cared about OpenGL. I stand
by my point that Autocad/3DStudio driver were the only thing card
manufacturers were working on.
If you prefer another opinion you have more respect for, you can
read Chris Hecker's article, he which he also said that everyone
though OpenGL was a slow pig not useful for games when Direct3D
was made.
> > It's confusing because there is 1) the GLQuake mini-driver 2)
> > 3dfxGL 3) and SGI OpenGL driver, and you say there is 4) an
> > future ICD.
>
> See there you go again, you take some inference out of context
> in your brain turn it into fact.
> Why is this confusing? If it's confusing just do what the
> shrink wrap says, you shouldn't be messing with the dlls.
I think you're reading more in my posts than there really is.
I'm trying to have an intelligent conversation while trying to
figure out exacly what 3DFX is doing.
All I'm doing is trying to find out if 3DFX is making
a) an ICD for MS-OpenGL
b) just a 'mini-driver'
c) a driver for SGI's OpenGL and it future(?) HW interface.
You either don't read this, or you believe that is not important.
(See bellow)
> You presented this as an either SGI or MS situation. This
> is a false distinction which was my point, see below.
>
> > It all looks the same, but they are very different. An OpenGL
> > driver, for example, isn't called 'opengl32.dll'. That's
> > _replacing_ opengl, not providing a driver for it to use. The
> > level of OpenGL possible compliance also varies.
>
> You say very different then you cite a dll file name ?!
> SGI's software driver has a different file name and it was
> only done this way to appease MS support concerns,
[..]
> You are inferring an inaccurate technical distinction from
> what was largely a decision about support. The SGI sdk could
> be used to produce an normal OpenGL ICD which is as
> compatible as any other ICD.
Sorry. I am not talking about opengl32.dll vs opengl.dll at all.
I am merely mentionning that the 'opengl32.dll' that 3DFX has
made available (for quake, or as 3dfxgl) isn't an ICD driver, and
can't be because it replaces OpenGL.
They have said that they weren't looking for a complete opengl-
compliant implementation for '3dfxgl'. But now they've anounced
a beta driver for SGI OpenGL.
I think these technical distinction matters a great deal, namely
to know which OpenGL features/function calls are safe to use if
the plan in to target voodoo hardware. Also, 3dfxgl is said to
only provides full-screen OpenGL, even on VoodooRush. A driver
for SGI OpenGL would in turn probably be a 100% compliant OpenGL
driver.
If 3DFX is doing an ICD (which, as you know, means an MS-OpenGL
driver) using the SGI SDK, then they have made a mistake by
presenting it as a 'driver for SGI OpenGL For Windows'. And the
extentions available are not the same.
One needs to know these 'technical distinctions' in other to plan
software development.
Allen Akin
In article <62tcji$kb9$1...@boris.eden.com>,
David Springer <spri...@matrix.eden.com> wrote:
| In rec.games.programmer jim schaefer <min...@wwa.com> wrote:
|
| : except for id software, who seems rather confident that opengl will work
| : for them. actually it's pretty neat seeing as how many chipsets are
| : making opengl drivers just for quake =)
|
| Regardless, you're absolutely wrong about OpenGL drivers just for
| Quake. None of them are OpenGL drivers. They are GLQuake
| drivers. They are unsupported subsets of OpenGL that implement only
| the functions that GLQuake actually uses.
I think David might have misinterpreted Jim's remarks, so just to
eliminate possible confusion for anyone else: There are quite a few
full OpenGL drivers reaching beta stage now (3Dfx has one in beta, for
example) and of course others are already shipping (for 3Dlabs-based
hardware, for example). Subset drivers also exist (I've heard of the
old 3Dfx glquake driver (now obsolete) and PowerVR; maybe there are
others) but I don't know of anyone actively developing new ones. SGI
is assisting chip and card vendors who plan to release full OpenGL
drivers, not subsets. I suspect Jim was saying that it's pretty neat
seeing how many chipset developers are building opengl drivers in
response to the demand for Quake; he might not have intended to imply
that the drivers were only for the Quake subset. Jim, is that right?
| Interestingly (embarassingly if your email address ends with sgi.com)
| it appears that Id Software, while having far less influence on IHVs than
| Microsoft, has more influence over IHVs than does SGI. This is uproariously
| funny. ...
It's usually true that software vendors have more influence over the
success of an API than hardware vendors. As I've mentioned before,
OpenGL exists partly because software vendors told workstation vendors
to get their act together and offer a standardized 3D API, to eliminate
market fragmentation and reduce support costs. I don't find this
embarrassing or even uproariously funny, though as usual I find David's
interpretation very creative. :-)
Allen
Allen Akin
In article <34521772...@news.wam.umd.edu>,
Rob Rodgers <kn...@acm.org> wrote:
|
| Actually, it's not that bad. At least the driver bugs can be
| specifically classified as bugs and not as implementation details or
Agreed. SGI has a set of tests that it uses in-house; we've just
started making those available to driver developers, in addition to the
conformance tests. There are still areas that need more coverage.
Allen
Allen Akin
In article <MPG.ebb153b9...@news.videotron.net>,
sumatose <suma...@NOSPAM.usa.net> wrote:
|
| I disagree. The main reason why consumer-level cars don't have
| full drivers is that 1) nobody cared about OpenGL before Carmack
I think your statement would have been more valid a year ago (though it
would have been a little too extreme). But if Microsoft hadn't axed
the MCD, there would be more full drivers now, so I would still argue
that Microsoft's action is the main reason for the lack of drivers
*today*. Subtle difference, maybe.
| ... 2) the cards being made two years ago were way to
| weak for opengl anyway. ...
You can argue that most cards being made two years ago weren't strong
enough in general, and I'd probably agree. But I think most everyone
acknowledges now that OpenGL isn't as heavyweight as the Microsoft
evangelists originally claimed. A card that's strong enough for D3D is
strong enough for OpenGL (and this is becoming even more obvious as
OpenGL features are added to D3D to improve both performance and
functionality).
| ... Also, AFAIK
| the 3DFX beta release of a full driver is for SGI OpenGL's, not
| MS-OpenGL.
I don't know for sure, but I doubt it makes much difference. If MS
isn't promoting OpenGL on Win95, why would it be important for 3Dfx to
have a driver for MS OpenGL on Win95?
Allen
sumatose
In group rec.games.programmer, Michael Maxie says...
> David Springer <spri...@matrix.eden.com> writes:
> <SNIP>
> >
> > Permedia 2 isn't even shipping yet and if you go read the press releases
> > they're comparing its performance to a Millenium II. Its performance is
> > way less than the Riva 128 (which is shipping) and its price isn't
> > significantly less. I don't think Permedia 2 is going to make many
> > waves.
>
> I've yet to benchmark it, but plan on reporting some results when I get
> a chance.
I'm fairly sure the Permedia II beats the crap out of the
Millenium II in anything except perhaps 2D. The Riva is fast,
but it isn't going anywhere with its 4 megs limit.
I think Springer should try the cards. With his job at Dell, he
should be able to get access to them without too much problems.
Javier Arevalo
"Jeff Atwood" <jat...@a.crl.com> wrote:
>I haven't seen a single game
>with dynamic LOD management, where the 3D models get less detailed (less
>polygons) as they are viewed from a distance and more detailed (more
>polygons) when they are viewed up close.
You have to look closer. This has been done for years.
Greets
Javier Arevalo
http://www.jet.es/jare
change nospam to jare in the address to send email
Glenn Corpes
phil...@dowco.com (Daniel Phillips) wrote:
> >>>I think it's now up to SGI to implement GL on Win95.
> >>
> >>You mean, since Microsoft is crippling their own implementation? We
> ll, sgi
> >>is certainly in the best position to do a good job - we should just
> be
> >>thankful they're willing to put resources into it.
> >
> >Yeah, they 'intentionally' crippled it a year before the idea
> >even came up to accelerate games with it.
>
> >Jak
>
> Well, what we are asking Microsoft to do is "intentionally" uncripple
> it,
> because we know it's easy for them to do, and it's what we want as far
> as 3D programming goes. By "we" I mean most game developers. I might
> be
> wrong on that point. I'm willing to debate it, though. Just follow a
> few
> simple guidelines:
The point of this thread was that DX6 may be incapable of exploiting
geometry hardware, correct me if i'm wrong but wouldn't a GL MCD would
be similarly incapable?.
Steve Legg
On 25 Oct 1997 19:20:19 GMT, gle...@cix.co.uk.notthisbityoumoron
(Glenn Corpes) wrote:
>phil...@dowco.com (Daniel Phillips) wrote:
>> 2) When it becomes available, applications will have to be rewritten to
>> take advantage of it.
>
>Why?, you write an app using D3D's geometry and when the drivers can
>handle geometry acceleration, your app will exploit it. The no hardware
>support thing is a driver writer's issue, not a game developer's, MS are
This is not strictly true since it is fairly easy to write
transformation/lighting code that performs MUCH better than D3D's. I
have even found that writing your own 2D clipping routines can be a
massive win.
To take advantage of hardware geometry acceleration you will need two
code paths, one using your own code and another using the higher level
D3D stuff. This is fairly messy as one path will need to deal
directly with D3DTLVERTEXs and the other with D3DVERTEXs.
> -=< gco...@ea.com, Project Leader Bullfrog >=-
sumatose
In group rec.games.programmer, Steve Legg says...
The same thing is true for OpenGL.
sumatose
In group rec.games.programmer, Daniel Phillips says...
> dir...@microsoft.com says...
> >Hardware transform and lighting incurs a much higher hardware cost to
> >implement than triangle setup, so it will be some time before this becomes
> >common in the volume PC accelerator space. Also, it's not obvious that
> >hardware vendors will spend their gate budgets pulling Direct3D's geometry
> >pipeline into their hardware. They might implement bigger caches or more
> >complex rasterization pipelines instead.
> >
> >--Nick
>
> 1) From the above, those hardware vendors who *want* to do hardware
> transform and lighting with Direct3D are out of luck.
> 2) When it becomes available, applications will have to be rewritten to
> take advantage of it.
You are either :
1) lying
2) have never use Direct3D and don't know what you're talking
about.
I'm betting both 1 and 2. What kind of respect can we have for
you when you spread lies like that all over Usenet?
Making an error in a usenet post is one thing, playing 'let's
jump on the MS guy' and using lies to push some views and trying
to lead others in errors is *disgusting*.
Daniel Phillips
suma...@NOSPAM.usa.net says...
>
>In group rec.games.programmer, Daniel Phillips says...
>> added to the growing list of anti-competitive complaints being levelled
>> at Microsoft by the DOJ? In other words, does the promotion of D3D and
>> suppression of OpenGL amount to an attempt to gain control of the 3D
>> game market?
>
>Yeah, sure, Phillips, let's put everyone that you don't like in
>jail.
>
>This is America. A company has the right to make a product, like
>an API, and promote it.
True.
>It's not anti-competive - it's competition.
That's a platitude, not a correct argument. It's anti-competitive if
a court decides it is. It's "allegedly anti-competitive" if somebody
makes that accusation. Um, are you trying to trot out your legal expertise
here?
--
Daniel Phillips
phil...@dowco.com
Jak Crow
On Fri, 24 Oct 1997 17:08:17 -0700, Angus Dorbie
<dorbie...@asd.sgi.com> wrote:
>Well, much of this is just plane inaccurate but it's
>history.
>
>I'm not interested in large contorting summaries of
>who is wearing the white hats and who is wearing the
>black. It's meaningless, unrealistic and irrelevant.
>
>I do object to the revisionism which surrounds the
>scurrilous Windows 95 MCD decision. Your willingness
>to just swallow the spin put on this by Microsoft is
>dismal.
You are hardly in a position to be objective, given that you
work for SGI. The fact of the matter is, SGI was -silent- about Open
GL for 3D game acceleration until someone outside SGI did something
with it. I think it's now up to SGI to implement GL on Win95. I mean,
you certainly don't want MS 'messing' things up right?
Jak
Email headers are false.
Please use:
jakcrow (at) werewolves (dot) org
Daniel Phillips
fa...@devnull.com says...
>
>Angus Dorbie <dorbie...@asd.sgi.com> wrote:
>
[...]
>>I'm not interested in large contorting summaries of
>>who is wearing the white hats and who is wearing the
>>black. It's meaningless, unrealistic and irrelevant.
>>
>>I do object to the revisionism which surrounds the
>>scurrilous Windows 95 MCD decision. Your willingness
>>to just swallow the spin put on this by Microsoft is
>>dismal.
>
>You are hardly in a position to be objective, given that you
>work for SGI.
That's right - attack the person instead of discussing the statement.
>The fact of the matter is, SGI was -silent- about Open
>GL for 3D game acceleration until someone outside SGI did something
>with it.
Is there supposed to be a point there? Kudo's to whoever took the
initiative, if it's true. It's obvious that sgi put a lot of
effort into following it up. Regardless, you don't seem to have made
any recognizable kind of point.
>I think it's now up to SGI to implement GL on Win95.
You mean, since Microsoft is crippling their own implementation? Well, sgi
is certainly in the best position to do a good job - we should just be
thankful they're willing to put resources into it.
>I mean, you certainly don't want MS 'messing' things up right?
>
>Jak
Jak Crow
On 25 Oct 1997 06:01:58 GMT, phil...@dowco.com (Daniel Phillips)
wrote:
>>>I do object to the revisionism which surrounds the
>>>scurrilous Windows 95 MCD decision. Your willingness
>>>to just swallow the spin put on this by Microsoft is
>>>dismal.
>>
>>You are hardly in a position to be objective, given that you
>>work for SGI.
>
>That's right - attack the person instead of discussing the statement.
Ahh, so when a person says the that the other person they are
disagreeing with is just "believing the hype", it's just okay then. I
suppose it is a way to deflect a statement too, yes?
>>The fact of the matter is, SGI was -silent- about Open
>>GL for 3D game acceleration until someone outside SGI did something
>>with it.
>
>Is there supposed to be a point there? Kudo's to whoever took the
>initiative, if it's true. It's obvious that sgi put a lot of
>effort into following it up. Regardless, you don't seem to have made
>any recognizable kind of point.
Point: The GL effort took a year and a half to become an
issue. yes? It certainly wasn't an issue until brought into the
spotlight. What people are expecting is MS to support a 3rd party
software more than their own technology in their OS. That's like
asking MS to develop Quicktime on their own.
>>I think it's now up to SGI to implement GL on Win95.
>
>You mean, since Microsoft is crippling their own implementation? Well, sgi
>is certainly in the best position to do a good job - we should just be
>thankful they're willing to put resources into it.
Yeah, they 'intentionally' crippled it a year before the idea
even came up to accelerate games with it.
Jak
Daniel Phillips
In article <3452d26...@nntp.best.com>, fa...@devnull.com says...
>
>On 25 Oct 1997 06:01:58 GMT, phil...@dowco.com (Daniel Phillips)
>wrote:
>
>>>>I do object to the revisionism which surrounds the
>>>>scurrilous Windows 95 MCD decision. Your willingness
>>>>to just swallow the spin put on this by Microsoft is
>>>>dismal.
>>>
>>>You are hardly in a position to be objective, given that you
>>>work for SGI.
>>
>>That's right - attack the person instead of discussing the statement.
>
> Ahh, so when a person says the that the other person they are
>disagreeing with is just "believing the hype", it's just okay then. I
>suppose it is a way to deflect a statement too, yes?
There are all kinds of ways to deflect statements, as you are
demonstrating, and not particularly skillfully at that. But people aren't
stupid - if you spend all your time deflecting statements you wind up with
zero credibility. Suit yourself.
>>>The fact of the matter is, SGI was -silent- about Open
>>>GL for 3D game acceleration until someone outside SGI did something
>>>with it.
>>
>>Is there supposed to be a point there? Kudo's to whoever took the
>>initiative, if it's true. It's obvious that sgi put a lot of
>>effort into following it up. Regardless, you don't seem to have made
>>any recognizable kind of point.
>
> Point: The GL effort took a year and a half to become an
>issue. yes? It certainly wasn't an issue until brought into the
>spotlight. What people are expecting is MS to support a 3rd party
>software more than their own technology in their OS. That's like
>asking MS to develop Quicktime on their own.
Well, that's a point. I disagree with it, but that's a point. There's no
point three paragraphs above - the first appearance of anything resembling
a point is in the paragraph above, no? Your dubious point, backed up with
a dubious analogy is that no company should support any software standard
that overlaps their own products, no? Well, the correct answer is: that
depends.
>>>I think it's now up to SGI to implement GL on Win95.
>>
>>You mean, since Microsoft is crippling their own implementation? Well, sgi
>>is certainly in the best position to do a good job - we should just be
>>thankful they're willing to put resources into it.
>
>Yeah, they 'intentionally' crippled it a year before the idea
>even came up to accelerate games with it.
>Jak
Well, what we are asking Microsoft to do is "intentionally" uncripple it,
because we know it's easy for them to do, and it's what we want as far
as 3D programming goes. By "we" I mean most game developers. I might be
wrong on that point. I'm willing to debate it, though. Just follow a few
simple guidelines:
- Be logical: no non-sequitors
- Be sure of your facts
- Don't throw in gratuitous flame bait if your position starts to weaken
- No personal attacks.
Please.
--
Daniel Philips
phil...@dowco.com
--
Daniel Phillips
phil...@dowco.com
David Springer
In rec.games.programmer Raist <rai...@mcs.com> wrote:
: This is very simple Jak:
: * Go to your local library (Borders/Barnes N' Nobles, etc.) and pick up a
: programming
: book on OpenGL and Direct 3D
: * Read them
: * Try to code something simple in both.
: * Compare the functionality of both.
: The whole point is that OpenGL has been time tested, is robust, is
: computer-widely
: industry accepted and has *BETTER* features than even the current Direct 3D
: 5.0.
And while you're at Barnes & Noble take a gander into the Barnes&Noble
software store and look for game titles with D3D support. There's a
bunch of them. Look for titles with OGL support - what few there are
are based on a single game engine (Quake) and can be used on exactly
two of many low cost 3D accelerators.
Additionally, the OGL support that is available under Win95 is not
really OGL support but rather an uncertified, unsupported subset of
OGL that Quake happens to use.
Your arguments sound nice but are quite disingenuous. Regardless of
how easy it is to produce a trivial work with OpenGL the reality is
proven to be (by the D3D titles shipping) that D3D is quite robust,
emminently useful, and embraced by most of the game development community
that actually has commercial works in the store shelves (as opposed
to hobbyists).
: PoweVR supports GL, as Permedia and Voodoo. Rendition is around the corner
: and Riva 128's is too.
Yeah, and the corner keeps moving... Riva's OGL ICD is months away.
I suspect it will never be certified and delivered as there's little
real demand for it. A simple GLQuake D3D wrapper will make the Quake
fanatics happy and that's ONLY subset of PC owners that gives a fig.
: What few cards? Permedia 2, PowerVR2, Riva, 3DFX and REndition covers a
: lot
: of territory. The only other worthy contender here would be ATI Xpert @
: play I guess.
Permedia 2 isn't even shipping yet and if you go read the press releases
they're comparing its performance to a Millenium II. Its performance is
way less than the Riva 128 (which is shipping) and its price isn't
significantly less. I don't think Permedia 2 is going to make many
waves. Regardless of that, you're still talking about OGL drivers that
DO NOT exist. No one has a certified accelerated OGL driver for Win95
and only PowerVR, Voodoo, and Voodoo Rush have even the unsupported
QuakeGL drivers which are useless for any real OpenGL app as they
are incomplete, uncertified, and unsupported.
: > Meanwhile,
: > there are a number of D3D titles I can go get right now,
: Which for the most part, blow flying twinkies. Monster Truck Madness? Heh,
: what
: a joke.
Compared to what ? A few programs that are derivatives of Wolfenstein 3D ?
: Unreal will be probably very good, as Forsaken and Jedi Knight. Try
: running those
: on an S3 or Mystique - or hey, the Cirrus Laguna! That should be great
: playing those
: games there right?
Try playing Quake on a Riva 128... there's some great game playing all
right. You have either use Windows NT or play it using software rendering
in Win95. Really appealing options...
: And hey, we are talking about using D3D 5.0 now that it has been released.
: Anything
: before that is pretty useless. So what you expected iD software to do?
: Wait
: for D3D to become stable? heh.
Microsoft recommended early adopters of DirectX to be those with 100
or more developers on staff. What did they expect Id to do ? I dunno,
grow into a company that's something more than a one-hit wonder ?