[Mesa-dev] [PATCH 00/25] GLX_MESA_query_renderer to all ;-)

[Emil Velikov]

As the name suggests this series adds support for the above extension
to every driver that mesa provides, standing as equal to the classic
i915 and i965.

Summary of the series
PATCH 01-05:
 Factor out common glx loader code, and then add support for
 __DRI2rendererQueryExtension to drisw and dri3.

PATCH 06-11:
 Handle the classic drivers - nouveau, radeon and swrast.

PATCH 12
 Resolves a typo wrt calculating the amount of system memory for dri/i9*5.

PATCH 13-16:
 Introduce MAX_GL_*_VERSION caps to gallium, and default values for each
 driver. Then the state-tracker reads back the values and clamps them against
 mesa's current capabilities.

PATCH 17-24:
 Add a range of additional PIPE_CAP(s) in order to handle device, vendor,
 uma and video memory as requested by the spec. Following with implementation
 for each driver.

PATCH 25:
 Adds support for __DRI2rendererQueryExtension to the dri state-tracker,
 essentially enabling GLX_MESA_query_renderer for every gallium driver.

Points of interest:
 - Some of the values reported by individual drivers may be off so please
those.
 - Retrieving the nouveau device id fails. Would be nice to resolve it but
it's not a critial issue.
 - How do we handle reporting the amount of video memory.
The spec describes GLX_RENDERER_VIDEO_MEMORY_MESA as "Number of megabytes
of video memory available to the renderer", which begs the following

1. On non UMA devices should we cap the value to the amount of vram or
gart ?
2. What amount should be reported by software renderers ?

Tested:
 - classic swrast
 - gallium swrast/llvmpipe
 - gallium nouveau

Needs testing:
 - everything else - dri2, dri3 both classic and gallium drivers

To test:
 1. Grab and build piglit.
 2. execute bin/glx-query-renderer-coverage.
 3. Check if the test pass and check the values returned.

The series can be found in the GLX_MESA_query_renderer branch at
https://github.com/evelikov/Mesa/

Thanks for sticking till the end, and having a look at the patches :-)

Emil

P.S. The last patch introduces some lovely compiler warnings about
redefinition of our memory allocation/deallocation macros, which should
be harmless.