[osg-users] OpenGL 3.1 at GDC

hannes_b at gmx.at hannes_b at gmx.at
Sat Mar 28 01:48:08 PDT 2009

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

there is more background info

and discussion with amd developer who did it

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

More information about the osg-users mailing list