We have recently found a regression in the i965 driver related to
gl_PointCoord which was not being caught by this test. This patch
changes the test slightly so that we can expose the problem for
future regression testing.
The problem occured because the driver was not using the correct
number of
This is not allowed so we check that we produce a linker error.
---
.../vs-to-fs-type-not-numerical.shader_test| 52 ++
1 file changed, 52 insertions(+)
create mode 100644
tests/spec/arb_enhanced_layouts/linker/component-layout/vs-to-fs-type-not-numerical.shader_test
TextureStorage* functions should produce INVALID_OPERATION instead
of INVALID_ENUM when the target is not valid.
---
tests/spec/arb_direct_state_access/getcompressedtextureimage.c | 2 +-
tests/spec/arb_direct_state_access/gettextureimage-targets.c | 2 +-
2 files changed, 2 insertions(+), 2 del
Linking means that we will validate in/out blocks between consumer and
producer stages. In this case it should fail because for geometry shaders
piglit will include a dummy vertex shader that does not have a matching
output block.
This has not been a problem until now because the linker was not de
The test declares that only GLSL 1.40 is required, but then shaders
use version 4.20, leading to execution failures if the platform does
not support 4.20. Just require GLSL 1.40 in the shaders too, since
that is sufficient and consistent with other similar tests.
---
.../execution/component-layout
---
.../tcs-input-array-dvec4-index-rd.shader_test | 99
.../tcs-output-array-dvec4-index-wr.shader_test| 97 +++
.../tes-input-array-dvec4-index-rd.shader_test | 93 +++
...put-array-dvec4-index-wr-before-tcs.shader_test | 103 ++
---
...l-recursive-variable-array-indexing.shader_test | 45 ++
1 file changed, 45 insertions(+)
create mode 100644
tests/shaders/glsl-recursive-variable-array-indexing.shader_test
diff --git a/tests/shaders/glsl-recursive-variable-array-indexing.shader_test
b/tests/shaders
Default ES precision qualifiers for integer types in the VS and FS
are different and that should make the test fail to compile/link
if Mesa actually checked for these things (because it would realize
that VS outputs and FS inputs do not have the exact same type as
a consequence).
Fix this by setti
Default ES precision qualifiers for float types in the VS and FS
are different and that should make the test fail to compile/link
if Mesa actually checked for these things (because it would realize
that VS outputs and FS inputs do not have the exact same type as
a consequence).
Fix this by setting
The textureProj tests multiply expected texture coordinates by the projector
in advance so that when the driver does the division we obtain the same
coordinates. However, the division can lead to small rounding errors that
can affect the selected layer and fail the tests. This is currently happenin
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/**
+ * @file fbo-extended-blend-pat
OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/**
+ * @file fbo-extended-blend-pattern.c
+ * @author Iago Toral Quiroga
+ *
+ * On Intel hardware at least, SIMD16 dual source rendering requires handling
+ * pixel data in two sets of 8 pixels each. Incorrect implementations may fail
+ * t
N ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/*
+ * Test texture upload with scale and bias pixel transfer options
+ *
+ * Iago Toral Quiroga
+ * Feb 13, 2015
+ */
+
Jordan has completed the review of the SandyBridge Geometry Shader
implementation and I would like to push the series to Mesa, but we need
this patch in piglit too so that people running piglit tests on
SandyBridge do not run into the GPU hang.
If nobody has objections I'll push this patch later t
F OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/**
+ * @file fbo-extended-blend-pattern.c
+ * @author Iago Toral Quiroga
+ *
+ * On Intel hardware at least, SIMD16 dual source rendering requires handling
+ * pixel data in two sets of 8 pixels each. Incorrect im
These tests has been in the list for a while and now that drivers are
starting to expose ARB_gpu_shader5 it would be nice to have these tests
for multi-stream included in the suite, so if nobody says otherwise we
would like to push them next week.
Iago
On miƩ, 2014-08-20 at 16:30 +0200, Samuel Ig
This has been hanging here for a while, so if nobody says otherwise I'd
like to push this next week.
Iago
On jue, 2014-06-12 at 09:00 +0200, Iago Toral Quiroga wrote:
> This tests correct rendering of polygons using antialised GL_LINE mode for one
> face and GL_FILL for the other o
This tests correct rendering of polygons using antialised GL_LINE mode for one
face and GL_FILL for the other one. On some Intel hardware at least this used
to require special handling that has caused regressions in the past.
The test checks that the GL_FILL face of the polygon renders properly.
-
This tests correct rendering of polygons using antialised GL_LINE mode for one
face and GL_FILL for the other one. On some Intel hardware at least this used
to require special handling that has caused regressions in the past.
The test checks that the GL_FILL face of the polygon renders properly.
-
This tests correct rendering of polygons using antialised GL_LINE mode for one
face and GL_FILL for the other one. On some Intel hardware at least this used
to require special handling that has caused regressions in the past.
The test checks that the GL_FILL face of the polygon renders properly.
-
20 matches
Mail list logo