GDC 2008

A place to plan OGRE-related meetings and events.
voxel
Gnome
Posts: 334
Joined: Wed Aug 02, 2006 9:27 am
Location: Toronto, Canada

GDC 2008

Post by voxel » Mon Feb 18, 2008 12:48 am

Any OGRE events at GDC? Meetups?
0 x

User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US

Post by xavier » Mon Feb 18, 2008 1:54 am

Been pretty quiet this year. I'm only going one day, not sure which one yet.
0 x
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.

voxel
Gnome
Posts: 334
Joined: Wed Aug 02, 2006 9:27 am
Location: Toronto, Canada

Post by voxel » Fri Feb 22, 2008 7:20 pm

Intel's new multi-threading demo/framework uses OGRE - includes physics, AI, scheduling, etc.

I'm very interested in getting my hands on it. It's the culimination of the Intel's threading in games research.
0 x

User avatar
FrameFever
Platinum Sponsor
Platinum Sponsor
Posts: 414
Joined: Fri Apr 27, 2007 10:05 am

Post by FrameFever » Fri Feb 29, 2008 10:48 am

do you have any screens?
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Post by sinbad » Fri Feb 29, 2008 4:31 pm

voxel wrote:Intel's new multi-threading demo/framework uses OGRE - includes physics, AI, scheduling, etc.

I'm very interested in getting my hands on it. It's the culimination of the Intel's threading in games research.
Ha, so they've finally revealed it :) I haven't seen much of it myself but I did a (very) small bit of consultancy for them when I was in California last year. I knew it was related to a new multicore setup they were working on, I guess that's the SkullTrail - they couldn't tell me anything outside of NDA at the time.
0 x

User avatar
FrameFever
Platinum Sponsor
Platinum Sponsor
Posts: 414
Joined: Fri Apr 27, 2007 10:05 am

Post by FrameFever » Fri Feb 29, 2008 7:09 pm

does this mean, because of the LGPL, they have to submit these changes to Ogre?
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Post by sinbad » Fri Feb 29, 2008 7:19 pm

As far as I'm aware they're just using Ogre as-is.
0 x

User avatar
FrameFever
Platinum Sponsor
Platinum Sponsor
Posts: 414
Joined: Fri Apr 27, 2007 10:05 am

Post by FrameFever » Fri Feb 29, 2008 8:03 pm

so they implemented multithreading without touching ogre, interesting.

I thought it would be nice to use several threads for application-traversal, cull-traversal, and the rendering.
So they used ogre "only" as one thread.
0 x

VictorMoran
Greenskin
Posts: 137
Joined: Thu Jul 12, 2007 7:04 pm

Post by VictorMoran » Fri Feb 29, 2008 8:07 pm

how did Ogre performed on the Skulltrail? Was it running on all 8 cores?
I heard that the Skull is quite mediocre as even plain quad core can outperformed.
http://hardware.slashdot.org/article.pl ... 08/1744254
When I read about it, I could not understand why is so special, to me it looks like a plain motherboard with two sockets for two multicores CPUs.
0 x

User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US

Post by xavier » Fri Feb 29, 2008 8:28 pm

FrameFever wrote:so they implemented multithreading without touching ogre, interesting.

I thought it would be nice to use several threads for application-traversal, cull-traversal, and the rendering.
So they used ogre "only" as one thread.
Most of what you are describing does no benefit typically from multithreading. Bear in mind that rendering is inherently asynchronous already -- the rendering engine sends a set of commands to the GPU, and then tells the GPU to execute those commands. The engine doesn't then sit there waiting for the render to complete.

In general, the only areas identified as suitable for multithreaded processing are particle system updates (which typically are CPU-side tasks) and sometimes animation update (if the animations are done entirely on the CPU, which increasingly, they are not).

I have implemented the engine in my project as multithreaded without touching Ogre -- Ogre runs in a separate thread, in parallel with the engine update processing (which itself can be, and usually is, multithreaded in various areas, such as physics update).

