Re: [osg-users] Parallel Rendering Problems using NVidia GPU cards in Windows

[Stefan Eilemann]

On 29. Jun 2012, at 21:03, WangWentao wrote:

> how about 2 same GPUs?

First one is chosen.


Stefan.

-- 
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Parallel Rendering Problems using NVidia GPU cards in Windows

[Stefan Eilemann]

On 26. Jun 2012, at 8:57, GeeKer Wang wrote:

> In fact, Windows NVidia driver will try to send OpenGL cammands to all GPU 
> when SLI model disabled.

NVidia drivers >=256.0 send the commands to the most powerful GPU and then blit 
the result to the display GPU. You can override the GPU on a per-application 
base in the control panel, afaik. On Linux this is a non-issue, as you address 
the GPUs through X screens.


Cheers,

Stefan.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [ANN] osgScaleViewer

[Stefan Eilemann]

Hi Torben,

On Tue, May 18, 2010 at 11:28 AM, Torben Dannhauer
 wrote:

> This sounds interesting! Maybe this is a better solution than my own simple 
> implementation based on osgDB::Serializer / boost::asio.

Maybe there is a potential to integrate the two projects.
osgScaleViewer does not yet distribute the scene graph itself, so
using osgDB::Serializer might be a first step. It's not clear to me
how (or if) you handle scene graph updates at run-time. The White
Paper gives a few pointers on how data distribution can be done using
Equalizer. We've done stuff like this with another SG already -- it's
just a bunch of work to write the serializers.

> I have some questions about how it works:
> a ) Is the output a single image which is constructed from all nodes image 
> parts, or is it possible to use it to project large images with very high 
> resolution to screen, using each node rendering a defined viewport of the 
> screen? (just using your datatransfer and swap control functions for cluster 
> control)

I'm not sure I understand the question. You can configure multiple
output channels, planar or non-planar, at arbitrary resolutions. The
rendering for these channels can be generated by the channels
themselves (standard multi-display rendering) or using additional
'source channels', which may have a lower resolution (scalable
rendering).

> b) Is it possible to distort with eq to project on curved screens? Something 
> like rtt -> distort with shader -> project?

Yes, although this is not implemented in Equalizer itself. There are a
couple of hooks to let you know when each output channel has the
result in its frame buffer.


Cheers,

Stefan.
-- 
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [ANN] osgScaleViewer

[Stefan Eilemann]

Hello All,

We'd like to announce the availability of osgScaleViewer, a scalable,
cluster-ready OpenSceneGraph viewer based on the Equalizer parallel
rendering toolkit.

Th integration with Equalizer offers a number of high-level features
to developers searching to develop cluster-based OSG applications,
including, but not limited, to:

- Run-time resource configuration
- Scalable rendering to aggregate multiple GPU's to render a single
  or multiple views.
- Automatic, application-transparent load-balancing of GPU's across
  multiple displays
- Support for fast data distribution based on versioned C++ objects

osgScaleViewer was initially developed by the Computer Graphics and
Multimedia Systems Group, University of Siegen and is now maintained by
the Equalizer core team. Various immersive applications have already
been developed based on this code.

Along with the public release, an accompying White Paper[1] has been
published. osgScaleViewer is part of the Equalizer distribution,
available through subversion [2].


Best,

Stefan.

[1] 
http://www.equalizergraphics.com/documents/WhitePapers/OpenSceneGraphClustering.pdf
[2] svn co https://equalizer.svn.sourceforge.net/svnroot/equalizer/trunk/src

--
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] External threads and osgViewer

[Stefan Eilemann]

Hi Robert,

On 26. Feb 2010, at 10:02, Robert Osfield wrote:

> At the end of last week I checked in a refactor of 
> OpenThreads::ReentrantMutex and Mutex so that the implementation of 
> recursive/reentrant mutex is left to the underlying threading library (i.e. 
> pthreads) rather than using OpenThreads code to attempt to implement it.   
> This refactor does away with the need to CurrentThread() etc, so code that 
> works with the standard Mutex should now work just fine the new 
> ReentrantMutex.

I was wondering about the 'interesting' approach taken by OpenThreads to 
implement a reentrant mutex, but since I didn't know the history I was 
reluctant to change it.

> Could you try the OSG-2.9.7 release of svn/trunk and see if the problem you 
> were seeing still exists?  I'm hopefully that we won't need any mods to the 
> OSG such as in your suggestion of changing the ReentrantMutex to a Mutex.

