On 09/26/2017 08:47 AM, Brian Paul wrote:
On 09/26/2017 10:32 AM, Thomas Hellstrom wrote:
Tests that check frontbuffer contents after drawing may fail because
the X server touch the front contents between drawing and checking.
In those
cases, there's typically a pending expose event. So check
Tests that check frontbuffer contents after drawing may fail because
the X server touch the front contents between drawing and checking. In those
cases, there's typically a pending expose event. So check for that
situation and optionally rerun the test.
Signed-off-by: Thomas Hellstrom <thel
.
- Test also frontbuffer.
Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
---
tests/glx/glx-swap-exchange.c | 74 +++
1 file changed, 46 insertions(+), 28 deletions(-)
diff --git a/tests/glx/glx-swap-exchange.c b/tests/glx/glx-swap-exchange.c
Tests the GLX_SWAP_COPY_OML swapbuffer mode. Very similar to the
glx-swap-exchange test.
Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
---
tests/glx/CMakeLists.gl.txt | 1 +
tests/glx/glx-swap-copy.c | 143
2 files change
to the RGB channels. At least temporary. The spec says
the front buffer contents should become the new back buffer contents but
I'm not 100% sure all implementations actually support front buffer alpha.
We might need to revisit this.
Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
---
Paul <bri...@vmware.com>
Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
---
tests/spec/gl-1.0/swapbuffers-behavior.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tests/spec/gl-1.0/swapbuffers-behavior.c
b/tests/spec/gl-1.0/swapbuffers-beha
On 06/21/2017 05:22 PM, Brian Paul wrote:
On 06/21/2017 08:34 AM, Thomas Hellstrom wrote:
Hi Brian,
On 06/21/2017 04:20 PM, Brian Paul wrote:
On 06/21/2017 06:24 AM, Thomas Hellstrom wrote:
Window systems (read dri3) that allocate a fake frontbuffer on demand
will
effectively read out from
On 06/21/2017 05:16 PM, Brian Paul wrote:
On 06/21/2017 06:25 AM, Thomas Hellstrom wrote:
the (tex->color != color) test, if false may cause uploading of stale
tex_data to the texture and cause a comparison failure. Also add a flush
after uploading so that texture data actually becomes visi
ed-off-by: Thomas Hellstrom <thellst...@vmware.com>
---
tests/glx/glx-multithread-texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/glx/glx-multithread-texture.c
b/tests/glx/glx-multithread-texture.c
index 08121e3..a70d246 100644
--- a/tests/glx/glx-multithre
the (tex->color != color) test, if false may cause uploading of stale
tex_data to the texture and cause a comparison failure. Also add a flush
after uploading so that texture data actually becomes visible for the draw
thread.
Cc: Frank Henigman <fjhenig...@google.com>
Signed-off-b
Hi Brian,
On 06/21/2017 04:20 PM, Brian Paul wrote:
On 06/21/2017 06:24 AM, Thomas Hellstrom wrote:
Window systems (read dri3) that allocate a fake frontbuffer on demand
will
effectively read out from the real front before the first swapbuffers
after
fake front creation, and the real front
Backbuffer contents become undefined after a swapbuffer call, so instead
probe the front buffer. Alternatively we can of course probe the back
before the swapbuffer call.
Cc: Frank Henigman <fjhenig...@google.com>
Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
---
t
the likelyhood
of not reading out from the real front by advertizing early that we will
access the front buffer. After all, real front consistency is not the objective
of this test.
Fixes sporadic failures due to window reparenting on dri3/vmwgfx.
Cc: Brian Paul <bri...@vmware.com>
Signed-off-by:
13 matches
Mail list logo
