The mesa state tracker is currently the only place where we create a
context and expect it to implement GLES1/2. Use the API-aware constructor
to communicate this to core mesa.
This introduces a new way to create or initialize a context:
_mesa_create_context_for_api and
_mesa_initialize_context_for_api
which in addition to the current arguments take an api enum to indicate
which OpenGL API the context should implement. At this point the
API field in GLcontext isn't used anywhere, but later commits will
key certain functionality off of it.
The _mesa_create_context and _mesa_initialize_context functions are
kept in place as wrappers around the *_for_api versions, passing in
API_OPENGL to get the same behavior as before.
In the direct rendered case, we need to convert DRI2 swap complete
events to GLX events for the client to consume. This path had what
looks like a stray "& 0x75" from some earlier debugging that prevented
clients from seeing the right event code.
When matching attributes using the 'mask' matching criteria, the spec
says that
"Only GLXFBConfigs for which the set bits of attribute include all
the bits that are set in the requested value are
considered. (Additional bits might be set in the attribute)."
The current test returns true if the two bit masks have bits in
common, specifically it matches even if the requested value has bits
set that are not set in the fbconfig attribute. For example, an
application asking for
GLX_DRAWABLE_TYPE, GLX_PIXMAP_BIT | GLX_PBUFFER_BIT,
as glxpbdemo does, will match fbconfigs that don't support pbuffer
rendering, as long as they support pixmap rendering.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Commit 1454f20a99 caused the regression.
When the vertex shader emitted both a texcoord and color we were grabbing
the wrong vertex attributes. Fix the draw_quad() code to put texcoords
in slot[1] and color in slot[2]. That's a bit cleaner than changing
the vertex shader code.
Tested with progs/tests/zreaddraw.c
piglit has a test called fbo-drawbuffers, this fails for me on r300g,
and fixing the texenv program to use the DATA outputs fixes it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to check pipe_blend_state::independent_blend_enable to determine
which render target/index to use when checking blend enable and colormask
state.
This is part of the fix for piglit/fbo-drawbuffers
The IDs will be the same in the case where an X window is used directly
as a GLX drawable, but will fail if a new GLX drawable is created
explicitly, as with glxgears_fbconfig.
Fixes fdo bug #27190.
