[Paraview] PV & multiple video cards

Tue Jun 22 20:50:44 EDT 2010

This will require the changes I communicated to the VTK ARB (see item 6)

http://public.kitware.com/pipermail/arb/2010-May/000093.html

On Tue, Jun 22, 2010 at 5:37 PM, Berk Geveci <berk.geveci at kitware.com> 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
>>
>>
>> _______________________________________________
>> 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
>


-- 
François Bertel, PhD  | Kitware Inc. Suite 204
1 (518) 371 3971 x113 | 28 Corporate Drive
                      | Clifton Park NY 12065, USA