search

CityScope / CS_Cooper-Hewitt

meta repo/sandbox repo for keeping everything related to the Cooper Hewitt exhibition
5 stars 2 forks source link

Stress Testing Whole System [Simulation+Projection+Slider+Scanning] #83

Closed RELNO closed 5 years ago

RELNO commented 5 years ago

Now that most tools are reaching matureness, this is a place to consolidate issues regarding stress-testing the system. This will help keeping track of all things related to all/some tools not playing nice together.
Continues https://github.com/CityScope/CS_Cooper-Hewitt/issues/82 and https://github.com/CityScope/CS_Cooper-Hewitt/issues/81 and will serve for new issues arising on this matter.

RELNO commented 5 years ago

81

@LAAP Scanning, slider, and processing work very well together. As soon as unity gets into the scene, everything slows down dramatically, and (maybe by chance) the slider crashed. PS, I had tried to fix the slider, however, I also have crashed the scanner, but that is a side effect...

RELNO commented 5 years ago

82

As I have explained on issue #81, the System slows down dramatically when Unity Gets into the scene. Solutions: Improve framerate or other heavy stuff from unity, Have two computers, Others...

agrignard commented 5 years ago

You can also try to reduce a bit the number of Agent in processing to see if it has any impact. But I am not sure it will change a lot as now the number of agent are not very high but maybe

LAAP commented 5 years ago

Hi. Yesterday, the crash happened when the slider in Unity got into the scene; but Processing and the scanner were still working in a fine way. I am not 100% about anything in life, however, I can tell that Unity is very heavy and slows the machine a lot and that as soon as I clicked the "play" the slider stop working. It can be a coincidence, for sure, for sure, for sure, but... We should test all @yasushisakai options

RELNO commented 5 years ago

@LAAP @yasushisakai @popabczhang @Carsonsmuts Before we start changing settings/code inside each app, a simple workflow would be to combinatorially run pairs and then triplets of apps at the same time and see what affects what. I.e:

  1. Scanner+Slider
  2. Slider+Unity
  3. Unity+Sim
  4. Sim+ Slider+ Scanner
  5. unity+slider+scanner
  6. etc....

at a certain point, something will show up to indicate where is the FPS drop happens

popabczhang commented 5 years ago

Updates on #81 and #82:

The slowdown and crash @LAAP mentioned is mainly due to running the project the Unity editor instead of the final built app. After we switch to the built app, it ran much better along with slider, scanner, and Processing.

@yasushisakai tested and monitored the resources use when all pieces are running together and figured that CPU usage is low enough, but GPU usage is topped (which cause seldom lags). However, for some reason, only one out of two GPUs the Mac Pro has was used. We need to figure out a way to distribute the GPU load to get rid of the seldom lags without using less ideal solutions such as reducing resolution.

I did some research on how to use both GPU for Mac Pro 2013 and here's the most useful piece of information I found after searching for long:

https://forums.macrumors.com/threads/mac-pro-2013-has-apple-separated-the-dual-gpu-card-function.2071870/

goMac said: macOS hasn't been able to use both GPUs at once for graphics at once since the 2013 Mac Pro came out. It's always been one card for graphics, one card for compute since the beginning, which is how it still works now.

macrumors G4 said: Not entirely true. MacOS just cannot use multiple GPU on single monitor's graphics (e.g. Crossfire), but it can use two GPU to drive two monitors graphics. I tested it myself. I can run Unigine Valley on one screen, and Unigine Heaven on another screen, and they powered by different GPU (as per the screen capture below). This function just not available on the 2013 Mac Pro's dual GPU, but actually available in MacOS. In fact, 2013 Mac Pro may able to use multi GPU on graphics (with multiple monitor) via eGPU.

If this statement is true, we could distribute the GPU load by displaying the Processing on two projectors only (instead of across all four display) and the Unity on another projector (the 4K one). @yasushisakai @agrignard

yasushisakai commented 5 years ago

via eGPU

...Is not a option here, in terms of logistics, and place to put the eGPU box.

Is there a way to reduce the vram consumption in the unity side? Changing the resolution for the unity program didn’t change the situation.

Processing on two projectors only

Even minimizing the vram that is used by full screen Processing won’t help the situation, since it Unity consumes full vram by itself.

@Carsonsmuts and Jason, Taka was talking about a VM solution, yet there the process will be convoluted and time consuming...

For reference, Vtd for video cards weren’t supported in the current machine.

LAAP commented 5 years ago

My apologies about the latest note.

"Stress Stress Testing Whole System" should be the place to show my own personal stress.

agrignard commented 5 years ago

duplicate with #101 (needs to keep only one issue) even if a status ceck is not really an issue it's more a report.

agrignard commented 5 years ago

Closed it become to generic for a specific issue and I guess it's is now fixed 'see #101)