The following patchs fixed some error handling for some gl functions.
Yuanhan Liu (8):
mesa: fix error handling for glBegin
mesa: fix error handling for glEvalMesh1/2D
mesa: fix error handling for some glGet* functions
mesa: fix error handling for glTexEnv
mesa: fix error handling for
According to opengl spec, trigger GL_INVALID_ENUM error if mode is not
one of those valid primitive mode while calling glBegin.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/vbo/vbo_exec_api.c | 24
1 files changed, 24 insertions(+), 0
According man page, trigger error when calling glEvalMesh1/2D inside
glBegin/glEnd.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/main/api_noop.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/api_noop.c b/src/mesa/main/api_noop.c
According to the man page, it should trigger a GL_INVALID_OPERATION
while calling some glGet* functions inside glBegin and glEnd.
This patch dose handle the following functions:
glGetBooleanv
glGetFloatv
glGetIntegerv
glGetInteger64v
glGetDoublev
Signed-off-by: Yuanhan Liu
Fix error handling while calling glTexEnv with invalid texture
environment parameters.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/main/texenv.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/texenv.c b/src/mesa/main/texenv.c
According the man page, GL_INVALID_OPERATION should be generated if
glIsEnabled is executed betwwen the execution of glBegin and the
correspoding execution of glEnd.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/main/enable.c |2 ++
1 files changed, 2 insertions(+), 0
Trigger GL_INVALID_ENUM error if the face paramter is not a valid value.
Trigger GL_INVALID_VALUE error if the GL_SHININESS value is out side
[0,128].
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/vbo/vbo_attrib_tmp.h | 10 +-
1 files changed, 9 insertions(+), 1
According the man page, GL_INVALID_OPERATION should generated if
glPixelZoom is executed between the execution of glBegin and the
corresponding execution of glEnd.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/main/pixel.c |2 ++
1 files changed, 2 insertions(+), 0
According the man page, trigger a GL_INVALID_VALUE if size 0.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/main/feedback.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/feedback.c b/src/mesa/main/feedback.c
index
Hi Luca, I've been toying with the d3d1x state tracker lately in order
to make it work properly with the nv50/nvc0 gallium drivers.
I've taken a bit of a shortcut and made it feed SM4 directly to the
driver (I didn't have the nerve to extend TGSI), and got as far as
having your spikysphere demo
The NV_fog_distance extension allows you to specify how the fog distance
of a fragment is calculated. The usual method approximates the distance
of the fragment from the eye as the absolute value of the distance of
the fragment from the eye's Z plane. (Or, rather, the distance of each
vertex and
---
src/gallium/drivers/llvmpipe/.gitignore |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/.gitignore
b/src/gallium/drivers/llvmpipe/.gitignore
index 6ebd2b8..ce96392 100644
--- a/src/gallium/drivers/llvmpipe/.gitignore
+++
No driver implements it yet.
---
src/mesa/main/extensions.c |1 +
src/mesa/main/fog.c| 14 ++
src/mesa/main/get.c|5 +
src/mesa/main/mtypes.h |2 ++
4 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/extensions.c
This is all that is needed to implement NV_fog_distance on programmable
hardware.
---
src/mesa/main/ffvertex_prog.c | 40
1 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index
The fixed-function generated vertex program is all that's needed for
Gallium drivers.
---
src/mesa/state_tracker/st_extensions.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index
This has not been tested on real hardware. I have no idea if it works.
Add support for NV_fog_distance to the NV10 and NV20 drivers.
---
src/mesa/drivers/dri/nouveau/nv10_context.c |1 +
src/mesa/drivers/dri/nouveau/nv10_state_tnl.c | 14 +++---
If I understand correctly, the new GL3 buffer object queries parameters,
like BUFFER_MAP_ACCESS_FLAGS, depends on ARB_map_buffer_range
extension.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/main/bufferobj.c | 12 ++--
1 files changed, 6 insertions(+), 6
Accroding the man page, GL_INVALID_VALUE would generated if access has any
bits set other than those valid defined bits.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/main/bufferobj.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git
On 09/19/2011 01:03 AM, Yuanhan Liu wrote:
Trigger GL_INVALID_ENUM error if the face paramter is not a valid value.
Trigger GL_INVALID_VALUE error if the GL_SHININESS value is out side
[0,128].
Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com
---
src/mesa/vbo/vbo_attrib_tmp.h | 10
On 09/19/2011 01:02 AM, Yuanhan Liu wrote:
According to opengl spec, trigger GL_INVALID_ENUM error if mode is not
one of those valid primitive mode while calling glBegin.
Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com
---
src/mesa/vbo/vbo_exec_api.c | 24
1
On 09/19/2011 01:02 AM, Yuanhan Liu wrote:
The following patchs fixed some error handling for some gl functions.
Yuanhan Liu (8):
mesa: fix error handling for glBegin
mesa: fix error handling for glEvalMesh1/2D
mesa: fix error handling for some glGet* functions
mesa: fix error
On 09/19/2011 04:25 AM, Yuanhan Liu wrote:
If I understand correctly, the new GL3 buffer object queries parameters,
like BUFFER_MAP_ACCESS_FLAGS, depends on ARB_map_buffer_range
extension.
That would make sense, but in fact the extension spec
On 09/19/2011 04:25 AM, Yuanhan Liu wrote:
Accroding the man page, GL_INVALID_VALUE would generated if access has any
bits set other than those valid defined bits.
Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com
---
src/mesa/main/bufferobj.c | 10 ++
1 files changed, 10
Agree.
So who is going to do that? Dave and Marek seems to already have
volunteered for that. I would also like to help, but at least officially
I don't have time todo so.
I've started on separate int types in my
http://cgit.freedesktop.org/~airlied/mesa/log/?h=gallium-int-work
This plumbs
On 09/18/11 10:26, Matt Turner wrote:
We've had a hack to fix this in Gentoo on Solaris for a while.
Signed-off-by: Matt Turnermatts...@gmail.com
---
Not sure what the deal is with uint, or why it wouldn't work on Solaris.
Not sure where uint is expected to be defined - Solaris provides the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/19/2011 07:20 AM, Brian Paul wrote:
On 09/19/2011 04:25 AM, Yuanhan Liu wrote:
If I understand correctly, the new GL3 buffer object queries
parameters, like BUFFER_MAP_ACCESS_FLAGS, depends on
ARB_map_buffer_range extension.
That would
On Mon, Sep 19, 2011 at 5:48 PM, Nicholas Miell nmi...@gmail.com wrote:
The NV_fog_distance extension allows you to specify how the fog distance
of a fragment is calculated. The usual method approximates the distance
of the fragment from the eye as the absolute value of the distance of
the
On 09/19/2011 03:48 AM, Nicholas Miell wrote:
---
src/gallium/drivers/llvmpipe/.gitignore |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/.gitignore
b/src/gallium/drivers/llvmpipe/.gitignore
index 6ebd2b8..ce96392 100644
---
On 09/19/2011 03:48 AM, Nicholas Miell wrote:
This is all that is needed to implement NV_fog_distance on programmable
hardware.
---
src/mesa/main/ffvertex_prog.c | 40
1 files changed, 36 insertions(+), 4 deletions(-)
diff --git
From: Ian Romanick ian.d.roman...@intel.com
Fixes a bug introduced by commit faf5d65. These formats should only
be exposed in OpenGL ES 1.x.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Adam Jackson a...@redhat.com
Cc: Xun Fang xunx.f...@intel.com
Bugzilla:
- Original Message -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/19/2011 07:20 AM, Brian Paul wrote:
On 09/19/2011 04:25 AM, Yuanhan Liu wrote:
If I understand correctly, the new GL3 buffer object queries
parameters, like BUFFER_MAP_ACCESS_FLAGS, depends on
On 09/19/2011 10:17 AM, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/19/2011 07:20 AM, Brian Paul wrote:
On 09/19/2011 04:25 AM, Yuanhan Liu wrote:
If I understand correctly, the new GL3 buffer object queries
parameters, like BUFFER_MAP_ACCESS_FLAGS, depends on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/19/2011 02:48 AM, Nicholas Miell wrote:
The NV_fog_distance extension allows you to specify how the fog
distance of a fragment is calculated. The usual method approximates
the distance of the fragment from the eye as the absolute value of
_NEW_WINDOW_POS wasn't a real Mesa state flag, but we were missing
_NEW_BUFFERS to update the stipple offset when FBO binding or window
size changed, and _NEW_POLYGON to update when stippling gets enabled.
Fixes oglconform's tristrip test.
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 10
Because we skip the pattern upload when stippling is disabled, we need
to check again when it might have been turned on.
---
src/mesa/drivers/dri/i965/brw_misc_state.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/19/2011 10:12 AM, Jose Fonseca wrote:
- Original Message -
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 09/19/2011 07:20 AM, Brian Paul wrote:
On 09/19/2011 04:25 AM, Yuanhan Liu wrote:
If I understand correctly, the new GL3
On 19 September 2011 19:23, Ian Romanick i...@freedesktop.org wrote:
Direct3D 9 calls the eye radial fog distance mode range-based fog
and Wine's D3D9 implementation will use NV_fog_distance to
implement it. Several other open source game engines in Google Code
Search use the eye radial fog
On 09/14/2011 12:49 PM, Paul Berry wrote:
This will allow drivers to increase ctx-Const.MaxClipPlanes to 8,
which is required for GLSL-1.30 compliance.
No driver behavior should be affected. However, many data structures
use MAX_CLIP_PLANES as an array size, so these arrays will get
slightly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/14/2011 12:49 PM, Paul Berry wrote:
To support GLSL 1.30, we will need to increase MAX_CLIP_PLANES to
8. To avoid breaking drivers that do not yet support 8 clip planes,
this patch modifies the Mesa core code that pertains to clipping to
use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/15/2011 04:40 PM, Paul Berry wrote:
This patch fixes a bug in ir_hirearchical_visitor: when traversing
an exec_list representing the formal or actual parameters of a
function, it modified base_ir to point to each parameter in turn,
rather
This patch fixes a bug in ir_hirearchical_visitor: when traversing
an exec_list representing the formal or actual parameters of a
function, it modified base_ir to point to each parameter in turn,
rather than leaving it as a pointer to the enclosing statement.
This was a problem, since
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/15/2011 04:40 PM, Paul Berry wrote:
In i965 GEN6+ (and I suspect most other hardware), gl_ClipDistance
needs to be laid out as a pair of vec4's (the first containing
clip distances 0-3, and the second containing clip distances 4-7).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/19/2011 12:03 AM, Yuanhan Liu wrote:
Trigger GL_INVALID_ENUM error if the face paramter is not a valid
value.
Trigger GL_INVALID_VALUE error if the GL_SHININESS value is out
side [0,128].
Signed-off-by: Yuanhan Liu
On 09/15/2011 04:40 PM, Paul Berry wrote:
This patch fixes a bug in ir_hirearchical_visitor: when traversing an
exec_list representing the formal or actual parameters of a function,
it modified base_ir to point to each parameter in turn, rather than
leaving it as a pointer to the enclosing
On 9/19/11 1:08 PM, Ian Romanick wrote:
From: Ian Romanickian.d.roman...@intel.com
Fixes a bug introduced by commit faf5d65. These formats should only
be exposed in OpenGL ES 1.x.
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
___
mesa-dev
On 09/19/2011 09:31 AM, Eric Anholt wrote:
Because we skip the pattern upload when stippling is disabled, we need
to check again when it might have been turned on.
---
src/mesa/drivers/dri/i965/brw_misc_state.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git
On 19 September 2011 10:53, Kenneth Graunke kenn...@whitecape.org wrote:
On 09/14/2011 12:49 PM, Paul Berry wrote:
This will allow drivers to increase ctx-Const.MaxClipPlanes to 8,
which is required for GLSL-1.30 compliance.
No driver behavior should be affected. However, many data
https://bugs.freedesktop.org/show_bug.cgi?id=39888
Sven Arvidsson s...@whiz.se changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, 19 Sep 2011 18:25:55 +0800, Yuanhan Liu yuanhan@linux.intel.com
wrote:
Accroding the man page, GL_INVALID_VALUE would generated if access has any
bits set other than those valid defined bits.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
It would be nice to see simple
Here are some more patches in the on going extension clean-up saga.
This set removes enables for a bunch of extensions that have always
been enabled in all drivers (even the ones recently removed). It also
removes some redundant enables of default-on extensions and one
nonsense extension.
From: Ian Romanick ian.d.roman...@intel.com
This extension is enabled by default in _mesa_init_extensions, so
drivers don't need to enable it again.
---
src/mesa/drivers/dri/intel/intel_extensions.c |1 -
src/mesa/drivers/dri/r200/r200_context.c |1 -
From: Ian Romanick ian.d.roman...@intel.com
This extension is enabled by default in _mesa_init_extensions, so
drivers don't need to enable it again.
---
src/mesa/drivers/dri/intel/intel_extensions.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git
From: Ian Romanick ian.d.roman...@intel.com
The following extensions are always enabled, and drivers do not have
to option to disable them:
GL_ARB_multisample
GL_ARB_texture_compression
GL_ARB_vertex_buffer_object / GL_OES_mapbuffer
GL_EXT_copy_texture
From: Ian Romanick ian.d.roman...@intel.com
The year 2006 apparently came from the Last Modified Date in the
spec header. however, the revision history at the bottom say 2/22/00
mjk - added NVIDIA Implementation Details. From that we can safely
infer that the spec is from at least 2000, and it
From: Ian Romanick ian.d.roman...@intel.com
Mesa has never any portion of this extension, and neither has any
other vendor.
---
src/mesa/main/extensions.c |1 -
src/mesa/main/mtypes.h |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/extensions.c
From: Ian Romanick ian.d.roman...@intel.com
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.
EXT_texture_format_BGRA is mostly a subset of EXT_bgra. The only
difference seems to
From: Ian Romanick ian.d.roman...@intel.com
All drivers remaining in Mesa support this extension. This extension
is required in desktop OpenGL. The existing support is already partially
broken in Mesa (e.g., using format=GL_ABGR for glTexImage2D in OpenGL ES 2.x).
This patch does not change the
From: Ian Romanick ian.d.roman...@intel.com
This extension is always enabled, and drivers do not have
to option to disable it.
I kept this one separate from the others because I was a little
uncertain about the changes to get.c.
Cc: Kristian Høgsberg k...@bitplanet.net
---
On 09/19/2011 01:18 PM, Ian Romanick wrote:
Here are some more patches in the on going extension clean-up saga.
This set removes enables for a bunch of extensions that have always
been enabled in all drivers (even the ones recently removed). It also
removes some redundant enables of default-on
On Fri, 09 Sep 2011 20:18:02 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
On 09/09/2011 10:07 AM, Eric Anholt wrote:
On Thu, 8 Sep 2011 15:49:23 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
+ /* Initialize the rest of u/v/r with 0.0, for safety */
+ for (int i =
On Sun, 11 Sep 2011 13:05:38 +0200, Tolga Dalman tolga.dal...@googlemail.com
wrote:
Hi Kenneth,
On Fri, 9 Sep 2011 14:41:45 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
- if (reg-type == BRW_REGISTER_TYPE_F) {
- return reg-imm.f == 0.0;
+ if (type ==
On Fri, 09 Sep 2011 15:28:06 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
On 09/08/2011 11:32 PM, Eric Anholt wrote:
These were copy and pasted from the FS, and are never used.
---
src/mesa/drivers/dri/i965/brw_vec4.h |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
On 09/19/2011 12:12 PM, Jose Fonseca wrote:
- Original Message -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/19/2011 07:20 AM, Brian Paul wrote:
On 09/19/2011 04:25 AM, Yuanhan Liu wrote:
If I understand correctly, the new GL3 buffer object queries
parameters, like
On 19 September 2011 11:10, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/15/2011 04:40 PM, Paul Berry wrote:
In i965 GEN6+ (and I suspect most other hardware), gl_ClipDistance
needs to be laid out as a pair of vec4's (the first containing
On 19 September 2011 10:59, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/15/2011 04:40 PM, Paul Berry wrote:
This patch fixes a bug in ir_hirearchical_visitor: when traversing
an exec_list representing the formal or actual parameters of a
On 09/19/2011 12:18 PM, Ian Romanick wrote:
Here are some more patches in the on going extension clean-up saga.
This set removes enables for a bunch of extensions that have always
been enabled in all drivers (even the ones recently removed). It also
removes some redundant enables of default-on
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 119
1 files changed, 85 insertions(+), 34 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 8921698..f68270d 100644
---
On 09/19/2011 01:26 PM, Eric Anholt wrote:
On Fri, 09 Sep 2011 15:28:06 -0700, Kenneth Graunkekenn...@whitecape.org
wrote:
On 09/08/2011 11:32 PM, Eric Anholt wrote:
These were copy and pasted from the FS, and are never used.
---
src/mesa/drivers/dri/i965/brw_vec4.h |2 --
1 files
From: Brian Paul bri...@vmware.com
The 1-bit alpha channel was incorrectly encoded. Previously, any non-zero
alpha value for the ubyte alpha value would set A=1. Instead, use the
most significant bit of the ubyte alpha to determine the A bit. This is
consistent with the other channels and
2011/9/19 Ian Romanick i...@freedesktop.org:
From: Ian Romanick ian.d.roman...@intel.com
This extension is always enabled, and drivers do not have
to option to disable it.
I kept this one separate from the others because I was a little
uncertain about the changes to get.c.
Yes, that looks
On Mon, Sep 19, 2011 at 09:17:42AM -0700, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/19/2011 07:20 AM, Brian Paul wrote:
On 09/19/2011 04:25 AM, Yuanhan Liu wrote:
If I understand correctly, the new GL3 buffer object queries
parameters, like
On Mon, Sep 19, 2011 at 11:54:44AM -0700, Eric Anholt wrote:
On Mon, 19 Sep 2011 18:25:55 +0800, Yuanhan Liu yuanhan@linux.intel.com
wrote:
Accroding the man page, GL_INVALID_VALUE would generated if access has any
bits set other than those valid defined bits.
Signed-off-by: Yuanhan
On Mon, Sep 19, 2011 at 08:08:18AM -0600, Brian Paul wrote:
On 09/19/2011 01:03 AM, Yuanhan Liu wrote:
Trigger GL_INVALID_ENUM error if the face paramter is not a valid value.
Trigger GL_INVALID_VALUE error if the GL_SHININESS value is out side
[0,128].
Signed-off-by: Yuanhan
On Mon, Sep 19, 2011 at 08:09:09AM -0600, Brian Paul wrote:
On 09/19/2011 01:02 AM, Yuanhan Liu wrote:
According to opengl spec, trigger GL_INVALID_ENUM error if mode is not
one of those valid primitive mode while calling glBegin.
Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=41023
Summary: d3d1x: error when building -
src/dxgi_native.cpp:1165:40: error: uninitialized
const ‘black’
Product: Mesa
Version: git
Platform: Other
Trigger GL_INVALID_ENUM error if the face paramter is not a valid value.
Trigger GL_INVALID_VALUE error if the GL_SHININESS value is out side
[0, ctx-Constant.MaxShiniess].
v2: fix the max shininess value.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/vbo/vbo_attrib_tmp.h
https://bugs.freedesktop.org/show_bug.cgi?id=38970
--- Comment #13 from Gordon Jin gordon@intel.com 2011-09-19 20:22:18 PDT
---
ajax/Ian, any idea?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the
On Mon, Sep 19, 2011 at 09:31:36AM -0700, Eric Anholt wrote:
Because we skip the pattern upload when stippling is disabled, we need
to check again when it might have been turned on.
Reviewed-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_misc_state.c |4
On Mon, Sep 19, 2011 at 9:16 PM, Yuanhan Liu
yuanhan@linux.intel.com wrote:
Trigger GL_INVALID_ENUM error if the face paramter is not a valid value.
Trigger GL_INVALID_VALUE error if the GL_SHININESS value is out side
[0, ctx-Constant.MaxShiniess].
v2: fix the max shininess value.
Trigger GL_INVALID_ENUM error if the face paramter is not a valid value.
Trigger GL_INVALID_VALUE error if the GL_SHININESS value is out side
[0, ctx-Constant.MaxShiniess].
v2: fix the max shininess value.
v3: suggested by Brian, move the face check into glMaterialfv function
to reduce code
On Mon, Sep 19, 2011 at 09:25:54PM -0600, Brian Paul wrote:
On Mon, Sep 19, 2011 at 9:16 PM, Yuanhan Liu
yuanhan@linux.intel.com wrote:
Trigger GL_INVALID_ENUM error if the face paramter is not a valid value.
Trigger GL_INVALID_VALUE error if the GL_SHININESS value is out side
[0,
On 09/19/2011 10:23 AM, Ian Romanick wrote:
I guess the big question is... why? With vertex shaders, this
functionality is not terribly useful. Over the past few weeks we've
been *removing* code like this, so it seems kind of odd to add some of
it. If I'm not mistaken, the only hardware
82 matches
Mail list logo