You can also implement asynchronous resource management in Ogre without changing Ogre -- it's more work to do it efficiently (the Ogre "multithreaded" option is inherently inefficient, in much the same way that the D3D multithreaded option is inefficient, and for the same reasons) but it can be done.
0 x
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.

voxel
Gnome
Posts: 334
Joined: Wed Aug 02, 2006 9:27 am
Location: Toronto, Canada

Post by voxel » Sat Mar 01, 2008 1:00 am

The core of OGRE is not multi-threaded (SceneManager, rendering, etc.)... only the higher order tasks like physics, animation, particles, etc.
0 x

User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US

Post by xavier » Sat Mar 01, 2008 2:23 am

voxel wrote:The core of OGRE is not multi-threaded (SceneManager, rendering, etc.)... only the higher order tasks like physics, animation, particles, etc.
Those are not multithreaded either. The only thread support in Ogre is for background resource loading. The problem is, turning on thread support in Ogre performs locks all over the place, which is the slow way of doing things. However, as a general-application library, Ogre cannot do it any other way (in much the same way that D3D and the MT memory managers have to do things a certain way to be generally applicable).
0 x
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.

User avatar
FrameFever
Platinum Sponsor
Platinum Sponsor
Posts: 414
Joined: Fri Apr 27, 2007 10:05 am

Post by FrameFever » Sun Mar 02, 2008 10:34 pm

In fact I read about this in a big book about computer graphics.
Ok it is in German, but there is a picture about this, which describe the solution for multiprocessor usage in a render-engine.

http://books.google.de/books?id=YEYheNS ... #PPA318,M1

does this mean, thats wrong?
0 x

User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US

Post by xavier » Mon Mar 03, 2008 2:53 am

No one is saying you can't do it. The issue is whether it's worth it, and in practice, very little of the actual rendering lends itself to concurrency. I don't have the actual Amdahl's Law equations to make the point conclusively, however.
0 x
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.

DDd
Kobold
Posts: 30
Joined: Thu Feb 28, 2008 9:04 pm

Post by DDd » Mon Mar 03, 2008 6:44 pm

any more info on that demo, is the soruce available or any whitepaper? i am googling it but if anyone can forward the info that would be very helpful.
0 x

voxel
Gnome
Posts: 334
Joined: Wed Aug 02, 2006 9:27 am
Location: Toronto, Canada

Post by voxel » Wed Mar 05, 2008 11:08 am

xavier wrote:No one is saying you can't do it. The issue is whether it's worth it, and in practice, very little of the actual rendering lends itself to concurrency. I don't have the actual Amdahl's Law equations to make the point conclusively, however.
The problem is that OGRE is not just rendering. Yes, OGRE does background resource loading but the default SceneManager also encapsulates a whole bunch of scene / world management things that could be threaded or made thread-safe.

As for rendering not leading itself to concurrency - bollocks... see RenderMan and modern GPUs. They follow the stream processing model tightly. The problem is the input to the GPU is through a command buffer (via DirectX / OpenGL) than should only be written to by a single thread.
0 x

User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US

Post by xavier » Wed Mar 05, 2008 4:21 pm

voxel wrote:
As for rendering not leading itself to concurrency - bollocks... see RenderMan and modern GPUs. They follow the stream processing model tightly. The problem is the input to the GPU is through a command buffer (via DirectX / OpenGL) than should only be written to by a single thread.
"Bollocks" is using an offline renderer as the basis for comparison. That renderer does not have to perform all of its tasks in the space of 16ms, repeatedly. There is a *HUGE* difference between using a GPU to accelerate offline rendering, and using it for real-time rendering.
0 x
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.

voxel
Gnome
Posts: 334
Joined: Wed Aug 02, 2006 9:27 am
Location: Toronto, Canada

Post by voxel » Thu Mar 06, 2008 11:16 pm

