[Paraview] PV & multiple video cards
burlen
burlen.loring at gmail.com
Wed Jun 23 20:27:52 EDT 2010
After Francois comments I thought VTK might attempt to hide the cross
platform/ vendor/ device complexity for us inside
vtkRenderWindow::SetGPUAffinity(...). Or some such method.
> >> Perhaps you would have two options, the
> >> --number-of-gpu-per-host as you described and a something like
> >> --set-display-server-id-by-process-id.
OK. I wouldn't be surprised if you already had coded this and committed
given its triviality, if not is this something I can commit?
Burlen
Moreland, Kenneth wrote:
> I have two comments. First, I think Burlen’s original idea should be
> implemented before and potentially added independently of the Windows
> solution. Setting the display screen based on process id is pretty
> trivial. In my experience, solutions involving OpenGL extensions tend
> to be harder to implement than you think and fraught with difficulties
> to support.
>
> Second, I’m disheartened by how labyrinthine it is to control which
> GPU an OpenGL context uses. I’ll refrain from starting a Windows rant
> (and for what it’s worth, I understand Mac is just as bad). Instead,
> I’d like to point out that Kitware has been working with Microsoft’s
> HPC development to support visualization, and perhaps they could
> encourage Microsoft to provide a better solution. After all, HPC
> visualization is not really supported if you cannot make use of every
> GPU available.
>
> -Ken
>
>
> On 6/22/10 6:49 PM, "luc Renambot" <renambot at gmail.com> wrote:
>
> That would be cleanest solution, but Nvidia provides it only for
> Windows and only for Quadro cards.
>
> Luc
>
> On Jun 22, 2010, at 2:37 PM, Berk Geveci wrote:
>
> > By the way, if we wanted to go all the way on this, we would also
> > support Windows. I was told that there is an nvidia-specific function
> > that controls the GPU a context uses. I believe that it is this:
> >
> > http://developer.download.nvidia.com/opengl/specs/WGL_nv_gpu_affinity.txt
> >
> > I have no idea if ATI supports this.
> >
> > -berk
> >
> >
> > On Tue, Jun 22, 2010 at 4:16 PM, Moreland, Kenneth
> <kmorel at sandia.gov> wrote:
> >> I think this is a good suggestion. I don’t think the fact that
> it relies on
> >> processes being assigned in a particular order is a big deal.
> The default
> >> allocation is usually to place contiguous ranks in the same node
> anyway.
> >> The tiled display options also have heavy reliance on the order
> in which
> >> processes are assigned, and I don’t recall complaints about that.
> >>
> >> The only change I would suggest is to not have an option named
> >> --number-of-gpu-per-host change the display parameter. The
> option name
> >> should reflect the fact that it is going to override the display
> environment
> >> variable. Offhand, I cannot think of a single option name that
> reflects
> >> both the fact that you are changing the display and providing
> the number of
> >> screen ids to use. Perhaps you would have two options, the
> >> --number-of-gpu-per-host as you described and a something like
> >> --set-display-server-id-by-process-id. Since one does not make sense
> >> without the other, you could give an error if one is used
> independently.
> >>
> >> -Ken
> >>
> >>
> >> On 6/22/10 12:31 PM, "burlen" <burlen.loring at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> I realized that my suggestion relies on processes being assigned
> in a
> >> particular order. So something slightly more complicated would
> need to
> >> be done to determine the number of processes running on each
> host. Still
> >> it would be pretty simple way to make folks lives easier. Let me
> know
> >> what you think.
> >>
> >> Burlen
> >>
> >> burlen wrote:
> >>> Hi,
> >>>
> >>> currently we suggest users rely on details particular to
> specific MPI
> >>> implementations
> >>>
> >>>
> (http://paraview.org/Wiki/Setting_up_a_ParaView_Server#Multiple_GPUs_Per_Node)
> >>> to set up PV server on clusters with multiple graphics cards
> per node.
> >>> It seems to me that this reliance on non standard implementation
> >>> details isn't necessary for the most common case and it can
> introduce
> >>> some complication to get PV running on various installations.
> >>>
> >>> There is something simple that we could do to make users life
> easier.
> >>> ParaView could handle a common configuration of multiple graphics
> >>> cards seamlessly with very little effort via an additional command
> >>> line option.
> >>>
> >>> Two common ways to address multiple video devices in X11 via the
> >>> DISPLAY variable are, 1) by server id (":[server].0") or 2) by
> screen
> >>> id (":0.[screen]"). It depends on how X11 is setup, but I think the
> >>> latter is the most common.
> >>>
> >>> If the user were to tell PV how many video devices are available on
> >>> each node via the following command line variable, PV could assign
> >>> rendering contexts cyclically across the available devices by
> setting
> >>> the DISPLAY variable for the user.
> >>>
> >>> --number-of-gpu-per-host=N
> >>>
> >>> as each server starts he will make the computation to set the
> DISPLAY
> >>> variable so that render contexts are cycled across the
> available devices.
> >>>
> >>> For example, something like the folowing could be added to
> >>> Filters/vtkPVMain.cxx
> >>>
> >>> if (numGpuPerHost)
> >>> {
> >>> int screenId=LocalProcId%numGpuPerHost
> >>> setenv("DISPALY=:0.%i",screenId)
> >>> }
> >>>
> >>> This would conflict with the "-display" option, if both are
> present PV
> >>> would exit and print some error message.
> >>>
> >>> Do you guys think this would be a reasonable approach to handle a
> >>> common use case?
> >>> Burlen
> >>>
> >>
> >> _______________________________________________
> >> Powered by www.kitware.com
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Please keep messages on-topic and check the ParaView Wiki at:
> >> http://paraview.org/Wiki/ParaView
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> http://www.paraview.org/mailman/listinfo/paraview
> >>
> >>
> >>
> >>
> >> **** Kenneth Moreland
> >> *** Sandia National Laboratories
> >> ***********
> >> *** *** *** email: kmorel at sandia.gov
> >> ** *** ** phone: (505) 844-8919
> >> *** web: http://www.cs.unm.edu/~kmorel
> <http://www.cs.unm.edu/%7Ekmorel>
> >>
> >>
> >> _______________________________________________
> >> Powered by www.kitware.com
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Please keep messages on-topic and check the ParaView Wiki at:
> >> http://paraview.org/Wiki/ParaView
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> http://www.paraview.org/mailman/listinfo/paraview
> >>
> >>
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.paraview.org/mailman/listinfo/paraview
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://www.paraview.org/mailman/listinfo/paraview
>
>
>
>
> **** Kenneth Moreland
> *** Sandia National Laboratories
> ***********
> *** *** *** email: kmorel at sandia.gov
> ** *** ** phone: (505) 844-8919
> *** web: http://www.cs.unm.edu/~kmorel <http://www.cs.unm.edu/%7Ekmorel>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://www.paraview.org/mailman/listinfo/paraview
>
More information about the ParaView
mailing list