GL_OES_geometry_shader and GL_OES_tessellation_shader specifications
require OpenGL ES Shading Language 3.10.
GL_ARB_tessellation_shader specification requires GLSL 1.50.
---
tests/shaders/built-in-constants.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tests/shade
On Mon, Nov 13, 2017 at 12:48 PM, Juan A. Suarez Romero
wrote:
> GL_OES_geometry_shader and GL_OES_tessellation_shader specifications
> require OpenGL ES Shading Language 3.10.
>
> GL_ARB_tessellation_shader specification requires GLSL 1.50.
> ---
> tests/shaders/built-in-constants.c | 8 +---
The wflinfo versions should be floats already, so don't call float() again.
If querying the ES api/version fails, we'll get None for the version number
so check for that.
---
tests/all.py | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tests/all.py b/tests/all.
With NVIDIA's driver, wflinfo reports a GLSL version line like this:
"OpenGL shading language version string: 4.40 NVIDIA via Cg compiler"
The existing parsing code didn't expect the text after the version
number and generated an exception. Change the parsing to handle this.
---
framework/wflinfo
for the series:
Reviewed-by: Dylan Baker
Quoting Brian Paul (2017-11-13 13:06:27)
> The wflinfo versions should be floats already, so don't call float() again.
> If querying the ES api/version fails, we'll get None for the version number
> so check for that.
> ---
> tests/all.py | 16 ---
For series,
Reviewed-by: Neha Bhende
Regards,
Neha
From: Piglit on behalf of Brian Paul
Sent: Friday, November 10, 2017 2:44:45 PM
To: piglit@lists.freedesktop.org
Subject: [Piglit] [PATCH 4/4] arb_sample_shading: don't use gl_FragColor/Data
in fragment sh
Dan Allen writes:
> Hi,
>
> I reported a bug in relation to the R600 driver and have since found the
> piglit tests. I ran the shader.py test and receive approximately 500
> errors when this test is run (it varies slightly between each run).
>
> Are these test results of interest to someone, an
Ping?
Am 09.11.2017 um 19:11 schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> We expect non-nan results for these (according to d3d10 rules, and at least
> for min/max, also according to ieee rules). The tests will not actually fail
> with other results (since GL's NaN behavior is all
