[Paraview] PV & multiple video cards

Wed Jun 23 11:17:31 EDT 2010

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
>>
>>
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20100623/21cbb608/attachment-0001.htm>