Re: [eq-dev] IPP and GBuffer generation and usage
5 views
Skip to first unread message
Stefan Eilemann
May 4, 2011, 2:47:55 AM5/4/11
to eq-...@equalizergraphics.com
Hi,
On 3. May 2011, at 22:10, erij89 [via Software] wrote:
> I'm new here and I have a few general questions in order to figure out if Equalizer is applicable for what we want to use it for.
Welcome! The goal of Equalizer is to solve the *generic* problems of writing a parallel and potentially distributed OpenGL application. If it is not applicable, we should figure out why and change it. ;)
> We are trying to build an out-of-core rendering server (stateless!) that should be able to generate different GBuffers depending on the request (Query String). Those GBuffers are e.g. color, depth, objectID images of a particular view. The rendered image should be postprocessed - if needed.
> We are currently using osg for that and a pp-library that works directly on the imagedata on the gpu.
Just to make sure: The render server delivers the GBuffers to the client, not simply a rendered image - correct?
> So if we would split the image, so that a quarter of it would be rendered on a different gpu/pc we would not have the data of the pixels right next to the splitting area. Is there an easy way to enlargen the area each gpu renderes (so that there are enough pixels beyond the corners) and after that, put the image together?
From my current understanding I would first assemble the partial images on the destination, and then run the pp on it. My assumption here is that the pp does not reduce the amount of data. If it does, it might be worthwhile to do the pp on the source channels.
> Is there an easy way to use our existing osg code with shaders that genereate the pbuffers for every Node?
Yes, just do it. :)
Of course there might be details to work out, but in the draw task method you have native access to a GL context. Have a look at osgScaleViewer for OSG integration.
> The most important thing is - if splitting an image - if it would be possible to put it back together, even if there are 3-4 representations of the same image (color, depth, normals, objectid) ?
You would have to write your own implementation of Channel::frameReadback and Channel::frameAssemble to read and assemble the different representations using the correct source/destination, but this is hardly rocket science.
> We are using mutliple GB of Model files and Texture data. Can all Equalizer-Nodes that that data, so that it would not have to be loaded multiple times (if using one pc)?
One one PC you would only configure one node (process) with n pipe (threads), one for each GPU. The pipe threads naturally have access to shared data.
HTH,
Stefan.
View this message in context: Re: IPP and GBuffer generation and usage
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
On 3. May 2011, at 22:10, erij89 [via Software] wrote:
> I'm new here and I have a few general questions in order to figure out if Equalizer is applicable for what we want to use it for.
Welcome! The goal of Equalizer is to solve the *generic* problems of writing a parallel and potentially distributed OpenGL application. If it is not applicable, we should figure out why and change it. ;)
> We are trying to build an out-of-core rendering server (stateless!) that should be able to generate different GBuffers depending on the request (Query String). Those GBuffers are e.g. color, depth, objectID images of a particular view. The rendered image should be postprocessed - if needed.
> We are currently using osg for that and a pp-library that works directly on the imagedata on the gpu.
Just to make sure: The render server delivers the GBuffers to the client, not simply a rendered image - correct?
> So if we would split the image, so that a quarter of it would be rendered on a different gpu/pc we would not have the data of the pixels right next to the splitting area. Is there an easy way to enlargen the area each gpu renderes (so that there are enough pixels beyond the corners) and after that, put the image together?
From my current understanding I would first assemble the partial images on the destination, and then run the pp on it. My assumption here is that the pp does not reduce the amount of data. If it does, it might be worthwhile to do the pp on the source channels.
> Is there an easy way to use our existing osg code with shaders that genereate the pbuffers for every Node?
Yes, just do it. :)
Of course there might be details to work out, but in the draw task method you have native access to a GL context. Have a look at osgScaleViewer for OSG integration.
> The most important thing is - if splitting an image - if it would be possible to put it back together, even if there are 3-4 representations of the same image (color, depth, normals, objectid) ?
You would have to write your own implementation of Channel::frameReadback and Channel::frameAssemble to read and assemble the different representations using the correct source/destination, but this is hardly rocket science.
> We are using mutliple GB of Model files and Texture data. Can all Equalizer-Nodes that that data, so that it would not have to be loaded multiple times (if using one pc)?
One one PC you would only configure one node (process) with n pipe (threads), one for each GPU. The pipe threads naturally have access to shared data.
HTH,
Stefan.
View this message in context: Re: IPP and GBuffer generation and usage
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
Stefan Eilemann
May 11, 2011, 2:29:53 PM5/11/11
to eq-...@equalizergraphics.com
On 11. May 2011, at 12:50, erij89 [via Software] wrote:
> Now I created a class that subclasses eq::Window. The problem is, that it creates a window by itself. But I want it to be an offscreen renderer that does not read its size from the EqualizerConfig since it has to be adjustible at runtime.
What does it do with the result?
> Is it necessary to have my eq::Window subclass hold an osgViewer::Viewer or can I just subclass both osgViewer::Viewer and eq::Window in one class and adjust my pbuffer settings in order to get an offscreen viewer and prevent Equalizer from initializing a window?
The glue to the operation system is in SystemWindow and its derived classes AGL/WGL/GLXWindow. You can subclass these, overwrite configInitFOODrawable and create your PBuffer there. You might have to call setPixelViewport to let Eq now about your change.
Stefan Eilemann
May 12, 2011, 5:18:17 AM5/12/11
to eq-...@equalizergraphics.com
On 12. May 2011, at 11:13, erij89 [via Software] wrote:
> But there is still one problem left. I don't need to handle the windowing events anymore if that window is gone. However, the WGLMessagePump is still processed and CommandQueue::pop() causes a debug exception and it says that pop() is called from two different threads.
> Is there a way to disable event managing for my eq::Window ?
That's in the Programming Guide. See Pipe::useMessagePump.
Stefan Eilemann
May 17, 2011, 3:25:57 PM5/17/11
to eq-...@equalizergraphics.com
Hi,
On 17. May 2011, at 13:28, erij89 [via Software] wrote:
> I get an unhandled exception in:
>
> Server::chooseConfig
> getClient->processCommand()
>
> There, pop is called on the CommandQueue. But that Queue is empty.
That should not happen - the exception, not the queue empty. CQ::pop is a blocking operation and the queue is quite often empty.
What kind of exception do you get? Can you build with debugging symbols and/or without optimizations to get more information?
Cheers,
On 17. May 2011, at 13:28, erij89 [via Software] wrote:
> I get an unhandled exception in:
>
> Server::chooseConfig
> getClient->processCommand()
>
> There, pop is called on the CommandQueue. But that Queue is empty.
That should not happen - the exception, not the queue empty. CQ::pop is a blocking operation and the queue is quite often empty.
What kind of exception do you get? Can you build with debugging symbols and/or without optimizations to get more information?
Cheers,
Stefan Eilemann
May 24, 2011, 1:18:57 PM5/24/11
to eq-...@equalizergraphics.com
On 24. May 2011, at 11:08, erij89 [via Software] wrote:
> It seems that the return value of getMainThreadQueue(); is invalid.
That is highly unlikely, since the main thread queue is a member of eq::Client - don't you have a way of debugging this properly instead of guessworking?
HTH,
Reply all
Reply to author
Forward
0 new messages