unit tests: limiting maximum memory usage

[anholt]

In order to complete the unit tests in a reasonable amount of time on low-end boards, I'd like to parallelize them. However, this runs into OOMkiller trouble with the larger resolutions being tested. My questions I have so far:

• I'm seeing 8k and 10k being allocated with 10 surfaces from CreateSurfaces -- is 10 a reasonable number of surfaces to need for all entrypoints?
• Could we clamp surface creation to getMinMaxSurfaceResolution()?
• Could we bake resolution name into test names so I can either filter out the large resolutions, or test them single-threaded?

[XinfengZhang]

hi @uartie , suppose you are more familiar with this part. please help to check these question . thanks

[uartie]

In order to complete the unit tests in a reasonable amount of time on low-end boards, I'd like to parallelize them. However, this runs into OOMkiller trouble with the larger resolutions being tested. My questions I have so far:

• I'm seeing 8k and 10k being allocated with 10 surfaces from CreateSurfaces -- is 10 a reasonable number of surfaces to need for all entrypoints?

I'm not sure why 10 was chosen in the original test design. @chivakker?

• Could we clamp surface creation to getMinMaxSurfaceResolution()?

I suppose we could skip cases where resolution does not fit in min/max.

• Could we bake resolution name into test names so I can either filter out the large resolutions, or test them single-threaded?

I'm not sure of a generic way to do this with gtest API. The --gtest_list_tests option shows the parameter values. Perhaps write a script using a combination of this and --gtest_filter_tests to omit cases with certain params?

[chivakker]

reducing the surfaces should be alright, the smallest I've tried was 2 surfaces. I saw that most resolutions worked well with 8 to 10 surfaces, so it should be alright to play with it.