Correct, it works now without modifications to GraphicsContext.


Cheers,

Stefan.
-- 
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] External threads and osgViewer

[Stefan Eilemann]

Hi JP,

On 15. Feb 2010, at 9:00, J.P. Delport wrote:

> if I remember correctly, the ReentrantMutex came into existence because on 
> Windows the normal Mutex was reentrant (a single thread could lock it more 
> than once). So ReentrantMutex was created to make a consistent mutex on all 
> platforms...

That may be so. The issue at hand is that the ReentrantMutex on pthreads only 
works if your threads are created using OpenThreads (it uses 
Thread::CurrentThread() which requires some TLS created by Thread::start()). 
Since in my case the render threads are already running, this mutex deadlocks. 
A plain Mutex doesn't need all this and works correctly.

In this use case the mutex does not need to be reentrant. Obviously it doesn't 
hurt if it is, so imo the change is ok.


Cheers,

Stefan.
-- 
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] External threads and osgViewer

[Stefan Eilemann]

Robert, all,

I've got it running by replacing the 'ReentrantMutex
s_contextIDMapMutex' with a normal Mutex in
osg/GraphicsContext.cpp:246. I'll send you the whole file on
osg-submissions in a minute.

I'll do some more testing, and probably create an
OpenThreads::createForCurrentThread() if I hit more issues. Somebody
suggested using SceneView in an offline email to me, but I'm not sure
if this is a good approach since it is marked deprecated. Any
opinions?


Cheers,

Stefan.

-- 
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] External threads and osgViewer

[Stefan Eilemann]

Hi,

While tracking down a deadlock issue in 
osg::GraphicsContext::getCompileContext, I have reached the conclusion that I 
can't use OSGViewer if I don't use OpenThreads, due to the usage of 
Thread::CurrentThread() all over the place. Is this assessment correct?

Before I start refactoring OpenThreads to support 'plugging in' existing, 
externally created threads: Has somebody already done such a thing? Are there 
any reservations or advice regarding this work?

I'm currently investigating if transforming s_contextIDMapMutex into a Mutex 
(instead of ReentrantMutex) is enough, since it is not used 'reentrantly'. This 
might take some time due to build system issues on my end, though.


Some background: I'm working on an integration of OSG and Equalizer. We use one 
OSGViewer per GPU rendering thread. The GPU rendering threads are created by 
Equalizer before the OSGViewer is set up. This works fine as long as there is 
only one thread, otherwise the whole program deadlocks quickly in:

#0  0x91dba922 in semaphore_wait_signal_trap ()
#1  0x91dc03e6 in pthread_mutex_lock ()
#2  0x00a4bfcb in OpenThreads::ReentrantMutex::lock ()
#3  0x00a44817 in osg::GraphicsContext::getCompileContext ()
#4  0x00db1099 in osgDB::DatabasePager::requiresExternalCompileGLObjects ()
#5  0x00c94a83 in osgViewer::Renderer::flushAndCompile ()
#6  0x00c95a38 in osgViewer::Renderer::cull_draw ()
#7  0x00a475d8 in osg::GraphicsContext::runOperations ()
#8  0x00ce3e63 in osgViewer::ViewerBase::renderingTraversals ()
#9  0x5016 in Channel::frameDraw (this=0x2287200, frameID=219) at 
Channel.cpp:126

For the curious, the current code can be found in the Equalizer trunk in 
src/contrib/eqOSG (see signature).


Cheers,

Stefan.

-- 
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 4 way SLI setup

[Stefan Eilemann]

On Tue, Jan 26, 2010 at 4:37 PM, Trajce Nikolov
 wrote:
> Stefan, does this direct GPU 2 GPU transfers need the SLI to be setup ?

No, to my understanding. I haven't yet used this extension myself, but
had a close look into it.


Cheers,

Stefan.

-- 
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 4 way SLI setup

[Stefan Eilemann]

On Tue, Jan 26, 2010 at 4:25 PM, Jan Ciger  wrote:
> However, then you are on your own with
> regards to creation of contexts and moving data between cards. It will
> be also very likely slow, because the main bus will be used instead of
> the dedicated SLI interconnects.

True in the general case, but afaik the NV_copy_image extension is
supposed to do GPU-to-GPU DMAs.


HTH,

