Re: [osg-users] osg apps on gpu cluster

[Per Nordqvist]

Hello Chris, thanks for chipping in.

I and Nick are working to utilize as much of the GPUs as possible, either
on single machine or cluster.
So hardware is not yet decided, but let's assume ubuntu 16+, multiple
modern Nvidia gaming cards, but still single screen.

Cheers
Per

On Mon, 1 Oct 2018, 21:22 Chris Hanson,  wrote:

> I think Robert advised me on tweaking this probably 4 years ago for a
> Windows system with 16 display outputs all running from one EXE, ensuring
> there were the proper number of contexts and threads all playing nicely so
> as not to jam up the bus.
>
> What's your hardware profile look like? Which Linux OS? What CPUs and how
> many, what display cards, and how many, how many outputs, etc. The exact
> best mechanism may not be invariant across all situations.
>
> On Mon, Oct 1, 2018 at 7:43 PM Trajce Nikolov NICK <
> trajce.nikolov.n...@gmail.com> wrote:
>
>> Hi Community,
>>
>> I am totally new to this topic and that is the reason I am pinging you
>> this time. Anyone with some experience or hints? I am after running (Linux)
>> osg app N times so each app to have dedicated GPU, something in this
>> fashion.
>>
>> I will investigate this too, but any word from you is highly appreciated.
>>
>> Thanks a bunch as always!
>>
>> Cheers,
>> Nick
>>
>> --
>> trajce nikolov nick
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> --
> Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
> http://www.alphapixel.com/
> Training • Consulting • Contracting
> 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4
> • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
> Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
> osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
> iPhone/iPad/iOS • Android
> @alphapixel  facebook.com/alphapixel (775)
> 623-PIXL [7495]
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Problems porting from osg-3.4.0 to osg-3.6.0

[Herman Varma]

Hi,


I have encountered another problem. what is the replacement for 
_boundingBoxComputed in osg-3.6.2

in osg-3.4.0
It was defined in osg\Drawable


BoundingBox _initialBound;
ref_ptr _computeBoundCallback;
mutable BoundingBox _boundingBox;
mutable bool  _boundingBoxComputed;

in osg-3.6.2
it  is not defined in osg\Drawable

BoundingBox  _initialBoundingBox;
ref_ptr_computeBoundingBoxCallback;
mutable BoundingBox _boundingBox;



The code to be ported is

osg::BoundingBox OsgDynMesh::computeBoundingBox() const
{
FBox3 box;
m_pDynGeom->DoCalcBoundBox(box);

// convert it to OSG bounds
v2s(box.min, _boundingBox._min);
v2s(box.max, _boundingBox._max);

_boundingBoxComputed=true;
return _boundingBox;
}

Thank you!

Cheers,
Herman

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75006#75006





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

[osg-users] Resizing FBO camera while rendering

[Rômulo Cerqueira]

Hi,

I have rendered a FBO camera to image by using a callback (as seen in the code 
below), however some OpenGL warnings/erros are raised when I resize at runtime 
by setupViewer() method. I debugged the code by using 


Code:
export OSG_GL_ERROR_CHECKING=ON 



and got the following error:


Code:
Warning: detected OpenGL error 'invalid operation' after applying attribute 
Viewport 0x7fb35406e500



How can I properly do the resizing of my FBO camera?



Code:
// create a RTT (render to texture) camera
osg::Camera *ImageViewerCaptureTool::createRTTCamera(osg::Camera* cam, 
osg::Camera::BufferComponent buffer, osg::Texture2D *tex, osg::GraphicsContext 
*gfxc)
{
osg::ref_ptr camera = cam;
camera->setClearColor(osg::Vec4(0, 0, 0, 1));
camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
camera->setRenderOrder(osg::Camera::PRE_RENDER, 0);
camera->setViewport(0, 0, tex->getTextureWidth(), tex->getTextureHeight());
camera->setGraphicsContext(gfxc);
camera->setDrawBuffer(GL_FRONT);
camera->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
camera->attach(buffer, tex);
return camera.release();
}

