On Mon, 2011-09-19 at 18:29 -0600, Brian Paul wrote:
> From: Brian Paul
>
> 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
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 108d7ae..
This is all that is needed to implement NV_fog_distance on programmable
hardware.
---
src/mesa/main/ffvertex_prog.c | 43 +---
1 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index 2
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 b/src/me
The code formatting in translate_fog_distance_mode has been fixed.
The NV10/NV20 patch isn't include this time around because it is still
untested and was only included in the first place in case the nouveau
people were interested.
___
mesa-dev mailing
Hello,
I'm currently experiencing random hangs using mesa-git and r600g.
The computer seems to be still active, but the display doesn't respond.
I have the means to connect to the machine via ssh, to execute debugging
commands.
Could you please suggest what output I could attach to the bug repo
builtin_stubs.cpp is only supposed to be used for builtin_compiler. It
contains a stub version of _mesa_glsl_initialize_functions() that does
nothing.
libglsl.a already contains builtin_function.cpp, the generated file that
contains a version of _mesa_glsl_initialize_functions() that actually
ini
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 hardwa
On Mon, Sep 19, 2011 at 09:25:54PM -0600, Brian Paul wrote:
> On Mon, Sep 19, 2011 at 9:16 PM, 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, ctx->Constant.MaxShi
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 9:16 PM, 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, ctx->Constant.MaxShiniess].
>
> v2: fix the max shininess value.
>
> Signed-off-by: Yuanhan
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
> ---
> src/mesa/drivers/dri/i965/brw_misc_state.c |4 +++-
> 1 files changed, 3
https://bugs.freedesktop.org/show_bug.cgi?id=38970
--- Comment #13 from Gordon Jin 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 CC list for the bug.
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
---
src/mesa/vbo/vbo_attrib_tmp.h | 11 ++-
1 file
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
OS/Version
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 Liu
> >---
> > src/mesa/vbo/v
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 11:54:44AM -0700, Eric Anholt wrote:
> On Mon, 19 Sep 2011 18:25:55 +0800, 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 Liu
>
> It woul
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 BUFFE
2011/9/19 Ian Romanick :
> From: Ian Romanick
>
> 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 correct. The extra stuff is for check
From: Brian Paul
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 other OpenGL implement
On 09/19/2011 01:26 PM, Eric Anholt wrote:
On Fri, 09 Sep 2011 15:28:06 -0700, Kenneth Graunke
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(+),
---
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
--- a/src/mesa/state_tracker/s
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 e
On 19 September 2011 10:59, Ian Romanick 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
> > function, i
On 19 September 2011 11:10, Ian Romanick 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
> > clip distan
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
parame
On Fri, 09 Sep 2011 15:28:06 -0700, Kenneth Graunke
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(-)
> >
> > diff -
On Sun, 11 Sep 2011 13:05:38 +0200, Tolga Dalman
wrote:
> Hi Kenneth,
>
> On Fri, 9 Sep 2011 14:41:45 -0700
> Kenneth Graunke wrote:
>
> > - if (reg->type == BRW_REGISTER_TYPE_F) {
> > - return reg->imm.f == 0.0;
> > + if (type == BRW_REGISTER_TYPE_F) {
> > + return imm.f == 0.0
On Fri, 09 Sep 2011 20:18:02 -0700, Kenneth Graunke
wrote:
> On 09/09/2011 10:07 AM, Eric Anholt wrote:
> > On Thu, 8 Sep 2011 15:49:23 -0700, Kenneth Graunke
> > wrote:
> >> + /* Initialize the rest of u/v/r with 0.0, for safety */
> >> + for (int i = ir->coordinate->type->vector_el
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 e
From: Ian Romanick
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
---
src/mesa/main/extensions.c |3 +--
src/mesa/main/get.c
From: Ian Romanick
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 situation in any way.
--
From: Ian Romanick
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 be that EXT_texture_form
From: Ian Romanick
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 b/src/mesa/main/extensions.c
From: Ian Romanick
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 may even be older.
--
From: Ian Romanick
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
GL_EXT_multi_draw_arrays / GL_SUN_multi_draw_arr
From: Ian Romanick
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 a/src/mesa/drivers/dri/intel/intel_extensions.c
b/
From: Ian Romanick
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 -
src/mesa/drivers/dri/r300/r300_context.c |1 -
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.
___
On Mon, 19 Sep 2011 18:25:55 +0800, 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 Liu
It would be nice to see simple piglit tests created for these sorts of
API validatio
https://bugs.freedesktop.org/show_bug.cgi?id=39888
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 19 September 2011 10:53, Kenneth Graunke 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 structures
>> use
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 a/src/mes
On 9/19/11 1:08 PM, Ian Romanick wrote:
From: Ian Romanick
Fixes a bug introduced by commit faf5d65. These formats should only
be exposed in OpenGL ES 1.x.
Reviewed-by: Adam Jackson
- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
h
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 statem
-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 ---
> src/mes
-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).
> How
> > 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,
-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
-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
>
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 l
On 19 September 2011 19:23, Ian Romanick 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 mode if it is
-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,
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
b/src/mesa
_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 +++
-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
>
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
ARB_m
- 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
>
From: Ian Romanick
Fixes a bug introduced by commit faf5d65. These formats should only
be exposed in OpenGL ES 1.x.
Signed-off-by: Ian Romanick
Cc: Adam Jackson
Cc: Xun Fang
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40860
---
src/mesa/main/texcompress.c | 32 +
On 09/19/2011 03: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 the distance of
the fragment from the eye's Z plane.
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 a/src/mesa/main/ffver
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
--- a/src/gallium/
On Mon, Sep 19, 2011 at 5:48 PM, 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 the distance of
> the fragment from th
-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
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 Turner
---
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 C99
standard type na
> 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 pl
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 Liu
---
src/mesa/main/bufferobj.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
di
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
(http://www.opengl.org/registry/specs/ARB/map_buffe
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 hand
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 Liu
---
src/mesa/vbo/vbo_exec_api.c | 24
1 files changed, 24 insertions
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 Liu
---
src/mesa/vbo/vbo_attrib_tmp.h | 10 +-
1 files changed, 9
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
---
src/mesa/main/bufferobj.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/bufferobj.c b/src/mes
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
---
src/mesa/main/bufferobj.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/
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 +++---
src/mesa/drivers/dri/nouveau/nv20_c
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 722db8d..
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 2
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 b/src/me
---
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
+++ b/src/gallium/driv
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 th
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 wo
According the man page, trigger a GL_INVALID_VALUE if size < 0.
Signed-off-by: Yuanhan Liu
---
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 597ec1e..d73aa08 100644
--- a/src/mesa/ma
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
---
src/mesa/main/pixel.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/m
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
---
src/mesa/vbo/vbo_attrib_tmp.h | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/s
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
---
src/mesa/main/enable.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sr
Fix error handling while calling glTexEnv with invalid texture
environment parameters.
Signed-off-by: Yuanhan Liu
---
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
index c0d0f37..1df3890 100644
--
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
---
src/mesa/mai
According man page, trigger error when calling glEvalMesh1/2D inside
glBegin/glEnd.
Signed-off-by: Yuanhan Liu
---
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
index 7d3d332..c4ac95c 10064
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
---
src/mesa/vbo/vbo_exec_api.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/src/mesa/vbo
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
90 matches
Mail list logo