Stefan.
-- 
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 4 way SLI setup

[Stefan Eilemann]

Hi,


On Tue, Jan 26, 2010 at 2:29 PM, Trajce Nikolov
 wrote:
> I am building an IG with 4 way SLI cards. QUite a hot machine. I am
> wondering if there is a way to dedicate some of the cards to run specifics
> task. My idea is for example, card 0 to run background rendering (mostly
> render to frame buffer objects) and 3 way SLI to render the scene. Is this
> "distributed" rendering feasible?

Yes, but you have to disable SLI, at least on some cards. You can find
more information here:
http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html


HTH,

Stefan.
-- 
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Stefan Eilemann]

On 17. May 2009, at 11:11, Robert Osfield wrote:


Hi Tim,

On Sat, May 16, 2009 at 2:37 PM, Tim Moore  wrote:
I've been thinking about this too, but without the global cull.   
Are you

trying to avoid having a real scene graph on the local nodes and keep
lists of drawables and StateSets instead? I would think that  
broadcasting

the dynamic changes to the scene graph would result in less network
traffic than broadcasting lists of drawables, but I suppose it  
depends

very much on the application.


A fully distributed scene graph would probably be more efficient that
a distributed render graph approach, but it'd be more intrusive to the
scene graph design and implementation as all nodes would need an
fomarlised update mechanism.  OpenSG has such support but is a more
complicated object model than the OSG, which makes it more involved to
use and extend than the OSG.


In fact the only thing needed for this is a change notification  
mechanism. The distribution can build a 'shadow' hierarchy, and update  
the remote copies based on the notifications.


The update mechanism and serialization can live outside the scene graph.



The distributed render graph approach is lighter weight as you are
only tracking changes to the drawable leaves and state which is more
constrained and well encapsulated than other parts of the scene graph.
I believe it'll be much easier to implement this approach in a non
intrusive way than a full blow distributed scene graph, which is
really why I suggest it, we'd be able to get much of scalability of
the cluster without the complexity that normally comes with doing a
distributed application or distributed scene graph.


I'm wondering what the network load of such a distribution would be,  
and how one could cache the data. The beauty of the distributed scene  
graph is that on a static scene virtually no data has to be  
transmitted. It seems to me that the distributed render graph at least  
needs to transmit the equivalent of display list ID's.


FYI: The Equalizer source tree has an example of an OSG/Eq integration  
relying on a shared filesystem to load the SG. We are thinking of  
extending this example (and OSG) towards using a distributed OSG,  
pending on time/financing.



Best,

Stefan.

--
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] ANN: Equalizer BOF at Eurographics'09

[Stefan Eilemann]

Hi,

We will be holding an Equalizer Birds-Of-a-Feather meeting next week  
during Eurographics'09. Since the main focus turned out to be the  
integration between Equalizer and OpenSceneGraph, this might be  
interesting to some of you:


Place: Eurographics 2009, TU Munich
Date: Tuesday, March 31, 15:00-16:30
Room: MI 02.13.010

Full Schedule: 


See you there,

Stefan.

--
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] What about User-Meeting in Europe - osgInEurope?

[Stefan Eilemann]

On 19. Feb 2009, at 8:11, Adrian Egli OpenSceneGraph (3D) wrote:


Switzerland :-)


Same here - alternatively Munich work as well.


Cheers,

Stefan.

--
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] WGL_NV_gpu_affinity

[Stefan Eilemann]

On 3. Jan 2009, at 10:01, Ferdi Smit wrote:


Interesting Stefan, I didn't know that.

So how would one achieve similar effect on non-quadro cards?


To my knowledge:

1) Use Linux/OS X
2) Soft-mod your Geforce to a Quadro
3) It might be possible with ATI cards, I haven't checked that for  
some time.



Surely it must be possible to use two GPUs independently?


You can, just not with OpenGL. Cuda, OpenCL and iirc Direct3D can  
address individual GPU's.


If not, that means that multi-GPU systems are inherently broken on  
windows?


Depends on you definition of broken. For a user it is certainly good  
to be able to drag GL windows across GPU's.


Also the overhead is 'just' broadcasting GL commands to all GPU's. If  
your window covers only one GPU, the other GPU(s) will have no  
fragments to process.


Or can I setup truly independent screens in driver settings, like  
with X?


Not that I am aware of, but I'ld like to know if you find a solution.


Cheers,