xavier wrote:
voxel wrote:
As for rendering not leading itself to concurrency - bollocks... see RenderMan and modern GPUs. They follow the stream processing model tightly. The problem is the input to the GPU is through a command buffer (via DirectX / OpenGL) than should only be written to by a single thread.
"Bollocks" is using an offline renderer as the basis for comparison. That renderer does not have to perform all of its tasks in the space of 16ms, repeatedly. There is a *HUGE* difference between using a GPU to accelerate offline rendering, and using it for real-time rendering.
I mentioned modern GPUs.

For the record, modern shading languages and GPUs are becoming more and more like RenderMan (Pixar's implementation at least) which started on hardware and is still highly parallelized.

I love OGRE, but the default SceneManager is its weakest link. Thankfully we all have access to the source.
0 x

User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US

Post by xavier » Fri Mar 07, 2008 3:18 am

You also don't have to use the default scene manager -- in fact you are encouraged not to do so for anything other than the demo apps. It's meant to be extended to suit the needs of the application.

In terms of parallel processing, you are missing the point -- GPUs are inherently massively parallel by design. It's the software parallelization that is largely without gain -- the rendering does not happen in software, it happens on the GPU, which already is parallel. As I said above, the tasks involved in getting the data ready for submission to the GPU largely do not benefit from additional parallelization, except in the select few cases I mentioned.
0 x
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.

User avatar
FrameFever
Platinum Sponsor
Platinum Sponsor
Posts: 414
Joined: Fri Apr 27, 2007 10:05 am

Post by FrameFever » Sat Mar 15, 2008 12:12 pm

I have again a question to the multithreading topic.
My experience is not big in this topic.

When I have an 8 core CPU with maybe 1.6ghz per Core, than Ogre will only use one core right? that means Ogre will use 12,5% of the CPU?
currently I have a 2,4 ghz dual core, so 2,4 ghz can Ogre use?!

Does this mean with every core on the CPU, Ogre will be slower an slower?

Or is this total bullshit?
can somebody clarify my about this?
0 x

jjp
Silver Sponsor
Silver Sponsor
Posts: 597
Joined: Sun Jan 07, 2007 11:55 pm
Location: Cologne, Germany
Contact:

Post by jjp » Sat Mar 15, 2008 1:00 pm

Single-threaded software won't be slower, it will be able to utilize less of the computational power you have available. If you substitute 2 cores with 2.4GHZ for 4 cores with 2.4GHZ speed will remain the same.
0 x
Enough is never enough.

User avatar
FrameFever
Platinum Sponsor
Platinum Sponsor
Posts: 414
Joined: Fri Apr 27, 2007 10:05 am

Post by FrameFever » Sat Mar 15, 2008 3:59 pm

this means, when I have a CPU with 32 cores with 2.4ghz, my Ogre application will run on the same speed like a dual core CPU with 2.4ghz?
0 x

jjp
Silver Sponsor
Silver Sponsor
Posts: 597
Joined: Sun Jan 07, 2007 11:55 pm
Location: Cologne, Germany
Contact:

Post by jjp » Sat Mar 15, 2008 4:23 pm

Yes. It might be a good idea to familiarize yourself with that topic. It seems as if you don't know at all what happens inbetween you writing a program and a CPU executing it :)
0 x
Enough is never enough.

User avatar
FrameFever
Platinum Sponsor
Platinum Sponsor
Posts: 414
Joined: Fri Apr 27, 2007 10:05 am

Post by FrameFever » Thu Mar 20, 2008 7:40 pm

I found a paper where they describe the multi threading implementation with Ogre.
And as fas as I can see, they are touching Ogre deep :oops:
They Multi-Threaded the D3D rendersystem. The source code should also availabe for download.

http://www.intel.com/cd/ids/developer/a ... 331359.htm

So is it worth to implement this in Ogre?
0 x

User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US

Post by xavier » Thu Mar 20, 2008 8:28 pm

Looks to be a good article. However, they present the same caveat that I've been trying to point out here:
Threading Won’t Benefit Every App
Keep in mind that threading the render system is only beneficial to applications that have a somewhat equal time spent in the application and in the graphics API modules. Being either application heavy or graphics system heavy would not see much benefit from threading.
0 x
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.

Post Reply