// create float textures to be rendered in FBO
osg::Texture2D* ImageViewerCaptureTool::createFloatTexture(uint width, uint 
height)
{
osg::ref_ptr tex2D = new osg::Texture2D;
tex2D->setTextureSize( width, height );
tex2D->setInternalFormat( GL_RGB32F_ARB );
tex2D->setSourceFormat( GL_RGBA );
tex2D->setSourceType( GL_FLOAT );
tex2D->setResizeNonPowerOfTwoHint( false );
tex2D->setFilter( osg::Texture2D::MIN_FILTER, osg::Texture2D::LINEAR );
tex2D->setFilter( osg::Texture2D::MAG_FILTER, osg::Texture2D::LINEAR );
return tex2D.release();
}

void ImageViewerCaptureTool::setupViewer(uint width, uint height, double fovY)
{
// set graphics contexts
osg::ref_ptr traits = new 
osg::GraphicsContext::Traits;
traits->x = 0;
traits->y = 0;
traits->width = width;
traits->height = height;
traits->pbuffer = true;
traits->readDISPLAY();
osg::ref_ptr gfxc = 
osg::GraphicsContext::createGraphicsContext(traits.get());

// set the main camera
_viewer = new osgViewer::Viewer;
osg::ref_ptr tex = createFloatTexture(width, height);
osg::ref_ptr cam = createRTTCamera(_viewer->getCamera(), 
osg::Camera::COLOR_BUFFER0, tex, gfxc);
cam->setProjectionMatrixAsPerspective(osg::RadiansToDegrees(fovY), (width * 
1.0 / height), 0.1, 1000);

// render texture to image
_capture = new WindowCaptureScreen(gfxc, tex);
cam->setFinalDrawCallback(_capture);
}

osg::ref_ptr 
ImageViewerCaptureTool::grabImage(osg::ref_ptr node)
{
// set the current node
_viewer->setSceneData(node);

// if the view matrix is invalid (NaN), use the identity
if (_viewer->getCamera()->getViewMatrix().isNaN())
_viewer->getCamera()->setViewMatrix(osg::Matrixd::identity());

// grab the current frame
_viewer->frame();
return _capture->captureImage();
}


WindowCaptureScreen METHODS


WindowCaptureScreen::WindowCaptureScreen(osg::ref_ptr 
gfxc, osg::Texture2D* tex) {
_mutex = new OpenThreads::Mutex();
_condition = new OpenThreads::Condition();
_image = new osg::Image();

// checks the GraficContext from the camera viewer
if (gfxc->getTraits()) {
_tex = tex;
int width = gfxc->getTraits()->width;
int height = gfxc->getTraits()->height;
_image->allocateImage(width, height, 1, GL_RGBA, GL_FLOAT);
}
}

WindowCaptureScreen::~WindowCaptureScreen() {
delete (_condition);
delete (_mutex);
}

osg::ref_ptr WindowCaptureScreen::captureImage() {
//wait to finish the capture image in call back
_condition->wait(_mutex);
return _image;
}

void WindowCaptureScreen::operator ()(osg::RenderInfo& renderInfo) const {
osg::ref_ptr gfxc = 
renderInfo.getState()->getGraphicsContext();

if (gfxc->getTraits()) {
_mutex->lock();

// read the color buffer as 32-bit floating point
renderInfo.getState()->applyTextureAttribute(0, _tex);
_image->readImageFromCurrentTexture(renderInfo.getContextID(), true, 
GL_FLOAT);

// grants the access to image
_condition->signal();
_mutex->unlock();
}
}



... 

Thanks in advance,

Cheers,
Rômulo

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75005#75005





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

Re: [osg-users] Moving from 3.4.1 to 3.5.7 breaks my "hardware instancing"

[Julien Valentin]

Hi 
is osgdrawinstanced example working as expected?
What's your configuration specificities (gpu driver, plateform...)?
cheers


