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

[Aras Pranckevicius]

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