Thanks Guys,
for your detailed insight. I'll be going with the GLX_VENDOR route since I have
temporary display connections anyways to probe for available GPUs.
Cheers,
Stefan.
--
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann
--
On 22. Dec 2011, at 17:51, DRC wrote:
>> Setup is a 3-GPU 'VGL-served' machine. With VGL present, I want:
>>
>> - two offscreen renderers using :0.1 and :0.2 contributing to:
>> - one on-screen renderer rendering and assembling :0.1 and :0.2 using the
>> forwarded DISPLAY (:10.0, redirected to
Hi DRC,
Since I cant comment on a closed bug, I'll do it here:
Begin forwarded message:
> Initial Comment:
> Not sure if it's a bug, but:
>
> I have an application using multiple GPUs. There are nGPU + 1 display
> connections. The nGPU ones use :0.n, and the +1 uses the ssh X11 forwarding
> (
On 12/23/11 2:43 AM, Stefan Eilemann wrote:
>> Why not just have your application putenv("VGL_READBACK=0")? That
>> prevents VirtualGL from reading back and sending frames, if you have
>> other means of doing that. You could, for instance, wrap a
>> glXSwapBuffers() call around which you don't wa
On 12/23/11 2:54 AM, Stefan Eilemann wrote:
> Since I cant comment on a closed bug, I'll do it here:
I apologize for the lameness of the SourceForge bug tracker.
"Close comment posting" is unchecked, so I'm not sure why it isn't
letting you comment. In theory at least, it should still be open f
On 22.12.2011 17:51, DRC wrote:
> This is a common technique when using VirtualGL with Chromium and
> ParaView, although in those cases, the rendering is split up among
> multiple processes, so VGL_READBACK=0 is set in the launch scripts
> for
> the sub-renderers rather than being set in the main
On 12/23/11 9:24 AM, Arthur Huillet wrote:
> Doesn't "vglrun pvserver" work out of the box however?
> Why is this technique needed, then?
Back when we were working with it, which was years ago, the subrenderers
were using windows, so we wanted to run each subrenderer in VirtualGL to
redirect the r
On 23. Dec 2011, at 15:59, DRC wrote:
> I still am not understanding why you would need the app to behave
> differently if VirtualGL is present. If it's using Pbuffers/FBO's for
> the subrenderers, then where/why is the "extra readback" occurring?
My server is a 3-GPU system. When running with
On 23. Dec 2011, at 16:22, DRC wrote:
> However, if you're calling glXMakeCurrent() on non-visible windows
> (why?), then that would explain the behavior you're seeing.
Each Eq render thread has its own display connection and GL context. Off-screen
FBO windows need to call glXMakeCurrent, which
On 23.12.2011 16:59, DRC wrote:
> On 12/23/11 9:24 AM, Arthur Huillet wrote:
>> Doesn't "vglrun pvserver" work out of the box however?
>> Why is this technique needed, then?
>
> Back when we were working with it, which was years ago, the
> subrenderers
> were using windows, so we wanted to run eac
On 12/23/11 10:46 AM, Arthur Huillet wrote:
> As far as I know they still draw to visible windows. (I wonder why...
> is there any technical reason to do so?)
>
> So I guess the case you describe is still applicable, however I know
> for having experimented it that "vglrun pvserver" does work. D
On 12/23/11 10:25 AM, Stefan Eilemann wrote:
> Each Eq render thread has its own display connection and GL context.
> Off-screen FBO windows need to call glXMakeCurrent, which requires a window
> ID. Hence the hack to have an invisible window to make the context current
> and then bind the rende
12 matches
Mail list logo