loopy wrote:
> Hi,
> I upgraded from 3.4.1 to 3.5.7 and my code that uses "hardware instancing" 
> (to render a large number of simple geometry) renders nothing now.
> 
> I had no need to make any source code changes  when I updated, and other 
> parts of the code that uses vertex/fragment shaders works fine. I am 
> wondering what could have changed to break this code?
> 
> The outline is that I have a class that inherits from Drawable and overrides 
> drawImplementation/computeBoundingBox/supports/accept
> I am adding a VertexAttribDivisor to the Program
> 
> OSG_NOTIFY_LEVEL=DEBUG shows nothing interesting.
> 
> Any ideas where I should start looking?
> 
> Andrew



Twirling twirling twirling toward freedom

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75004#75004





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

Re: [osg-users] osg apps on gpu cluster

[Chris Hanson]

I think Robert advised me on tweaking this probably 4 years ago for a
Windows system with 16 display outputs all running from one EXE, ensuring
there were the proper number of contexts and threads all playing nicely so
as not to jam up the bus.

What's your hardware profile look like? Which Linux OS? What CPUs and how
many, what display cards, and how many, how many outputs, etc. The exact
best mechanism may not be invariant across all situations.

On Mon, Oct 1, 2018 at 7:43 PM Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:

> Hi Community,
>
> I am totally new to this topic and that is the reason I am pinging you
> this time. Anyone with some experience or hints? I am after running (Linux)
> osg app N times so each app to have dedicated GPU, something in this
> fashion.
>
> I will investigate this too, but any word from you is highly appreciated.
>
> Thanks a bunch as always!
>
> Cheers,
> Nick
>
> --
> trajce nikolov nick
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osg apps on gpu cluster

[Trajce Nikolov NICK]

Hi Community,

I am totally new to this topic and that is the reason I am pinging you this
time. Anyone with some experience or hints? I am after running (Linux) osg
app N times so each app to have dedicated GPU, something in this fashion.

I will investigate this too, but any word from you is highly appreciated.

Thanks a bunch as always!

Cheers,
Nick

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

[osg-users] Latency

[David Heitbrink]

I currently have an odd problem I am stuck on. I have a system with 2 Quadro 
P5000 cards- driving 3 displays that are warped and blended on a 120 degree 
dome. Running Windows 10.  The application is ground vehicle simulation -  I 
have pretty high rates of optical flow. Each display is running its own 
process, they receive a UDP broadcast with position update information. What I 
am seeing is 1 of the displays is off by 1 frame 95% of the time. When this 
happensmy blending fails and I get a large seam in my scene. I added 
logging as to the eye point position as well as high frequency counter time. 

>From what I can tell from the logs, the return from the VSync's 
>(viewer->frame() ) are all within 200 microseconds, and the eye point position 
>and data frame number (i.e. the frame number for my incoming data) is the same 
>across all of the channels. 

So I strongly suspect this has something to do with the graphics card/driver's 
own internal frame bufferingand there is not a lot I can do about it. 

This leaves me with a couple of real issues.
1) Programmatically cannot tell if a channel is a frame behind or not. 
Basically I added buffering for the other 2 channels for position 
information..and my seam goes away 95% of the time
2) Since things are not 100% the same...I randomly get a seam 5% of the 
time (assuming I am buffering).

At this point I don't know what to do.I have talked to NVidia about this, 
they mentioned making sure DPI scaling in windows is set to 100% and/or setting 
up the app to be DPI aware. I have done this.but I get the same result.


Any advice and/or speculative guesses on this would be great.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75001#75001





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

[osg-users] Moving from 3.4.1 to 3.5.7 breaks my "hardware instancing"

[Andrew Cunningham]

Hi,
I upgraded from 3.4.1 to 3.5.7 and my code that uses "hardware instancing" (to 
render a large number of simple geometry) renders nothing now.

I had no need to make any source code changes  when I updated, and other parts 
of the code that uses vertex/fragment shaders works fine. I am wondering what 
could have changed to break this code?

The outline is that I have a class that inherits from Drawable and overrides 
drawImplementation/computeBoundingBox/supports/accept
I am adding a VertexAttribDivisor to the Program

OSG_NOTIFY_LEVEL=DEBUG shows nothing interesting.

Any ideas where I should start looking?

Andrew

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75000#75000





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