The previous commit stopped exporting 21 libGLESv2 and 88 libGLESv1_CM
functions. This removes the work-arounds for those functions from
ABI-check.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Chad Versace <chad.versace@linux.intel.com>
This has been a long standing issue with the ES libraries. Functions
marked in the XML with 'static_dispatch=false' were still incorrectly
exported. ABI-check is supposed to detect this case, but we have to
paper over failures every time a new extension is added.
This change will cause a big pile of functions to disappear from
libGLESv2 and libGLESv1_CM.
libGLESv2 loses (20 functions):
glBindVertexArrayOES
glCompressedTexImage3DOES
glCompressedTexSubImage3DOES
glCopyTexSubImage3DOES
glDeleteVertexArraysOES
glDiscardFramebufferEXT
glDrawBuffersNV
glFlushMappedBufferRangeEXT
glFramebufferTexture3DOES
glGenVertexArraysOES
glGetBufferPointervOES
glGetProgramBinaryOES
glIsVertexArrayOES
glMapBufferOES
glMapBufferRangeEXT
glProgramBinaryOES
glReadBufferNV
glTexImage3DOES
glTexSubImage3DOES
glUnmapBufferOES
libGLESv1_CM loses (88 functions):
glAlphaFuncxOES
glBindFramebufferOES
glBindRenderbufferOES
glBlendEquationOES
glBlendEquationSeparateOES
glBlendFuncSeparateOES
glCheckFramebufferStatusOES
glClearColorxOES
glClearDepthfOES
glClearDepthxOES
glClipPlanefOES
glClipPlanexOES
glColor4xOES
glDeleteFramebuffersOES
glDeleteRenderbuffersOES
glDepthRangefOES
glDepthRangexOES
glDiscardFramebufferEXT
glDrawTexfOES
glDrawTexfvOES
glDrawTexiOES
glDrawTexivOES
glDrawTexsOES
glDrawTexsvOES
glDrawTexxOES
glDrawTexxvOES
glFlushMappedBufferRangeEXT
glFogxOES
glFogxvOES
glFramebufferRenderbufferOES
glFramebufferTexture2DOES
glFrustumfOES
glFrustumxOES
glGenerateMipmapOES
glGenFramebuffersOES
glGenRenderbuffersOES
glGetBufferPointervOES
glGetClipPlanefOES
glGetClipPlanexOES
glGetFixedvOES
glGetFramebufferAttachmentParameterivOES
glGetLightxvOES
glGetMaterialxvOES
glGetRenderbufferParameterivOES
glGetTexEnvxvOES
glGetTexGenfvOES
glGetTexGenivOES
glGetTexGenxvOES
glGetTexParameterxvOES
glIsFramebufferOES
glIsRenderbufferOES
glLightModelxOES
glLightModelxvOES
glLightxOES
glLightxvOES
glLineWidthxOES
glLoadMatrixxOES
glMapBufferOES
glMapBufferRangeEXT
glMaterialxOES
glMaterialxvOES
glMultiTexCoord4xOES
glMultMatrixxOES
glNormal3xOES
glOrthofOES
glOrthoxOES
glPointParameterxOES
glPointParameterxvOES
glPointSizePointerOES
glPointSizexOES
glPolygonOffsetxOES
glQueryMatrixxOES
glRenderbufferStorageOES
glRotatexOES
glSampleCoveragexOES
glScalexOES
glTexEnvxOES
glTexEnvxvOES
glTexGenfOES
glTexGenfvOES
glTexGeniOES
glTexGenivOES
glTexGenxOES
glTexGenxvOES
glTexParameterxOES
glTexParameterxvOES
glTranslatexOES
glUnmapBufferOES
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Chia-I Wu <olv@lunarg.com>
Cc: Paul Berry <stereotype441@gmail.com>
This is hella ugly. The same-named function in desktop OpenGL is
hidden, but it needs to be exposed by libGLESv2 for OpenGL ES 3.0.
There's no way to express in the XML that a function should be be hidden
in one API but exposed in another.
This won't affect any change now, but it will prevent a regression in a
later patch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Functions that are part of OpenGL ES 1.0 or 1.1 should have static
dispatch functions in libGLESv1_CM. This doesn't affect any change yet,
but it will prevent later regressions.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Chad Versace <chad.versace@linux.intel.com>
This prevents the entrypoints from being (incorrectly) advertised by
libGL.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Chad Versace <chad.versace@linux.intel.com>
It looks like these were added accidentally by Paul in commit 1a1db174.
From the commit message and the look of the patch, I think this was just
some sed-job left overs.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
It was my understanding that the writemask works in SIMD4x2 mode for
texturing instructions and doesn't require a message header. Some bit of
this logic must be wrong, so disable it until it's understood.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76617
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
By doing GC the linker removes all the symbols that are not referenced
and/or used by the final library. This results in a saving of ~100K
up-to ~600K per (stripped) binary (classic vs gallium drivers).
If interested one can ask the compiler to print the sections that are
removed using -Wl,--print-gc-sections.
v2: Check if ld supports the flag before using it.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Matt Turner <mattst88@gmail.com> (v1)
... apart from the dri drivers.
With this final change we can build mesa without fear that
the resulting libraries will have unresolved symbols.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Set the flag for all but the dri targets. They have missing
glapi symbols which are required for the normal operation with
the X server.
Jon, I fear that you'll need to carry the "no-undefined" hunk
locally when building the dri drivers under cygwin.
Cc: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Unused due to the missing GALLIUM_TRACE define.
Requested-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Explicitly setting the linker variable was required for old and broken
build toolchains. At this point this should no longer be needed, and
setting the sources lists will trigger generation of the correct LINK
variables.
Explicitly include dummy.cpp to use g++ to link the static library which
in most cases is based upon C++ code.
v2: Reword commit message.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This lets us have only one if HAVE_MESA_LLVM block, rather than
one for each driver.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Every library uses the same libtool/linker flags. Compact those
into AM_LDFLAGS and append the version script to it.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Or it compiles them in, but pretends they don't exist
v2: Rebase (Emil)
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Mesa does _not_ link against libudev. Additionally the only place
that deals with it is the loader, thus we can drop the CFLAGS.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
It makes little sense to enable the vdpau, xvmc and omx state-trackers
as they do not make use of (don't work with) the software driver.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
grep -q is easier to read and consistent with the rest of configure.ac.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Gallium osmesa links against the softpipe driver, thus the build
will fail if it's missing.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Evidently at least static OSMesa is still used as shared one
causes substantial increase in the load time for some programs
that use it (from seconds up-to ~30min).
Rather than forcing everyone to use shared mesa, revert commit
a6efbac9fb and default to shared
build when both shared and static are disabled.
v2: Whitespace cleanup, drop silly comment.
Reported-by: Burlen Loring <burlen.loring@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Currently only linux can make use of dri3, so it would make sense to
enable it explicitly for the platform.
Drop a duplicated libudev check while we're at it.
v3: Properly handle dri3 and reword commit message.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76377
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
GL_INTENSITY has never been valid as a pixel format -- to get the memcpy
pack/unpack paths, the app needs to specify GL_RED as the pixel format
(or GL_RED_INTEGER for the integer formats).
Note: This was briefly merged before, but exposed some breakage in gallium, so
was reverted. Hopefully it will stick this time.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
_mesa_format_matches_format_and_type() returns true for
GL_RED/GL_RED_INTEGER (with an appropriate type) into an intensity
mesa_format.
We want the `red`-based format instead, regardless of the order we find
them in our walk of the mesa formats list.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The case for this was in the wrong function, and this format's store
func was not set in the table at all.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
Whether or not the coords are normalized is handled in the texture
state. But we otherwise need to treat RECT sample instructions as 2D.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
In some cases, we need a register to be assigned up to three components
before the base. Since we can't have negative register #'s, just shift
everything up. May increase register usage for trivial shaders, but I
don't think we are shader limited in those cases. A proper solution is
going to require a better register assignment algorithm (which is on the
TODO list), this is just a hack to get us by until then.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
RB_FRAME_BUFFER_DIMENSION is not a banked context register, so we need
to wait for the GPU to idle before updating it. But we'd rather not
have unnecessary WFI's, so actually keep track if we need to emit it or
not.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
This is something that XA triggers. In some cases it will only use
SAMP[1] (composite mask) but not SAMP[0] (composite src).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Based on a patch by Ville Syrjälä.
As usual, these are placeholder values; actual values will come later.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
