[Bf-committers] Re: OpenGl in windowsVista ... bad news....

[Gilbert, Joseph]

D3D is pretty fast on windows as it's optimized for windows systems and
it's close to the hardware so openGL riding d3d may not be that much
slower.
However, his is clearly part of a EEE strategy on the part of Microsoft
to squish openGL from win32 platforms. If they peg opengl at 1.4 and
keep updating direct x (or windows graphics foundation), win32
programmers will be forced to abandon opengl on win platforms to get at
the features from the latest hardware. This is especially true of video
games (which is where directx/wgf is aiming at). Since most games are
written for windows systems it would hit opengl pretty hard in this
area.

-----Original Message-----
From: bf-committers-bounces at projects.blender.org
[mailto:bf-committers-bounces at projects.blender.org] On Behalf Of Aras
Pranckevicius
Sent: Monday, August 08, 2005 10:14 AM
To: bf-blender developers
Subject: Re: [Bf-committers] Re: OpenGl in windowsVista ... bad news....

> > I really doubt about the performance part. The only overhead I see
is
> > that it's more work on the CPU side to translate from GL to D3D
> > calls/commands/whatever. The rest is performed on the video card
> > anyway, and once GL->D3D translation is done (on the CPU), the rest
> > proceeds as usual.
> 
> I think some of the concern arises from the situation where the
GL->D3D APIs
> are unequal to each other.  The fastest parts of GL will now only be
as fast
> and their D3D counterparts, we basically get each interface's slowest
sections
> and get to combine them, and that's for the parts of the API that do
match up.
> The parts of the API that do not will have advanced GL calls
translated into an
> API that may or may not actually be able to do quite the same thing,
so some
> speed also comes off there as now you're trying to hack GL features
into D3D.

Well, in the end it's the video card that does all the "real work". In
the end everything in both GL and D3D are just native videocard
command/data streams that go directly to the hardware (I'm not talking
about parts of GL that fallback to software rendering when HW isn't
present).

While there are some really exotic things that are impossible, for
example, in DX9 that are possible in GL (some limits on the shaders,
alpha-to-coverage), I don't think Blender (at least now) uses them.

> I'd continue writing, but to be terribly honest I don't know very much
about
> where the two APIs do and do not overlap and where this actually could
be a
> problem.

I'd say they're quite similar. In the end it's the same hardware that
does the work, so the APIs are just a different way to send commands
to the hardware.

-- 
Aras 'NeARAZ' Pranckevicius
http://nesnausk.org/nearaz | http://nearaz.blogspot.com
_______________________________________________
Bf-committers mailing list
Bf-committers at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-committers