graphics/PlatformProbe: Implement a more principled GraphicBufferAllocator selector

[RAOF]

This implements an actual selection process for the GraphicBufferAllocator:

• First, find the RenderingPlatform(s) with fewest displays they can't drive, then
• Select the RenderingPlatform with the highest number of displays probed 'best' for

In the case of ties, the algorithm picks the first RenderingPlatform in the list;
due to the selections elsewhere, that will be the first platform in alphabetical order

Fixes: #3400

[RAOF]

This needs further testing on hardware I have (laptop, RPi4) before merging.

[codecov]

Codecov Report

Attention: Patch coverage is 98.93617% with 1 line in your changes missing coverage. Please review.

Project coverage is 77.31%. Comparing base (a5f3143) to head (48cfdca).
Report is 480 commits behind head on main.

Files with missing lines	Patch %	Lines
tests/unit-tests/graphics/test_platform_prober.cpp	98.48%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3402      +/-   ##
==========================================
- Coverage   77.52%   77.31%   -0.22%     
==========================================
  Files        1065     1075      +10     
  Lines       67901    68494     +593     
==========================================
+ Hits        52639    52953     +314     
- Misses      15262    15541     +279     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[AlanGriffiths]

This looks sensible, and obviously does what is described.

But could there be tests?

[RAOF]

Yes, there could (and should!) be tests!

[RAOF]

Ok! glmark on the Pi is noisy, but this does not appear to have a significant performance effect there (and it still renders correctly 😉).

It works on my laptop - rendering is correct, both from i915 and amdgpu, and performance is better when rendering on i915. Performance seems to be a lot worse on amdgpu. Here we run into “how useful a benchmark is glmark?”. I'm not sure, and I'm still investigating exactly where the difference is.

[RAOF]

OK. So, the difference between trunk and this:

• On trunk, amdgpu uses linux_dmabuf. The client driver selects a format/modifier pair that's (apparently) much faster for amdgpu to render to, but is incompatible with i915.
• On this (and, it turns out, 2.16.2) the client driver uses wl_drm and create_prime_buffer; this will (presumably, there's no easy way to introspect this) allocate a linear buffer that is slower to render to.

So this is not a performance regression vs 2.16.2 on AMD on my Intel/AMD hybrid laptop, and renders correctly.

It might be interesting in future to see how rendering to the optimal buffer layout, and then going through the bounce-buffer to be sampleable from the Intel GPU, but that's definitely future work.

This should be good to go.

[AlanGriffiths]

Yeah, that looks better