Marek Olšák writes:
> I think glFenceSync+glFlush in one context and glWaitSync (server-side
> synchronization) in the other context would be the best solution. It
> shouldn't block the CPU, but it should set the right ordering of
> commands. glFinish seems to be overkill.
Sounds great for an AR
Oops -- this patch will be replaced. Still has mad magic indices
everywhere, to be replaced with enum values based on Eric's feedback last
time. 2/2 still stands.
On Tue, Nov 20, 2012 at 4:45 PM, Chris Forbes wrote:
> Picks up the driver not bothering to normalize attribute values.
> This was b
At least i965 takes a fairly different path for FF and ARB VP
compared to GLSL vertex shaders. Add a 'glsl' option to allow
this test to exercise either path.
Signed-off-by: Chris Forbes
---
tests/all.tests | 3 ++-
.../draw-vertices-2101010.c
Picks up the driver not bothering to normalize attribute values.
This was broken in an early version of my i965 support for this
extension.
Signed-off-by: Chris Forbes
---
.../arb_vertex_type_2_10_10_10_rev/draw-vertices-2101010.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(
I think glFenceSync+glFlush in one context and glWaitSync (server-side
synchronization) in the other context would be the best solution. It
shouldn't block the CPU, but it should set the right ordering of
commands. glFinish seems to be overkill.
Marek
On Mon, Nov 19, 2012 at 10:27 PM, Eric Anholt
The time-elapsed test needs to consume a lot of GPU time so that it
can validate GPU time queries against elapsed wall-clock time.
Previously we did this by painting the window thousands of times.
That sometimes caused false failures due to the CPU time consumed in
preparing the draw calls.
This p
On 19 November 2012 13:26, Eric Anholt wrote:
> Paul Berry writes:
>
> > From: Ian Romanick
> >
> > To use multithreading with xlib, you're supposed to call XInitThreads
> > before any other xlib call. Without this, xlib and GLX calls won't be
> > thread safe. It looks like this test had an e
Paul Berry writes:
> Currently, in Mesa with the i965 driver, calling glFlush() forces all
> pending drawing operations to be sent to the kernel; this ensures that
> any subsequent drawing operations will be performed after those
> pending drawing operations, even if they come from other contexts
Paul Berry writes:
> From: Ian Romanick
>
> To use multithreading with xlib, you're supposed to call XInitThreads
> before any other xlib call. Without this, xlib and GLX calls won't be
> thread safe. It looks like this test had an extra mutex to work
> around the lack of thread saftey in glXC
For the series:
Reviewed-by: Chad Versace
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
Currently, in Mesa with the i965 driver, calling glFlush() forces all
pending drawing operations to be sent to the kernel; this ensures that
any subsequent drawing operations will be performed after those
pending drawing operations, even if they come from other contexts.
The glx-multithread test wa
From: Ian Romanick
To use multithreading with xlib, you're supposed to call XInitThreads
before any other xlib call. Without this, xlib and GLX calls won't be
thread safe. It looks like this test had an extra mutex to work
around the lack of thread saftey in glXCreateContext and
glXMakeCurrent.
On Mon, Nov 19, 2012 at 8:53 AM, Chad Versace
wrote:
> - Request a config with the es3 bit, EGL_OPENGL_ES3_BIT_KHR.
> - Try to create a GLES 3.0 context with the config.
> - Verify that the context version is >= 3.0.
>
> CC: Matt Turner
> Signed-off-by: Chad Versace
> ---
> .../egl/spec/egl_khr
Attempt to create contexts with bogus versions.
Tests Mesa commit 243cf7a924eaef78ce0d5150747fae6c3c4e6974. Before that
commit, the Intel driver failed to validate requested OpenGL ES context
versions.
CC: Kenneth Graunke
Signed-off-by: Chad Versace
---
.../spec/egl_khr_create_context/verify-g
If eglChooseConfig fails with EGL_BAD_ATTRIBUTE, then fail the test.
Piglit only requests valid attributes, therefore the error is incorrect.
Regresses test egl-create-context-verify-gl-flavor:gles3.0 on
mesa-5cf853669. Mesa fails to recoginize EGL_OPENGL_ES3_BIT_KHR despite
exposing the EGL_KHR_c
- Request a config with the es3 bit, EGL_OPENGL_ES3_BIT_KHR.
- Try to create a GLES 3.0 context with the config.
- Verify that the context version is >= 3.0.
CC: Matt Turner
Signed-off-by: Chad Versace
---
.../egl/spec/egl_khr_create_context/verify-gl-flavor.c | 17 +
1 file ch
Kenneth Graunke writes:
> From the GL 3.0 specification, page 162:
> "Final Expansion to RGBA
>
> This step is performed only for non-depth component groups. Each group
> is converted to a group of 4 elements as follows: if a group does not
> contain an A element, then A is added and set to 1
>From the GL 3.0 specification, page 162:
"Final Expansion to RGBA
This step is performed only for non-depth component groups. Each group
is converted to a group of 4 elements as follows: if a group does not
contain an A element, then A is added and set to 1 for integer
components or 1.0 for
18 matches
Mail list logo
