[Paraview] PV & multiple video cards

[burlen]

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
>