I think your implementation of dmesg logging isn't correct. Note that
dmesg is a ring buffer; once it's full, new lines added at the end of
dmesg will cause the lines at the beginning to disappear. That's why I
had to find and save the timestamp string, and find its position again
in a new dmesg
On 09/19/2013 06:13 PM, Chad Versace wrote:
On 09/19/2013 01:58 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
The exact same spec language appears in the 3.1 spec. Currently no Mesa
driver supports OpenGL 3.2, but there are drivers that support 3.1.
This allows the
On Thursday 19 September 2013 16:02:49 Chad Versace wrote:
On 09/17/2013 08:43 AM, Dylan Baker wrote:
On Monday 16 September 2013 20:08:33 Marek Olšák wrote:
---
piglit-run.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/piglit-run.py b/piglit-run.py
On Thursday 19 September 2013 20:12:34 Ken Phillis Jr wrote:
I probably should be a little bit more price about issue #3... I do expect
the times to be different, but there is a problem of seeing less than one
tenth of the total time when I only have four processors.
Good example:
Doh!
On Friday 20 September 2013 16:29:25 Marek Olšák wrote:
I think your implementation of dmesg logging isn't correct. Note that
dmesg is a ring buffer; once it's full, new lines added at the end of
dmesg will cause the lines at the beginning to disappear. That's why I
had to find and save
Mesa/i965 currently (as of commit 1cc3b90) has an inaccurate
implementation of dFdy() which produces the same results for every
pixel in an aligned 2x2 block. This piglit test exposes the
inaccuracy.
---
.../execution/fs-dfdx-accuracy.shader_test | 35 ++
This test makes current a context, terminates the context's display, then
unbinds the context. According to the EGL 1.4 spec (2011.04.06), Section
3.2 Initialization, no errors should occur.
Exposes a use-after-free crash on mesa-9.2 with i965. This is the
underlying reason that `./$gles1_test
---
...-layout-qualifiers-with-variable-declarations.geom | 19 +++
...-layout-qualifiers-with-variable-declarations.geom | 19 +++
2 files changed, 38 insertions(+)
create mode 100644
I'll send a new patch, stay tuned.
Marek
On Fri, Sep 20, 2013 at 10:32 PM, Dylan Baker baker.dyla...@gmail.com wrote:
On Wednesday 18 September 2013 01:21:59 Marek Olšák wrote:
On Wed, Sep 18, 2013 at 1:04 AM, Dylan Baker baker.dyla...@gmail.com
wrote:
On Wednesday 18 September 2013
On Wednesday 18 September 2013 01:21:59 Marek Olšák wrote:
On Wed, Sep 18, 2013 at 1:04 AM, Dylan Baker baker.dyla...@gmail.com
wrote:
On Wednesday 18 September 2013 00:48:45 Marek Olšák wrote:
On Tue, Sep 17, 2013 at 6:43 PM, Dylan Baker baker.dyla...@gmail.com
wrote:
On Monday 16
The Radeon driver writes GPU page faults to dmesg and we need to know which
tests caused them.
If there is any change in dmesg during a test run, the test result is changed
as follows:
* pass - dmesg-warn
* warn - dmesg-warn
* fail - dmesg-fail
Dmesg is captured before and after each test and the
This is a wrapper for eglBindAPI() that does error-checking.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
tests/util/piglit-util-egl.c | 31 +++
tests/util/piglit-util-egl.h | 12
2 files changed, 43 insertions(+)
diff --git
Chad Versace (3):
egl_khr_create_context: Fix tests for invalid flags
util/egl: Add piglit_egl_bind_api()
egl_khr_create_context: Test the debug flag
tests/all.tests| 2 +
.../spec/egl_khr_create_context/CMakeLists.gl.txt | 1 +
According to version 15 of the EGL_KHR_create_context spec,
EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR is a valid flag for OpenGL ES contexts.
But the test EGL_KHR_create_context/invalid flag GLES verifies that it
is an *invalid* flag.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
Test eglCreateContext with with EGL_CONTEXT_OPENGL_BIT_KHR set for GL,
GLES1, GLES2, and GLES3. If context creation succeeds, then verify the
context is really a debug context by verifying GL_CONTEXT_FLAGS contains
GL_CONTEXT_FLAG_DEBUG_BIT. If context creation fails, then verify that
15 matches
Mail list logo