The assertion added in f09910f3 broke nv50 completely by asserting that
the number of elements in a dereferenced pointer (i.e. 1) was greater
than i (which ranged up to six), rather than checking the number of
elements in the containing array.
Signed-off-by: Daniel Stone dan...@fooishbar.org
---
Makes sense.
Jose
- Original Message -
The assertion added in f09910f3 broke nv50 completely by asserting
that
the number of elements in a dereferenced pointer (i.e. 1) was greater
than i (which ranged up to six), rather than checking the number of
elements in the containing array.
On 07.02.2012 13:47, Jose Fonseca wrote:
Makes sense.
Very much so ...
http://cgit.freedesktop.org/mesa/mesa/commit/?id=189e6c7e81ce35b89d9b52d4bd0d6271a7e9c10f
(of 26 hours ago).
Jose
- Original Message -
The assertion added in f09910f3 broke nv50 completely by asserting
that
https://bugs.freedesktop.org/show_bug.cgi?id=45277
--- Comment #2 from Damien Grassart dam...@grassart.com 2012-02-07 05:11:44
PST ---
I've also found that removing PIPE_CAP_VERTEX_COLOR_UNCLAMPED as a supported
feature for r600 does fix this bug (src/gallium/drivers/r600/r600_pipe.c:369).
Is
On 7 February 2012 13:03, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 07.02.2012 13:47, Jose Fonseca wrote:
Makes sense.
Very much so ...
http://cgit.freedesktop.org/mesa/mesa/commit/?id=189e6c7e81ce35b89d9b52d4bd0d6271a7e9c10f
(of 26 hours ago).
Ha, snap. Thanks anyway. :)
On Mon, Feb 6, 2012 at 9:01 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On Mon, Feb 6, 2012 at 7:47 PM, Jose Fonseca jfons...@vmware.com
wrote:
Dave,
I really see no point of inferring anything when translating MOVs.
The src/dst value will need to be
fixes undefined references in libradeonwinsys.a when linking
Signed-off-by: Tobias Droste tdro...@gmx.de
---
src/gallium/targets/gbm/Makefile |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/gallium/targets/gbm/Makefile b/src/gallium/targets/gbm/Makefile
index
- Original Message -
On Mon, Feb 6, 2012 at 9:01 PM, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
On Mon, Feb 6, 2012 at 7:47 PM, Jose Fonseca jfons...@vmware.com
wrote:
Dave,
I really see no point of inferring anything when translating
MOVs.
From: Dave Airlie airl...@redhat.com
If we had no vertex textures previously and we have none now,
don't bother doing the enables dance.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_atom_texture.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff
I'm not familiar enough with draw internals to tell whether your changes are
enough or not.
But I'm OK with this change as is, given that most drivers will not advertise
PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION, so only those that do
advertise need to be tested to ensure that things
- Original Message -
From: Dave Airlie airl...@redhat.com
If we had no vertex textures previously and we have none now,
don't bother doing the enables dance.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_atom_texture.c |3 +++
1 files changed,
On Tue, Feb 7, 2012 at 4:29 PM, Jakob Bornecrantz ja...@vmware.com wrote:
- Original Message -
From: Dave Airlie airl...@redhat.com
If we had no vertex textures previously and we have none now,
don't bother doing the enables dance.
Signed-off-by: Dave Airlie airl...@redhat.com
---
On 02/07/2012 05:24 PM, Jose Fonseca wrote:
I'm not familiar enough with draw internals to tell whether your changes are
enough or not.
But I'm OK with this change as is, given that most drivers will not advertise
PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION, so only those that do
- Original Message -
On 02/07/2012 05:24 PM, Jose Fonseca wrote:
I'm not familiar enough with draw internals to tell whether your
changes are enough or not.
But I'm OK with this change as is, given that most drivers will not
advertise
Hi guys,
Is there any reason we need to update tex combiner state if we are
using shaders?
can we drop update_tex_combine updates to only the case where we don't
have a fragment shader/program unless its from the FF shader?
Dave.
___
mesa-dev mailing
On 02/07/2012 01:08 PM, Dave Airlie wrote:
Hi guys,
Is there any reason we need to update tex combiner state if we are
using shaders?
can we drop update_tex_combine updates to only the case where we don't
have a fragment shader/program unless its from the FF shader?
Yes, I think so.
-Brian
On Mon, 30 Jan 2012 07:40:15 +0100, Mathias Fröhlich
mathias.froehl...@gmx.net wrote:
Hi,
I am trying to make the shaders from a sky scattering shader work with mesa.
One of the problems is that the shader contains a nested 16 x 32 loop with an
instruction intensive body. The glsl loop
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 33 ---
1 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index ab05896..388e9d7 100644
---
Initial note: I'm very concerned about landing this much driver code
right before a release. It's very nice code, and easy to read and
review, but I'm still more scared of it than the previous hacks with
known bugs in this timeframe. For merging after 8.0, I'm fully on
board.
On Mon, 6 Feb
On 02/07/2012 12:08 PM, Dave Airlie wrote:
Hi guys,
Is there any reason we need to update tex combiner state if we are
using shaders?
can we drop update_tex_combine updates to only the case where we don't
have a fragment shader/program unless its from the FF shader?
I don't recall when
On 02/07/2012 01:10 PM, Eric Anholt wrote:
Initial note: I'm very concerned about landing this much driver code
right before a release. It's very nice code, and easy to read and
review, but I'm still more scared of it than the previous hacks with
known bugs in this timeframe. For merging
On Tue, 7 Feb 2012 13:10:46 -0700, Brian Paul bri...@vmware.com wrote:
We don't want our VBOs mapped when we're drawing. This change checks
if the vertex store VBO is mapped before we execute a list, unmaps it,
then remaps it after drawing. This situation pops up when building a
nested
On 02/07/2012 03:18 PM, Eric Anholt wrote:
On Tue, 7 Feb 2012 13:10:46 -0700, Brian Paulbri...@vmware.com wrote:
We don't want our VBOs mapped when we're drawing. This change checks
if the vertex store VBO is mapped before we execute a list, unmaps it,
then remaps it after drawing. This
On 02/06/2012 12:33 AM, Chad Versace wrote:
The HiZ op was implemented as a meta-op. This patch reimplements it by
emitting a special HiZ batch. This fixes several known bugs, and likely
a lot of undiscovered ones too.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
On 02/04/2012 05:24 AM, Eric Anholt wrote:
We were doing saturate-based clamping on the [0,width] or [0,height]
coordinate, which meant only the first pixel was addressable.
Fixes piglit ARB_texture_rectangle/texwrap-RECT-bordercolor
Tag this for stable branches too.
Reviewed-by: Ian
https://bugs.freedesktop.org/show_bug.cgi?id=45571
Matt Turner matts...@gmail.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Guys,
It seems that I missed a bunch of patches sitting on master that wanted
to be picked to 8.0. I went ahead and picked them over. My plan is to
have my QA team run them tonight and do the release tomorrow evening or
first thing Thursday morning.
There are a few other bugs (e.g.,
Ping? I don't want to commit that without anyone looking at it.
Am 06.02.2012 02:08, schrieb Roland Scheidegger:
In vbo_exec_DrawRangeElementsBaseVertex, take into account the basevertex.
As far as I can tell it is completely ok (though maybe stupid) to have
start/end of 100/199, with
---
src/mesa/drivers/dri/i965/brw_defines.h |1 +
src/mesa/drivers/dri/i965/brw_disasm.c | 223 ---
src/mesa/drivers/dri/i965/brw_eu.h | 17 +++-
src/mesa/drivers/dri/i965/brw_eu_emit.c | 82 +++-
src/mesa/drivers/dri/i965/brw_structs.h | 37
Improves nexuiz performance 0.28% +/- .15% (n=5) on my gen6. No
statistically significant performance difference on warsow (n=5).
---
src/mesa/drivers/dri/i965/brw_fs.h |1 +
src/mesa/drivers/dri/i965/brw_fs_emit.cpp|6
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |
Our only instruction with a 3rd source so far was linterp, and that
value was never register-allocated.
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
On Tue, Feb 7, 2012 at 10:09 PM, Ian Romanick i...@freedesktop.org wrote:
On 02/07/2012 12:08 PM, Dave Airlie wrote:
Hi guys,
Is there any reason we need to update tex combiner state if we are
using shaders?
can we drop update_tex_combine updates to only the case where we don't
have a
32 matches
Mail list logo