Stefan.
--
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] WGL_NV_gpu_affinity

[Stefan Eilemann]

On 24. Dec 2008, at 14:10, Robert Osfield wrote:


If things are performing under Windows it's most likely a driver
issue. I can't see any reason why the way that the OSG is opening up
windows under Windows, or he lack of gpu affinity extension as being
the problem as normally the screen number and GPU attached to to the
associated physical screen should provide all the info the driver
needs to map things correctly.  Linux/X11 works just fine with just
the screen number so doesn't have any more information or controls
that would make it behave differently, so it's all down to the
driver/windowing system.

Now it might be that the NVidia drivers under windows are a bit
screwed when it comes to driving multiple displays and that one has to
add the extra extension usage to give it the kick up the butt that it
needs to do the right thing.  Try experimenting with the gpu affinity
extension see if it makes any difference.


The default under windows is that all GL commands go to all GPU's, so  
that one can drag a window across multiple GPU's.


The default on X11 is the opposite - you only see GL on the screen  
you've used to open the display connection.


The GPU affinity extension limits the GL commands to a subset of your  
GPU's. I've done tests showing that it gives you ~15% faster  
performance on a dual-GPU system. The window was only on one screen/ 
GPU. Sample code and tests can be easily done with Equalizer (see  
signature).


The extension is only available on Quadro cards, and a bit tricky to  
use. You have to create a temporary GL context to get the extension  
function pointers _on a screen driven by an nVidia card_.



HTH,

Stefan.

--
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Distributed rendering of scene graph

[Stefan Eilemann]

Benjamin, Jan,

Let me jump in with some definite answers on Equalizer.

On 1. Mar 2008, at 20:54, Benjamin Eikel wrote:

> On Saturday 01 March 2008 at 20:18:19, Jan Ciger wrote:
>> Hello Benjamin,
>>
>> Benjamin Eikel wrote:
>>> Hello Jan,
>>>
>>> thank you for your suggestion. Equalizer looks like a prebuilt  
>>> framework
>>> for simple, high-performance parallel rendering. This is not what  
>>> we are
>>> searching for, because we want to/have to implement our own  
>>> specialized
>>> rendering system.
>>
>> As far as I remember, you can plug in your own rendering and  
>> compositing
>> stages into Equalizer.
> Hello Jan,
>
> okay, this might be something that we could use. I have only skimmed  
> through
> the web page and the programming guide so maybe I missed something.  
> The
> problem that I see is that maybe other functions which are provided by
> OpenSceneGraph are not supported by Equalizer (loading from  
> different file
> formats, picking/dragging, animation pathes).

Equalizer is a parallel rendering framework, in the same sense as MPI  
is a parallel programming framework. File loading, picking, etc. are  
application-specific problema, and outside of the scope of Equalizer.  
Equalizer does not prevent implementing these, and where it makes  
sense it will aid these functions.

File loading for example would be done, as I understand, on your  
application node. The resulting scenegraph will then be distributed to  
your render clients. This is something we have already done with  
another scene graph.

Picking and event handling in general are areas where Equalizer helps  
the application. For example, events are sent to the application node  
by default.

Data distribution for OSG is something which has been requested a  
number of times, just nobody stepped forward and did it so far (or  
paid for it). I am sure this work would give you a good reward, and I  
can help with the details.

Equalizer gives you a framework into which you plug your  
applications' (rendering) code. If you have something which doesn't  
fit, let us know and we'll find a solution.

> Furthermore if we want to write
> our own rendering and composition algorithm what is left for  
> Equalizer to do
> for us?

What exactly do you have in mind? It seems that if you want to  
implement your own parallel rendering algorithms, the right way would  
be to modify Equalizer. You are of course welcome to contribute.

> I think the effort getting used to it and integrating it in our
> system would be too high in comparison to the earnings.

The effort to relearn the lessons we learned by doing two parallel  
rendering frameworks is high as well.

>> Sometimes it is better to start from something working than from
>> scratch, even though it is tempting to reinvent the wheel (I am/was  
>> in
>> academia too).
> Yes that is right. That is why we want to use OpenSceneGraph.

An integration of OSG with Equalizer is a new thing. Furthermore it  
builds new value (rather than redoing existing things), and would add  
value to both projects.

Cross-posting to eq-dev. Feel free to direct Equalizer-specific  
questions to this list.


Cheers,

Stefan.
-- 
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org