Handle errors in _mesa_unpack_image instead in unpack_image. This
would make the error message more detailed and specified.
This patch does:
1. trigger a GL_INVALID_VALUE if (width < 0 || height < 0 || depth < 0)
2. do not trigger an error if (width == 0 || height == 0 || depth == 0)
the o
LLVM 3.0svn added SubtargetInfo as additional parameter to
createMCDisassembler() and createMCInstPrinter().
See revision 139237 of LLVM.
Signed-off-by: Tobias Droste
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --
---
src/gallium/drivers/nouveau/SConscript |2 +-
src/gallium/drivers/nv50/SConscript|2 +-
src/gallium/drivers/nvc0/SConscript|2 +-
src/gallium/drivers/nvfx/SConscript|2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/SCo
On 09/14/2011 01: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
ctx->Const.MaxClipPlanes rather than MAX_CLIP_PLA
On Wed, Sep 14, 2011 at 8:44 PM, Bryan Cain wrote:
> I don't see any reason why this patch would make a difference, but since
> it apparently does, I'll take a look at it and fix it. What program is
> that?
Nevermind. I guess it's a bug in r600g, because softpipe and nouveau pass.
The registers
On 09/14/2011 01:49 PM, Paul Berry wrote:
To support GLSL 1.30, we will need to increase MAX_CLIP_PLANES to 8,
and as a side effect this will increase the value of
MAX_CLIPPED_VERTICES defined in src/mesa/main/config.h. Gallium has
its own value of MAX_CLIPPED_VERTICES, defined in draw_pipe_clip
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 larger.
---
src/mesa/main/config.h |2 +-
Previously this value was set to MAX_CLIP_PLANES, which is defined to
be 6. But MAX_CLIP_PLANES needs to be increased to 8 to support
GLSL-1.30-compliant drivers. This patch hard-codes the default value
of ctx->Const.MaxClipPlanes to 6, so that when MAX_CLIP_PLANES is
increased, it won't affect d
To support GLSL 1.30, we will need to increase MAX_CLIP_PLANES to 8,
and as a side effect this will increase the value of
MAX_CLIPPED_VERTICES defined in src/mesa/main/config.h. Gallium has
its own value of MAX_CLIPPED_VERTICES, defined in draw_pipe_clip.c,
but this value only takes effect if MAX_
This patch removes the assertion "MAX_CLIP_PLANES == 6" from the i965
driver. This assertion is unnecessary; nothing in the driver requires
MAX_CLIP_PLANES to be 6.
---
src/mesa/drivers/dri/i965/brw_curbe.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/
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
ctx->Const.MaxClipPlanes rather than MAX_CLIP_PLANES, since
ctx->Const.MaxClipPlanes will rem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/14/2011 12:18 PM, Dave Airlie wrote:
>>> Hi guys,
>>>
>>> So I've been noticing there are a number of inconsistencies
>>> between EXT_gpu_shader4 and GLSL1.30, are you planning on
>>> implementing EXT_gpu_shader4?
>>>
>>> EXT_gpu_shader4 appe
I don't see any reason why this patch would make a difference, but since
it apparently does, I'll take a look at it and fix it. What program is
that?
Bryan
On 09/14/2011 07:01 AM, Marek Olšák wrote:
> Bryan,
>
> This commit causes hardlocks on r600g (integers disabled).
>
> Maybe you can see bet
https://bugs.freedesktop.org/show_bug.cgi?id=40437
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 09/14/2011 11:16 AM, Michel Dänzer wrote:
From: Michel Dänzer
This makes sure that stObj->pt exists and is up to date.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39193 .
Signed-off-by: Michel Dänzer
---
src/mesa/state_tracker/st_cb_fbo.c |9 ++---
1 files changed, 6 inser
>> Hi guys,
>>
>> So I've been noticing there are a number of inconsistencies
>> between EXT_gpu_shader4 and GLSL1.30, are you planning on
>> implementing EXT_gpu_shader4?
>>
>> EXT_gpu_shader4 appears to define "unsigned" and can also use
>> texture2D to sample from integer samplers.
>
> There are
From: Michel Dänzer
This makes sure that stObj->pt exists and is up to date.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39193 .
Signed-off-by: Michel Dänzer
---
src/mesa/state_tracker/st_cb_fbo.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/mesa
https://bugs.freedesktop.org/show_bug.cgi?id=40860
Ian Romanick changed:
What|Removed |Added
Severity|major |normal
Priority|high
On 09/14/2011 06:16 AM, Dave Airlie wrote:
Hi guys,
So I've been noticing there are a number of inconsistencies between
EXT_gpu_shader4 and GLSL1.30, are you planning on implementing
EXT_gpu_shader4?
I'm not super interested in it, though it seems like a nice thing to
have once GL3 and GLSL 1
On 09/12/2011 06:20 PM, Paul Berry wrote:
The array_lvalue field was attempting to enforce the restriction that
whole arrays can't be used on the left-hand side of an assignment in
GLSL 1.10 or GLSL ES, and can't be used as out or inout parameters in
GLSL 1.10.
However, it was buggy (it didn't w
- Original Message -
> >> +util_format_is_rgb(enum pipe_format format)
> >> +{
> >> + const struct util_format_description *desc =
> >> + util_format_description(format);
> >
> > For callers that call these helpers a lot, all these internal calls
> > to util_format_description() wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/2011 08:47 AM, Brian Paul wrote:
> On 09/13/2011 04:54 AM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This introduces a new gl_clear_color union and moves the current
>> ClearColorUnclamped to use it, it removes ClearColor completely
>> a
On 09/14/2011 06:09 AM, Dave Airlie wrote:
From: Dave Airlie
I'm not 100% sure about this, it may need a version check or it might
be completely wrong.
Signed-off-by: Dave Airlie
---
src/mesa/main/uniforms.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/14/2011 06:16 AM, Dave Airlie wrote:
> Hi guys,
>
> So I've been noticing there are a number of inconsistencies
> between EXT_gpu_shader4 and GLSL1.30, are you planning on
> implementing EXT_gpu_shader4?
>
> EXT_gpu_shader4 appears to define "u
Thanks for taking a look at this, Jose. Comments/questions below...
On 09/14/2011 09:19 AM, Jose Fonseca wrote:
Hi Brian,
- Original Message -
From: Brian Paul
---
src/gallium/auxiliary/util/u_format.c | 77
+
src/gallium/auxiliary/util/u_format
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/14/2011 11:02 AM, Jose Fonseca wrote:
> - Original Message -
>> What are people's opinions on this? Is it worth spending some
>> time to clean up some of this code?
>
> It's hard to say...
>
> A lot of this code is disjoint anyway, so i
https://bugs.freedesktop.org/show_bug.cgi?id=30124
Bug 30124 depends on bug 29626, which changed state.
Bug 29626 Summary: [swrast] glean glsl1 texture2D() regression
https://bugs.freedesktop.org/show_bug.cgi?id=29626
What|Old Value |New Value
---
- Original Message -
> Hi,
>
> I've talked about it a bit before, but I feel that it's getting out
> of
> hand, so it's time to talk about cleaning up some of the Python
> that's
> used to generate/build Mesa.
>
> First, the biggest problem is that our Python's completely untested
> and
https://bugs.freedesktop.org/show_bug.cgi?id=30124
Kenneth Graunke changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 14 September 2011 08:26, Corbin Simpson wrote:
> Hi,
>
> I've talked about it a bit before, but I feel that it's getting out of
> hand, so it's time to talk about cleaning up some of the Python that's
> used to generate/build Mesa.
>
> First, the biggest problem is that our Python's completely
Hi,
I've talked about it a bit before, but I feel that it's getting out of
hand, so it's time to talk about cleaning up some of the Python that's
used to generate/build Mesa.
First, the biggest problem is that our Python's completely untested
and unstructured. It's very ad-hoc. This might be alri
Hi Brian,
- Original Message -
> From: Brian Paul
>
> ---
> src/gallium/auxiliary/util/u_format.c | 77
> +
> src/gallium/auxiliary/util/u_format.h | 16 +++
> 2 files changed, 93 insertions(+), 0 deletions(-)
>
> diff --git a/src/gallium/auxili
From: Brian Paul
If we're drawing to a luminance, luminance/alpha or intensity surface
we have to adjust (rebase) the fragment/quad colors before writing them
to the tile cache. The tile cache always stores RGBA colors but if
we're caching a L/A surface (for example) we need to be sure that R=G=
From: Brian Paul
---
src/gallium/auxiliary/util/u_format.c | 77 +
src/gallium/auxiliary/util/u_format.h | 16 +++
2 files changed, 93 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format.c
b/src/gallium/auxiliary/util/u_format.
Am Montag, den 12.09.2011, 23:39 +0200 schrieb Emeric Grange:
> Hi,
> Here is a series of small patches to the g3dvl video decoding stack.
> Most of these are extracted from my GSoC 2011 work and are not related
> to VP8 decoding (http://cgit.freedesktop.org/~emericg/mesa-vp8/).
>
> The third an
On 09/13/2011 04:40 PM, Ian Romanick wrote:
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/mesa/main/image.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index 3e75e7c..da8eaff 100644
--- a/src/mesa
https://bugs.freedesktop.org/show_bug.cgi?id=29133
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=29832
Corbin Simpson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=29133
Corbin Simpson changed:
What|Removed |Added
Version|unspecified |7.8
Component|Drivers/DRI/nouv
Bryan,
This commit causes hardlocks on r600g (integers disabled).
Maybe you can see better than me what's wrong.
This is a side-by-side diff of the failing TGSI shader. The right-hand
one is from Mesa master. The left-hand one is with the commit
reverted.
http://pastebin.com/raw.php?i=QXB3SZAE
https://bugs.freedesktop.org/show_bug.cgi?id=28657
Corbin Simpson changed:
What|Removed |Added
Version|unspecified |7.8
Status|NEW
From: Dave Airlie
I'm not 100% sure about this, it may need a version check or it might
be completely wrong.
Signed-off-by: Dave Airlie
---
src/mesa/main/uniforms.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/uniforms.c b/src/mesa/main
Hi guys,
So I've been noticing there are a number of inconsistencies between
EXT_gpu_shader4 and GLSL1.30, are you planning on implementing
EXT_gpu_shader4?
EXT_gpu_shader4 appears to define "unsigned" and can also use
texture2D to sample from integer samplers.
My main worry is we end up needing
https://bugs.freedesktop.org/show_bug.cgi?id=19303
Corbin Simpson changed:
What|Removed |Added
Version|unspecified |6.2.1
Component|Other
> Looks pretty good, Dave.
>
> Reviewed-by: Brian Paul
>
> I'd be OK with committing as-is, but I'd suggest a few minor things:
Pushed with edits: comments below:
>
> 1. Do we really need to call the field ClearColorUnclamped? I think we
> could keep it as ClearColor and just add a comment that
On 14.09.2011 11:30, Jose Fonseca wrote:
> - Original Message -
>> On 14.09.2011 09:36, Jose Fonseca wrote:
>>> Original Message -
> On the contrary, I think that putting norm and scaled/int in the
> same sack is talking apples and oranges... Normalization, like
> fix
Make sure _NEW_POLYGONSTIPPLE state is set. A simple call case like the
following:
glEnable(GL_POLYGON_STIPPLE);
glPolygonStipple(pattern);
glClear(GL_COLOR_BUFFER_BIT); /* <---!!---> */
glRectf(...);
glFlush();
would simply make the polygon stipple fail. The glClear would fire a
draw
- Original Message -
> On 14.09.2011 09:36, Jose Fonseca wrote:
> > Original Message -
> >>> On the contrary, I think that putting norm and scaled/int in the
> >>> same sack is talking apples and oranges... Normalization, like
> >>> fixed-point integers, affects the interpretatio
On 14.09.2011 09:36, Jose Fonseca wrote:
> Original Message -
>>> On the contrary, I think that putting norm and scaled/int in the
>>> same sack is talking apples and oranges... Normalization, like
>>> fixed-point integers, affects the interpretation of the 32bit
>>> integer in memory, n
Original Message -
> >
> > On the contrary, I think that putting norm and scaled/int in the
> > same sack is talking apples and oranges... Normalization, like
> > fixed-point integers, affects the interpretation of the 32bit
> > integer in memory, namely the scale factor that it should b
50 matches
Mail list logo
