Print "GEOM" instead of "2", for example.
v2: also update the text parsing code, per Ilia.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
From time to time we have had cases where glslang has added a decoration we
don't handle and it has caused problems. This audit ensures that, for
every decoration, we either handle it or hit an unreachable() with an
accurate description of why we don't have to.
It appears that UV immediates aren't working on Ivy Bridge. In this
case, a signed version will work, and this fixes the piglit
tests/spec/glsl-4.50/execution/helper-invocation.shader_test test.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This allows clear and easy communication between the two.
Caller: Requesting information (struct vN)
Callee: I know how to deal with older version (vN-1) only. Here is your
data and the version I support.
Caller: Older version ? Sure I'll cap all access to the fields provided
by the older version (vN-1)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
One cannot use a single version to control both export_in and export_out
versions. Using this forces us to always extend/bump both structs at the
same time.
An alternative scheme is coming with next patch.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
... and make them more explicit.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
Be more explicit what it actually does.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
OCD polish for consistency with other mesa interfaces.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
Using the macro to set the version is wrong and ill-advised. Please don't
do it.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
Analogous to previous commit, but for EGL.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
Since we only need partial information about the GLX symbols we can
forward declare them and drop the include. Obviously each user of the
said API will needs more than what's provides, so they'll include the
GLX header.
If they don't, the compiler will give us a nice warning ;-)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
These come from windows.h, gl.h, glcorearb.h and/or glext.h.
The interop interface is aimed at non-Windows platforms while the macros
are used/derived due to Windows specifics. Thus we can safely remove
them.
Strictly speaking there should be GLXAPIENTRY/EGLAPIENTRY and alike
macros, although a) there is no GLX ones and b) this brings us even
further from decoupling the file from the GLX/EGL header dependency.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
Thus we can preserve the ABI, while avoiding the inclusion of some/all
of the following:
EGL/egl.h
GL/gl.h
GL/glcorearb.h
GLES/gl.h
GLES2/gl2.h
GLES3/gl3.h
GLES3/gl31.h
This will allow us to build/use it alongside any combination of APIs.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
This reverts commit 4e2c9a0435.
The solution was incomplete and fragile. An alternative one is coming
shortly.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
The GL_OES_geometry_shader work is on the oes_shader_io_blocks branch
of idr's fd.o repository.
The GL_OES_tessellation_shader work is on the tess-gles branch
of kwg's fd.o repository.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Add weak symbol notation for the pthread_mutexattr* symbols, thus making
the linker happy. When building with -O1 or greater the optimiser will
kick in and remove the said functions as they are dead/unreachable code.
Ideally we'll enable the optimisations locally, yet that does not seem
to work atm.
v2: Add the AX_GCC_FUNC_ATTRIBUTE([weak]) hunk in configure.
Cc: Alejandro Piñeiro <apinheiro@igalia.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Tested-by: Mark Janes <mark.a.janes@intel.com>
1. Don't clear bucket descriptions to fix issues with sim level
buckets getting out of sync.
2. Close out threadviz file descriptors in ClearThreads().
3. Skip buckets for jitter based buckets when multithreaded. We need
thread local storage through llvm jit functions to be fixed before
we can enable this.
4. Fix buckets StopCapture to correctly detect capture complete.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Lift the resctriction we had before and allow creation of images with
multiple planes. We still require all the planes to be within the same
bo.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
This function now only creates the mt and we then call
intel_set_texture_image_mt() in intel_image_target_texture_2d() to set
it for the texture image.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Create the mt for the drawable bo directly and call our new
intel_miptree_create_for_bo() helper instead.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
This factors out the work of setting up a miptree as the backing for a
texture image into a new helper.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
This lowers sampling from YUV textures to 1) one or more texture
instructions to sample each plane and 2) color space conversion to RGB.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This will be used to select the plane to sample from for planar
textures.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Otherwise, if the call executes normally we'll hit an assertion later
in the VBO code when we draw something. Note that these cases were
already handled correctly for the glIsEnabled() function (and the API
checks were copied from there).
Tested with new piglit gl-3.1-enable-vertex-array test.
v2: fix compat/es mix-up, per Ilia.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
We added support for Android build using autotools (configure),
update the documentation to reflect that.
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
For double-precision vertex inputs we need to measure them in dvec4
terms, and for single-precision vertex inputs we need to measure them in
vec4 terms.
For the later case, we use type_size_vec4() function. For the former
case, we had a wrong implementation based on type_size_vec4().
This commit introduces a proper type_size_dvec4() function, that we use
to measure vertex inputs.
Measuring double-precision vertex inputs as dvec4 is required because
ARB_vertex_attrib_64bit states that these uses the same number of
locations than the single-precision version. That is, two consecutives
dvec4 would be located in location "x" and location "x+1", not "x+2".
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Images aren't supported on maxwell, but neither is tessellation. Don't
overly confuse matters by trying to expose those subtleties in the
GL3.txt file/relnotes.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Dave Airlie <airlied@redhat.com>
Emil Velikov
Ilia Mirkin
Brian Paul
Jason Ekstrand
Jordan Justen
Emil Velikov
Ian Romanick
Tim Rowley
Kristian Høgsberg Kristensen
Kristian Høgsberg Kristensen
Nicolas Boichat
Juan A. Suarez Romero