D3D disappoints again (D3D 'setup' in DX6)

D3D disappoints again (D3D 'setup' in DX6)

Post by Angus Dorbi » Thu, 23 Oct 1997 04:00:00



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.

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.

 
 
 

D3D disappoints again (D3D 'setup' in DX6)

Post by Angus Dorbi » Thu, 23 Oct 1997 04:00:00




> >[...] 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.

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.

 
 
 

D3D disappoints again (D3D 'setup' in DX6)

Post by Carl Muell » Fri, 24 Oct 1997 04:00:00



>[...] 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.

Quote:>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.

 
 
 

D3D disappoints again (D3D 'setup' in DX6)

Post by Angus Dorbi » Fri, 24 Oct 1997 04:00:00



> On Wed, 22 Oct 1997 21:34:39 -0700, Angus Dorbie

> >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.

>         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.

 
 
 

D3D disappoints again (D3D 'setup' in DX6)

Post by Per Burstro » Fri, 24 Oct 1997 04:00:00


..........

Quote:> 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

 
 
 

D3D disappoints again (D3D 'setup' in DX6)

Post by Gary Taroll » Fri, 24 Oct 1997 04:00:00



> 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.

> 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.

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....

 
 
 

D3D disappoints again (D3D 'setup' in DX6)

Post by Angus Dorbi » Fri, 24 Oct 1997 04:00:00




> > 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.

> > 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.

> 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....

...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.

 
 
 

D3D disappoints again (D3D 'setup' in DX6)

Post by David Springe » Fri, 24 Oct 1997 04:00:00



: 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 ******************

 
 
 

D3D disappoints again (D3D 'setup' in DX6)

Post by Angus Dorbi » Fri, 24 Oct 1997 04:00:00





> > > 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....

> > ...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.

> somewhat correct...

> > 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.

> well you can say that about all processing....actually we
> 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.
> > 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.

> I have some background in vis. sim too, not professional, but
> 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.

> Depends on what databases you are using...entertainment
> 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.

- Show quoted text -

Quote:>..  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.

 
 
 

D3D disappoints again (D3D 'setup' in DX6)

Post by sumato » Fri, 24 Oct 1997 04:00:00


In group rec.games.programmer, Steve says...

Quote:> 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 *, 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. %-)

 
 
 

D3D disappoints again (D3D 'setup' in DX6)

Post by David Matiskell » Fri, 24 Oct 1997 04:00:00





> > On Wed, 22 Oct 1997 21:34:39 -0700, Angus Dorbie

> > >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.

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

 
 
 

D3D disappoints again (D3D 'setup' in DX6)

Post by Howard Stroy » Fri, 24 Oct 1997 04:00:00


: ...........

: > 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/Visuali...>

--
Howard Stroyan                                                  (970)229-3317
Hewlett-Packard                                             fax (970)229-6318

 
 
 

1. PC Hardware (Yes Again, it's to ask AGAIN!)

Hello, I've asked this question before and now I feel it's time to ask it
again. Why? Because there have been signicant changes in the hardware
market to warrent me asking this quesiton again to the pros.

Ok, question. I was thinking about:
  1) dropping the 386 machine completely and only support the 486/DX
machines.
  2) require a minimum of 8megs of memory.
  3) must have a SVGA card with 1meg ram.
  4) must have a hard disk.

Now, am i being reasonable? I think I am. I look at the PC being sold now
and they come with a minimum of 8megs of ram,thanks to memory hungry OS
like windoze, nt, os/2 and maybe even dos. Do you guys think I'll loose
a considerable amount of the market share, in both shareware and
commercial markets.

Hey this time someone answser and what ever happened to DrCat?

thanks,
Ms. Erica A. Ramsey

2. Calendar and Tasks support in own Message Store Provider

3. Window'ed applications and D3D

4. RSI Announces IDL for Mac OS X

5. Can't get LoadTextureFromResource() in D3D to work...

6. Where is a list of Cisco Certified Consultants?

7. Making OpenGL and D3D's geometry engines work off the same data.

8. Upgrade from NT4 and PERC RAID problem

9. Trouble's making a face :( (Delphi / D3D)

10. D3D UV's

11. Question about d3d's DrawIndexedPrimitive

12. I'm stuck with d3d fog, please help

13. Help: D3D Setup