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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
