osmesa: always build standalone for internal symbols
When building OSMesa and xlib GL, the resulting OSMesa would be linked
against libGL instead of the internal mesa libraries. However, when
building with -fvisibility=hidden, some of the internal functions used
in OSMesa could not be resolved through libGL.
Instead, always build OSMesa standalone without linking against libGL.
This has the advantage that OSMesa is always built the same way, but it
means that disk space is wasted when libGL is installed since both
libraries will contain the internal objects.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Tested-by: Tom Fogal <tfogal@alumni.unh.edu>
mesa: Allow querying the system FBO in GetFramebufferAttachmentParameteriv
If the default framebuffer is bound to <target>, then
<attachment> must be one of FRONT_LEFT, FRONT_RIGHT, BACK_LEFT,
BACK_RIGHT, AUXi, DEPTH_BUFFER, or STENCIL_BUFFER, identifying a
color buffer, the depth buffer, or the stencil buffer, and
<pname> may be FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE or
FRAMEBUFFER_ATTACHMENT_OBJECT_NAME.
as well as these <pname> values
FRAMEBUFFER_ATTACHMENT_RED_SIZE,
FRAMEBUFFER_ATTACHMENT_GREEN_SIZE,
FRAMEBUFFER_ATTACHMENT_BLUE_SIZE,
FRAMEBUFFER_ATTACHMENT_ALPHA_SIZE,
FRAMEBUFFER_ATTACHMENT_DEPTH_SIZE,
FRAMEBUFFER_ATTACHMENT_STENCIL_SIZE,
FRAMEBUFFER_ATTACHMENT_COMPONENT_TYPE, or
FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING.
https://bugs.freedesktop.org/show_bug.cgi?id=28551
Keith came up with a new way of running the pipeline which involves passing
a few info structs around (for fetch, vertices and prims) and allows us
to correctly handle cases where we endup with multiple primitives generated
by the pipeline itself.