miniglx was removed in February 2010. Clean up remaining
unnecessary doxygen references.
commit a9e3669683
Author: Kristian Høgsberg <krh@bitplanet.net>
Date: Thu Feb 25 16:17:04 2010 -0500
Remove remaining miniglx references
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
There has never been a doxygen/gbm_setup output folder.
Appears to have been a copy-paste error from original commit
in 245341f406.
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Per Doxygen documentation, to combine external documentation (stored in
a *.tag file) with a project the TAGFILES option should be set in the
configuration file.
A tag file typically only contains a relative location of the
documentation from the point where doxygen was run. So when
you include a tag file in other project you have to specify
where the external documentation is located in relation this
project.
You can do this in the configuration file by assigning the
(relative) location to the tag files specified after the
TAGFILES configuration option.
If you use a relative path it should be relative with respect
to the directory where the HTML output of your project is
generated; so a relative path from the HTML output directory
of a project to the HTML output of the other project that is
linked to.
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
The src/mesa/glapi folder was relocated in the below commit.
Amend the doxygen/glapi.doxy INPUT setting accordingly.
Whilst here, in addition this change also avoids a bug in the
consolidated Doxygen output caused by doxygen/glapi.doxy inadvertently
overwriting doxygen/swrast.tag via its GENERATE_TAGFILE setting.
This bug depended upon the specific order each *.tag was built.
commit 296adbd545
Author: Chia-I Wu <olv@lunarg.com>
Date: Mon Apr 26 12:56:44 2010 +0800
glapi: Move to src/mapi/.
Move glapi to src/mapi/{glapi,es1api,es2api}.
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Mesa has not had a src/mesa/shader/ folder since Mesa 7.9 removed it
in October 2010, as part of a revised GLSL compiler written by Intel.
Remove doxygen/shader.doxy and consequential changes made throughout.
In addition to removing an unnecessary Doxygen doxyfile, this change also
avoids a bug in the consolidated Doxygen output caused by
doxygen/shader.doxy inadvertently overwriting doxygen/swrast.tag via its
GENERATE_TAGFILE setting.
This bug depended upon the specific order each *.tag was built.
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
We used to use sse roundps intrinsic directly, but switched to use the llvm
intrinsics for rounding with e4f01da15d.
However, llvm semantics follows standard math lib round function which is
specced to do roundNearestAwayFromZero but we really want roundNearestEven
(moreoever, using round generates atrocious code since the cpu can't do it
directly and it results in scalar calls to libm __roundf).
So, use llvm.nearbyint instead, which does exactly the right thing, and even
has the advantage of being available with llvm 3.3 too. (I've verified it
actually generates a roundps instruction with llvm 3.3.)
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=94909
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This fixes a compile error while building Nouveau with C++11 enabled (and
glibc >= 2.23). This happens if SWR is enabled, as it forces C++11.
Signed-off-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Jose Fonseca <jfonseca@vmware.com>
https://bugs.freedesktop.org/show_bug.cgi?id=94907
libasan is never linked to shared objects (which doesn't go well with
-z,defs). It must either be linked to the main executable, or (more
practically for OpenGL drivers) be pre-loaded via LD_PRELOAD.
Otherwise works.
I didn't find anything with llvmpipe. I suspect the fact that the
JIT compiled code isn't instrumented means there are lots of errors it
can't catch.
But for non-JIT drivers, the Address/Leak Sanitizers seem like a faster
alternative to Valgrind.
Usage (Ubuntu 15.10):
scons asan=1 libgl-xlib
export LD_LIBRARY_PATH=$PWD/build/linux-x86_64-debug/gallium/targets/libgl-xlib
LD_PRELOAD=libasan.so.2 any-opengl-application
Acked-by: Roland Scheidegger <sroland@vmware.com>
This is supposed to be INVALID_OPERATION in ES. We already did this
for the fv/iv variants, but not Iiv/Iuv, which are new in ES 3.2 (or
extensions).
Fixes:
ES31-CTS.texture_border_clamp.samplerparameteri_non_gen_sampler_error
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Courtesy of address sanitizer.
[airlied: free buffers as well]
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Increase r to four channels as rgba is written to it
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is the last necessary bit for OpenGL 4.2 support. All driver-specific
functionality has already been implemented as part of extensions.
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This is kind of a hack. We currently track precise requirements
by decorating ir_variables. Propagating or grafting the RHS of an
assignment to a precise value into some other expression tree can
lose those decorations.
In the long run, it might be better to replace these ir_variable
decorations with an "exact" decoration on ir_expression nodes,
similar to what NIR does.
In the short run, this is probably good enough. It preserves
enough information for glsl_to_nir to generate "exact" decorations,
and NIR will then handle optimizing these expressions reasonably.
Fixes ES31-CTS.gpu_shader5.precise_qualifier.
v2: Drop invariant handling, as it shouldn't be necessary (caught
by Jason Ekstrand).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Copy and paste error in commit eafeb8db66:
i965/tiled_memcpy: Unroll bytes==64 case.
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
ARB_program_interface_query requires that we add struct fields
recursively down to basic types.
Fixes 52 struct test cases in dEQP-GLES31.functional.program_interface_query.*
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
No functional change here, but this now lets us recurse throught structs
in add_shader_variable().
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This lets us pass in the absolution location of a variable instead of
computing it in add_shader_variable() based on variable location and
bias. This is in preparation for recursing into struct variables.
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This consolidates the combination of create_shader_variable() and
add_program_resource() into a new helper function. No functional
difference, but we'll expand add_shader_variable() in the next few
commits.
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The existing code uses SSSE3, and because it isn't compiled in a
separate file compiled with that, it is usually not used (that, of
course, could be fixed...), whereas SSE2 is always present with 64-bit
builds. This should be pretty much as fast as the pshufb version,
albeit those code paths aren't really used on chips without llc in any
case.
v2: fix andnot argument order, add comments
v3: use pshuflw/hw instead of shifts (suggested by Matt Turner), cut comments
v4: [mattst88] Rebase
Reviewed-by: Matt Turner <mattst88@gmail.com>
Replaces four byte loads and four byte stores with a load, bswap,
rotate, store; or a movbe, rotate, store.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This was triggered by
dEQP-GLES3.functional.vertex_array_objects.all_attributes
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Move the buffer resource extraction code out into its own function.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
It is incorrect to assume that pixel format is always in BGR byte order.
We need to check bitmask parameters (such as |redMask|) to determine whether
the RGB or BGR byte order is requested.
v2: reformat code to stay within 80 character per line limit.
v3: just fix the byte order problem first and investigate SRGB later.
v4: rebased on top of the GLES3 sRGB workaround fix.
v5: rebased on top of the GLES3 sRGB workaround fix v2.
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes
dEQP-GLES31.functional.uniform_location.negative.atomic_fragment
dEQP-GLES31.functional.uniform_location.negative.atomic_vertex
Both of which have lines like
layout(location = 3, binding = 0, offset = 0) uniform atomic_uint uni0;
The ARB_explicit_uniform_location spec makes a very tangential mention
regarding atomic counters, but location isn't something that makes sense
with them.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The XMesaVisual instances freed in the visuals table on display close
are being freed with a free() call, instead of XMesaDestroyVisual(),
causing a memory leak.
Signed-off-by: John Sheu <sheu@google.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
GLvoid was used before in OpenGL but it has changed to just using void.
All GLvoids in mesa's state tracker has been changed to void in this patch.
Tested this with piglit and no problems were found. No compiler warnings.
Signed-off-by: Jakob Sinclair <sinclair.jakob@openmailbox.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
