Since atm our OPs aren't typed but instead values are, we need to
take care if they're used as different types (e.g. a load makes a
value u32 by default).
Maybe this should be changed (also to match TGSI), but it should
work as well if done properly.
At some point we'll want to support real subroutines instead of
just inlining them into the main shader.
Since recursive calls are forbidden, we can just save all used
registers to a fixed local memory region and restore them on a
return, no need for a stack pointer.
There's a useful feature buried in glapi to log all API calls to stderr.
Unfortunately it requires editing the code and then it's enabled
unconditionally for that build. This patch builds in API logging for
debug builds and makes it run-time switchable by setting MESA_DEBUG=dispatch.
This increases the chance that GLSL programs will actually work.
Note that continues and returns are not yet lowered, so linking
will just fail if not supported.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
This allows us to specify different options, especially useful for chips
without unified shaders.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Otherwise builtin_profiles contains dangling pointers the next time
_mesa_read_profile is called. I suspect this may fix bugzilla #29847,
but I was never able to reproduce it.
GL_EXT_texture_env_combine has slightly more restrictive limits on the
valid sources for some operands. This wasn't caught before because
almost every driver in Mesa that supports the EXT version also
supports the ARB version.
Inspired by a patch posted the the mesa-dev mailing list by Andrew
Randrianasulu.
Since we now actually destroy GLX drawables, we get into situations where
we get events for drawables that no longer exist. Just ignore the
event in that case.
Doesn't work for pixmaps, was looking up the GLX XID and was never thread
safe. Instead, just destroy the client side structures when the
drawable is no long current for a context.
libmesagallium.a that this state tracker will be linked to expects
OpenGL's _glapi_table. That is, it expects libGL.so instead of
libGLESv1_CM.so or libGLESv2.so. As there is no clean way to know the
shared library the app links to, use the api as a simple check. It
might be as well to simply remove this function call though.
Make st/dri screens capable of creating OpenGL ES and
OpenGL ES2 contexts.
TODO: Figure out the "get_current" problem with multiple
st_api's for real.
(s/API_OPENGLES1/API_OPENGLES/ by Chia-I Wu)
