[Bf-committers] Re: OpenGl in windowsVista ... bad news....
djcapelisp at yahoo.com
Mon Aug 8 16:06:37 CEST 2005
--- Aras Pranckevicius <nearaz at gmail.com> wrote:
> (first post to the list! :))
> > * OpenGL performance will be significantly reduced - perhaps as much as 50%
> > * OpenGL on Windows will be fixed at a vanilla version of OpenGL 1.4
> > * No extensions will be possible to expose future hardware innovations
> 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.
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. But one should remember that it's not just direct and easy traslation
of APIs if there isn't a terrible suitable alternative D3D API to match the GL
one. Then again, I don't use windows so I don't care much. To be honest
Blender's GL runs pretty fine on linux in mesa totally unaccelerated, so I
don't see why GL slowdown are even going to cause much of a problem for us. It
doesn't really affect our rendering after all, that's all scanline. ;) (We
should also note that WineX does a very good job of translating D3D -> GL,
hopefully the other way is just as fast.)
> Now, Vista should have an improved display driver model that lowers
> driver overhead significantly. So, that's lowered general driver
> overhead, but some perf hit because of GL->D3D translation. In the
> end, I wouldn't be surprised if the whole thing runs at the same speed
> as now on WinXP.
Hopefully they will cancel each other out, I think it's a bit premature to be
even worrying about it at the moment. We're kind of trying to find our way
around in the dark right now. Hard data will be available soon enough and
Vista shouldn't ship on anything real for awhile. This is a nice discussion
that might yield a plan for later, but I don't think we need to get too worried
> > It wouldn't be too hard to mimic the basic Blender lighting,
> > material and texture options with GLSL, enhancing and
> > speeding up the 'shaded display' mode quite some.
> While surely not being "trivial", this is still doable. Lighting
> computations are a piece of cake I think; the most problematic things
> are exotic textures (animated procedural anyone?) and visibility
> (shadows etc.).
> > The coding work would involve writing a sortof wrapper
> > though, to enable in Blender to set an "OpenGL Profile" to denote
> > which level of HW support you have.
> Definitely. Some sort of "viewport renderer" that can scale down to
> the older hardware. Not very hard, methinks.
Along these same lines it would be interesting to figure out if we could make
the linux versions automagically use mesa instead of accel when it's not
present. There's some library issues present with that, but can't we detect
the problem and fall-back to mesa? I kind of assumed that we had tried this at
some point, but perhaps it's the time to give a bit more thought to it.
> Aras 'NeARAZ' Pranckevicius
> http://nesnausk.org/nearaz | http://nearaz.blogspot.com
> Bf-committers mailing list
> Bf-committers at projects.blender.org
Network Security and Cryptography Researcher.
Founder of SGA
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
More information about the Bf-committers