hi robert,
Robert Osfield wrote:
http://www.solidsmack.com/solidworks-opengl-direct3d-gpu-comparison-cad/2008-09-01/
Highlights of Autodesk Inventor OpenGL to DirectX Evolution from
“Norbert” - Autodesk Inventor Graphics Team
Interesting link to the solidworks blog about OpenGL-Direct3D, in particular
the quotes from the Autodesk/Inventor develop/marketing. Valid points are
that not al OpenGL drivers are great. But the the inference that OpenGL
does wokr in 64bit... well that's buillshit. The comment about off screen
rendering is also bullshit - kinda suggests that their OpenGL developers are
a bit incomptent if they can't use PBO's or Pbufferss. OpenGL has been
working under 64bit way before Direct3D even first developed. So.. perhaps
it's the drivers they are referrring too.. Also curiously no mention of
running on other platforms... Finally the comment about OpenGL disabling
features in consumer hardware, this is true but they are very small part of
OpenGL, and ones that the Direct3D didn't even implement.
The disabling of small set of OpenGL features is a bit of sad case of
profittering from the ATI and NVidia, if they've decreased the number of
vendors using OpenGL and these must have features then they've rather shot
themselves in the foot, or at least shot their OpenGL division in the
foot. Personally I don't use line smoothing or two side lighting too much
- does anybody here have issues with this? Or is it just the internal
driver optimization for CAD that they are referring to?
The OpenGL driver quality is the key issue underneath all of this. It's why
most of us end up recommending NVidia hardware over ATI or Intel. Which
does kinda go against one of the main points of OpenGL - it's a hardware
abstraction layer that is meant to free you from being tied to a particular
hardware device.
this really needs to be addressed, with an open letter for example or anything
else. on one side amd/ati open and support the development of open source
drivers and on the other side they cripple the usage of their hardware while
using their closed source drivers. this i really don't understand...
On the OpenCL front it'd be good to get OSG + OpenCL integration out there
with demos. Same goes for the test of the OSG - we don't really have any
full blown technology demos, just small little examples that are meant to
test and teach about very specific OSG/OpenGL features. We do have 3rd
party applications and tools that might be used a bit more actively as
technology demonstrators.
and about opencl and the cloth physics as a showcase
http://www.engadget.com/2009/03/27/havok-and-amd-show-off-opencl-with-pretty-pretty-dresses/
there is more background info
http://www.bit-tech.net/news/hardware/2009/03/20/amd-to-demo-gpu-physics-at-gdc/1
and discussion with amd developer who did it
http://forum.beyond3d.com/showthread.php?t=53336
some quotes from
mhouston System Architect, AMD
Yes, we were running Havok cloth demos on multi-core CPU as well as
GPU via OpenCL, all with the same OpenCL code underneath the Havok
API. As was said above, there is no visible difference between the
OpenCL code on either the CPU or the GPU and Havok's native code. The
dancer dances off screen if you don't have the camera follow enabled,
but the camera follow has a "bob" to it that makes some people sick
after watching it for awhile.
We had a few demos we were cycling between. All OpenCL with no
specific AMD functions or native code. I'm still partial to the
Powdertoy demo and I have probably spend more time than I should
playing with it. All in the name of debugging and optimizations.
I really hope Andrew's talk (EA) gets posted soon (the slides should
all go up in not too long) as I think it's pretty cool that he was
able to extract the Ropa cloth code used in Skate, port to OpenCL,
and throw his code at AMD and Nvidia after developing on a different
platform, and have AMD showing multi-core CPU and GPU and Nvidia
showing GPU, side by side on alpha implementations. OpenCL is a real
thing and the implementations are getting there. This year is going
to be interesting and some of us are going to be very busy.
I speak only for myself on this one, not AMD. I think that GPU
physics cannot succeed unless there is a neutral way to run on
multiple platforms. (All of the physics engines run on the CPU, but
we need a way to target GPUs and other architectures as well) Basing
physics, and other middleware, on OpenCL, DX11, or another vendor
neutral standard seems like the best way forward IMO. OpenCL has the
potential advantage that multi-core CPUs, Cell, and other
architectures can be supported under the same system and code.
(Tuning will be different for each architecture, but getting
something up and running should work if we got conformance tests
right).
Coming up with a "standard" physics package is tricky because there
is a lot of religion in how the solvers are implemented, i.e. there
is no "one solver to rule them all". Also, to get things to run well
on a GPU or a large multi-core will need exploration into algorithms
that map well to massively parallel systems and the APIs need to be
designed to batch smaller primitives together to "bulk" up the
submission to a parallel system. (If any grad students/developers are
reading this and are interested in researching this, drop me a note).
so the development is on the road...
i think a good osg demo would be great, people like to watch great stuff. ;)
best regards
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
