For non-generic compressed format we assert two things:
1. The format has already been validated against the set of available
extensions.
2. The driver only enables the extension if it supports all of the
formats that are part of that extension.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Similar to the previous commit, we may be using a texture with actual RGBA
storage for the GL_ALPHA format, so force the color values to 0.0.
This commit fixes the following piglit (sub) tests:
EXT_texture_snorm/fbo-blending-formats
GL_ALPHA16_SNORM
GL_ALPHA8_SNORM
GL_ALPHA_SNORM
Note: Haswell bypasses this swizzle code, so may require an independent fix
for this bug.
Reviewed-by: Eric Anholt <eric@anholt.net>
We may be using a texture with actual RGBA storage for these formats, so force
the alpha value read to 1.0.
This commit fixes the following piglit (sub) tests:
ARB_texture_float/fb-blending-formats
GL_RGB16F_ARB
EXT_framebuffer_object/fbo-blending-formats
GL_RGB10
GL_RGB12
GL_RGB16
EXT_texture_snorm/fbo-blending-formats
GL_RGB16_SNORM
GL_RGB8_SNORM
GL_RGB_SNORM
These test improvements depend on the previous commit as well. That commit
smashes alpha to 1.0 for the case of ReadPixels (so fixes "FBO testing" as
reported by this test), while this commit smashes alpha to 1.0 for the case of
texturing (fixed the "window testing" as reported by this test).
Note: Haswell bypasses this swizzle code, so may require an independent fix
for this bug.
Reviewed-by: Eric Anholt <eric@anholt.net>
When performing a ReadPixels operation, we may be reading from a buffer that
stores alpha values, but that is actually representing a buffer with no alpha
channel. In this case, while rebasing the values, touch up all alpha values
read to 1.0.
This commit fixes the following piglit (sub) tests:
ARB_texture_float/fbo-colormask-formats
GL_RBG16F_ARB
EXT_texture_snorm/fbo-colormask-formats
GL_RGB16_SNORM
GL_RGB8_SNORM
GL_RGB_SNORM
It likely improves the results of other tests as well, but a PASS remains
elusive due to additional bugs.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
The renderbuffer's Format field may have an alpha channel even when the
underlying _BaseFormat does not. This can happen when mesa chooses to use
RGBA16 for an RGB16 format, for example.
So look at _BaseFormat when deciding whether to fixup the blend factors.
This test improves the results of at least the following piglit tests:
EXT_frambebuffer_object/fbo-blending-formats
{GL_RGB10, GL_RGB12, GL_RGB16}
EXT_texture_snorm/fbo-blending-formats
{GL_RGB16_SNORM, GLRGB8_SNORM, GL_RGB_SNORM}
But none of these actually change from FAIL to PASS yet. The R, G, and B probe
values are fixed with this commit, but the tests still fail because the alpha
values are still wrong.
Reviewed-by: Eric Anholt <eric@anholt.net>
/ vs \ mismatch was causing .objs to be put in the source tree, causing
breakeage when doing different build types in the same tree (eg., debug
vs release).
Fix this by normalizing everything to / slashes.
It's probably a good idea to purge all .objs from source tree to prevent
issues completely.
Thanks to Fredrik Höglund, all the hard work was already done.
Tested using a modified oglconform (that actually runs these tests on
our driver); it looks like there may be some bugs when using client
arrays. All applicable non-compatibility tests passed.
For now, only enable it in core profiles.
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Ian Romanick <idr@freedesktop.org>
Squashed with two reverts:
Revert "android: Update for builtin_stubs.cpp move"
This reverts commit c0def90ede.
Revert "scons: Update for builtin_stubs.cpp"
This reverts commit 8ac4b82699.
Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
Tested-on-Android-by: Chad Versace <chad.versace@linux.intel.com>
I don't see how this could have ever worked right.
The screen-space interpolation code uses the vertex->data[pos_attr]
position which contain window coords. But window coords are only
computed for the unclipped vertices; the clipped vertices have
undefined window coords (see draw_cliptest_tmp.h).
Use the vertex clip coords instead which are always defined.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=55476
(piglit fbo-blit-stretch failure on softpipe)
Note: This is a candidate for the 9.0 branch.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
In debug builds, set clipped vertex window coordinates to NaN values
to help debugging. Otherwise, we're just leaving the coordinate in clip
space and it's invalid to use it later expecting it to be a window coord.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Fixes piglit spec/ARB_sampler_objects/sampler-incomplete and
spec/EXT_texture_swizzle/depth_texture_mode_and_swizzle.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
This error was added in the 3.0.1 update to the OpenGL ES 3.0 spec.
Fixes the updated gles3conform packed_depth_stencil_parameters test.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes gles3conform test CoverageES30. It temporarily regresses some
framebuffer_blit tests, but the failing subcases have been determined to
be invalid for OpenGL ES 3.0.
v2: Fix typo in depth (and stencil) RB checking. Noticed by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
These were introduced in 2000 during a rework of the TNL module (commit
cab974cf6c), though I'm having a hard time
finding an instance there of one of these Exec functions being changed
at runtime.
Regardless, as far as I can tell now, these functions don't get changed,
by grepping for calls to SET_* to change the dispatch table (we do change
functions in GLvertexformat at runtime, but those don't overlap with
this set of functions). Remove them and just let them be initialized to
the same functions as are in the Exec table.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This cuts out a ton of code to make functions not set to a save_ variant
match.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This will let us copy from the Exec dispatch to deal with our commands that
don't get compiled into display lists.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
I want to drive the Save dispatch table setup from this same function.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
All callers are in Mesa core and all use _gloffset_COUNT, so just rely on
the already baked-in use of _gloffset_COUNT in the function.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We now have a separate dispatch table for begin/end that prevent these
functions from being entered during that time. The
ASSERT_OUTSIDE_BEGIN_END_WITH_RETVALs are left because I don't want to
change any return values or introduce new error-only stubs at this
point.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This is a step toward getting rid of ASSERT_OUTSIDE_BEGIN_END() in Mesa.
v2: Finish create_beginend_table() comment, move loopback API init into it,
and add a const flag. (suggestions by Brian)
Reviewed-by: Brian Paul <brianp@vmware.com> (v1)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
My change 7ca4f07b5b caused errors to not
be thrown when they should, because the new if statement for ExecuteFlag
made the CurrentSavePrimitive not get set. And on further review, we
shouldn't be validating our primitive in GL_COMPILE mode, since the
command shouldn't be executed yet.
Partially fixes piglit gl-1.0-beginend-coverage.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This reduces jitter slightly in a cleaner way, without desynchronizing mplayer2 as badly
when falling behind.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
It appears that scons implicit dependency scanners fail to chain
dependencies of generated headers when these are outside the build tree.
This patch ensures generated source files are _always_ put in the build
tree. I'm not 100% this will fix all depency issues, but from my
experiments it does seem to fix this.
NOTE: For this to be effective it is necessary to clean the source tree
from generated header/source files.
Reviewed-by: Brian Paul <brianp@vmware.com>
There really isn't any point. There is no resource savings, and we have
to do gymnastics in the driver to make it work.
There are also bad interactions with multisampling and OpenGL ES 3.0.
In ES3, a multisample-to-singlesample blit must have identical source
and destination format. This means a multisample RGBA8 to singlesample
RGB8 (window) blit will generate an error. Also in ES3, RGB8 is not a
renderable format. This means that the application CANNOT make an RGB8
multisample renderbuffer.
As a result, if an application gets an RGB8 window and wants to do
multisample FBO rendering, it will probably break.
"Fixes" gles3conform
framebuffer_blit_functionality_multisampled_to_singlesampled_blit test
on RGB8 visuals.
v2: Fix 'formats' array size. Suggested by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
Ian Romanick