On Tue, Feb 7, 2012 at 10:09 PM, Ian Romanick 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 fragmen
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
b/src/mesa/driv
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 | 4
---
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 +++
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 _MaxEl
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., Chad's
https://bugs.freedesktop.org/show_bug.cgi?id=45571
Matt Turner changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
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 Romanick
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
_
On 02/07/2012 03:18 PM, Eric Anholt wrote:
On Tue, 7 Feb 2012 13:10:46 -0700, Brian Paul 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 whe
On Tue, 7 Feb 2012 13:10:46 -0700, Brian Paul 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 display list in GL
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 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 update
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 2012
---
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
--- a/src/mesa/state_tracker/st_
On Mon, 30 Jan 2012 07:40:15 +0100, Mathias Fröhlich
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 unrolling pass is try
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
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 display list in GL_COMPILE_AND_EXECUTE mode.
---
src/mesa/vbo/vbo_save.h |
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 l
- 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 PIPE_CAP_QUADS_FOLLOW_PROVOKING
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
On Tue, Feb 7, 2012 at 4:29 PM, Jakob Bornecrantz wrote:
> - Original Message -
>> From: Dave Airlie
>>
>> If we had no vertex textures previously and we have none now,
>> don't bother doing the enables dance.
>>
>> Signed-off-by: Dave Airlie
>> ---
>> src/mesa/state_tracker/st_atom_tex
- Original Message -
> From: Dave Airlie
>
> If we had no vertex textures previously and we have none now,
> don't bother doing the enables dance.
>
> Signed-off-by: Dave Airlie
> ---
> src/mesa/state_tracker/st_atom_texture.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions
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 ar
From: Dave Airlie
If we had no vertex textures previously and we have none now,
don't bother doing the enables dance.
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_atom_texture.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_ato
- Original Message -
> On Mon, Feb 6, 2012 at 9:01 PM, Jose Fonseca
> wrote:
> > - Original Message -
> >> On Mon, Feb 6, 2012 at 7:47 PM, Jose Fonseca
> >> wrote:
> >> > Dave,
> >> >
> >> > I really see no point of inferring anything when translating
> >> > MOVs.
> >> > The src
fixes undefined references in libradeonwinsys.a when linking
Signed-off-by: Tobias Droste
---
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 ce56f93..2737b79 1006
On Mon, Feb 6, 2012 at 9:01 PM, Jose Fonseca wrote:
> - Original Message -
>> On Mon, Feb 6, 2012 at 7:47 PM, Jose Fonseca
>> wrote:
>> > Dave,
>> >
>> > I really see no point of inferring anything when translating MOVs.
>> > The src/dst value will need to be converted from/to a floating
On 7 February 2012 13:03, Christoph Bumiller
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. :)
(Doesn't matter too mu
https://bugs.freedesktop.org/show_bug.cgi?id=45277
--- Comment #2 from Damien Grassart 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 the statement in the c
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
>>
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 arr
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
---
src/gallium/drivers/
33 matches
Mail list logo
