On Wed, Feb 15, 2012 at 11:28 PM, Ian Romanick wrote:
> Over the last six months a lot of feature work has happened in Mesa, and the
> load has been carried by a lot of different people / organization. In the
> process, we discovered a number of development process issues that made
> things more d
On 02/15/2012 04:58 AM, tf (mobile) wrote:
Personally i don't care much about non-autoconf builds, but as this relies on a
-DTLS= setting during configuration time, it will break non-ac builds (which
need tls), no?
Other than that, LGTM.
-tom
That's okay, we've already broken non-automake b
https://bugs.freedesktop.org/show_bug.cgi?id=41791
Marcus Meissner changed:
What|Removed |Added
CC||mar...@jet.franken.de
--- Comment #6 f
On 02/16/2012 01:42 AM, Kenneth Graunke wrote:
On 02/15/2012 04:58 AM, tf (mobile) wrote:
Personally i don't care much about non-autoconf builds, but as this
relies on a -DTLS= setting during configuration time, it will break
non-ac builds (which need tls), no?
Other than that, LGTM.
-tom
Th
On 02/15/2012 05:39 PM, Anuj Phogat wrote:
As suggested by Brian, for a 1D texture array, the border only applies to
the width. For a 2D texture array the border applies to the width and
height but not to the depth. This was not handled correctly in
_mesa_init_teximage_fields().
Note: This is a
On 02/15/2012 04:28 PM, Ian Romanick wrote:
Over the last six months a lot of feature work has happened in Mesa,
and the load has been carried by a lot of different people /
organization. In the process, we discovered a number of development
process issues that made things more difficult than the
On 02/16/2012 01:04 AM, Dave Airlie wrote:
On Wed, Feb 15, 2012 at 11:28 PM, Ian Romanick wrote:
Over the last six months a lot of feature work has happened in Mesa, and the
load has been carried by a lot of different people / organization. In the
process, we discovered a number of development
On 02/15/2012 07:01 PM, Eric Anholt wrote:
None of the consumers of this state will be called while the fs or vs
is in place, and the update_texture_state() call will get re-called on
fs/vs change, so it should be safe to skip the computation. Improves
the performance of a VS state change microb
On 02/15/2012 07:01 PM, Eric Anholt wrote:
There are three reasons left for this function flagging it:
Re-computing completeness (and therefore the number of levels),
binding a new current texture object, or you're doing some sort of
fixed function (and nobody cares). For other cases, like rebin
On Wed, 15 Feb 2012 15:41:01 -0700, Brian Paul wrote:
> If the texture format is integer, the incoming user data must also be
> integer (and similarly for non-integer textures).
>
> NOTE: This is a candidate for the stable branches.
> ---
> src/mesa/main/teximage.c | 11 +++
> 1 files
On 15 February 2012 15:28, Ian Romanick wrote:
> Over the last six months a lot of feature work has happened in Mesa, and
> the load has been carried by a lot of different people / organization. In
> the process, we discovered a number of development process issues that made
> things more difficu
>
> 1. Missing checks for error conditions that the spec requires an
> implementation to check for.
>
> 2. Newly-added state is not being saved/restored properly by meta-ops.
>
> 3. Overzealous error checks: some error condition is not being checked for
> in the correct way, causing an error to be
As suggested by Brian, for a 1D texture array, the border only applies to
the width. For a 2D texture array the border applies to the width and
height but not the depth. This was not handled correctly in
_mesa_init_teximage_fields().
Note: This is a candidate for stable branches
Signed-off-by:
On 02/16/2012 11:38 AM, Anuj Phogat wrote:
As suggested by Brian, for a 1D texture array, the border only applies to
the width. For a 2D texture array the border applies to the width and
height but not the depth. This was not handled correctly in
_mesa_init_teximage_fields().
Note: This is a c
Here's a respin of the VBO fixes, incorporating feedback from Roland,
Brian, and Ian.
I'm not entirely happy with this series. If you look at the resulting
code, we end up marking the range invalid if:
1. (int) start + basevertex < 0
2. (int) end + basevertex < 0
3. start + basevertex >= _MaxE
The application supplied [start, end] range is merely a conservative
hint of the ranges of index values inside the index buffer. There is no
requirement that all vertices in the range [start, end] be referenced.
Passing an 'end' value larger than the maximum legal index is perfectly
acceptible; a
Some applications, such as Regnum Online, appear to pass invalid
start/end values to glDrawRangeElements. In particular, the 'start'
index sometimes exceeds the maximum array element. This is clearly
invalid behavior, and although the spec isn't clear, seems to result
in undefined, implementation
This failed to take basevertex into account:
If basevertex < 0:
(end + basevertex) might actually be in-bounds while 'end' is not.
We would have clamped in this case when we probably shouldn't.
This could break application drawing.
If basevertex > 0:
'end' might be in-bounds while (en
Now that we have a index_range_invalid flag, we can just use that rather
than calling vbo_validated_drawrangeelements directly and returning.
NOTE: This is a candidate for release branches.
Signed-off-by: Kenneth Graunke
Reviewed-by: Brian Paul
---
src/mesa/vbo/vbo_exec_array.c |6 +-
https://bugs.freedesktop.org/show_bug.cgi?id=46191
Bug #: 46191
Summary: mesa lacks manpages
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: Other
OS/Version: Linux (All)
Status: NEW
Severit
Am 16.02.2012 20:14, schrieb Kenneth Graunke:
> Here's a respin of the VBO fixes, incorporating feedback from Roland,
> Brian, and Ian.
>
> I'm not entirely happy with this series. If you look at the resulting
> code, we end up marking the range invalid if:
>
> 1. (int) start + basevertex < 0
>
This field allows to address output variables more precisely
(varyings won't have to "hold" a whole register if they are not vec4).
---
src/glsl/ir.cpp |1 +
src/glsl/ir.h | 22 ++
src/glsl/ir_clone.cpp |1 +
src/glsl/linker.cpp |6 +-
4 files
---
src/mesa/drivers/dri/i965/brw_fs.cpp |4 +-
src/mesa/drivers/dri/i965/brw_vec4.h | 13
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 89 +---
3 files changed, 93 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_f
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 37 +++
1 files changed, 31 insertions(+), 6 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..b65fad6 100644
--- a/src/mesa/state_tracker/st_
---
src/mesa/main/mtypes.h| 10 ++
src/mesa/main/shaderapi.c |1 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index a2b01d0..f2f2dae 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2389,6 +2
---
src/glsl/linker.cpp | 125 ++-
1 files changed, 74 insertions(+), 51 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 8e690ac..4a5e3bb 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1813,6 +1813,36 @@ as
---
src/glsl/linker.cpp | 442 +++
1 files changed, 442 insertions(+), 0 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 4a5e3bb..8441854 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1815,6 +1815,369 @@ a
---
src/mesa/drivers/dri/i965/brw_context.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 87ea1a5..fbfaeba 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers
Hi everyone,
The main motivation behind this series is to move updates of invariant
registers to the beginning of CS. Invariant registers are those which never
change thoughout a CS, so they don't need to be part of gallium states and
examined everytime such states are changed. Besides that, th
---
src/gallium/drivers/r600/evergreen_hw_context.c |5 -
src/gallium/drivers/r600/evergreen_state.c | 14 +++---
src/gallium/drivers/r600/r600_hw_context.c |3 ---
src/gallium/drivers/r600/r600_pipe.h| 20 ++--
src/gallium/drivers/r600
The code was almost the same for r600 and eg. What can't be consolidated is
in the *_prepare functions.
---
src/gallium/drivers/r600/evergreen_hw_context.c | 55 --
src/gallium/drivers/r600/r600.h | 15 +-
src/gallium/drivers/r600/r600_hw_context.c
This is a state which is derived from other states and is actually the first
state which doesn't correspond to any gallium state.
There are two state flags:
bool occlusion_query_enabled
bool flush_depthstencil_enabled
Additional flags can be added later if needed, e.g. bool hiz_enabled.
The e
---
src/gallium/drivers/r600/r600_hw_context.c | 38
src/gallium/drivers/r600/r600_pipe.h | 16
src/gallium/drivers/r600/r600_state.c | 130 ++--
3 files changed, 82 insertions(+), 102 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_hw
---
src/gallium/drivers/r600/evergreen_hw_context.c | 48 ---
src/gallium/drivers/r600/evergreen_state.c | 155 +--
src/gallium/drivers/r600/r600_pipe.h| 15 +++
3 files changed, 100 insertions(+), 118 deletions(-)
diff --git a/src/gallium/drivers/r60
https://bugs.freedesktop.org/show_bug.cgi?id=46191
Sven Arvidsson changed:
What|Removed |Added
CC||s...@whiz.se
--- Comment #1 from Sven A
This avoids extra if statements in the common case of just comparing
two expressions that don't involve assignments or function calls,
along with simplifying the handling of constant expressions. Since GL
3.0 availability, my actual application testcases for improvement from
this patch have appare
On Thu, Feb 16, 2012 at 10:04:07PM +0100, Marek Olšák wrote:
> Hi everyone,
>
> The main motivation behind this series is to move updates of invariant
> registers to the beginning of CS. Invariant registers are those which never
> change thoughout a CS, so they don't need to be part of gallium s
There are three reasons left for this function flagging it:
Re-computing completeness (and therefore the number of levels),
binding a new current texture object, or you're doing some sort of
fixed function (and nobody cares). For other cases, like rebinding a
shader, we no longer trigger the drive
None of the consumers of this state will be called while the fs or vs
is in place, and the update_texture_state() call will get re-called on
fs/vs change, so it should be safe to skip the computation. Improves
the performance of a VS state change microbenchmark by 1.60186% +/-
0.443318% (n=20).
v
It was concerned that the 4 pad bytes on LP64 were uninitialized.
---
src/mesa/drivers/dri/intel/intel_screen.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 60781e5..4eeeb2f 100
On Thu, Feb 16, 2012 at 12:28 AM, Ian Romanick wrote:
> Over the last six months a lot of feature work has happened in Mesa, and the
> load has been carried by a lot of different people / organization. In the
> process, we discovered a number of development process issues that made
> things more d
On Tue, 14 Feb 2012 10:57:17 -0800, "Ian Romanick" wrote:
> From: Ian Romanick
>
> Before calling _tnl_run_pipeline, the i915 driver maps all textures
> used in vertex shaders (via intel_tex_map_images). Later run_vp tries
> to map the textures again (via _swrast_map_texture). However, this
>
As suggested by Brian, for a 1D texture array, the border only applies to the
width. For a 2D texture array the border applies to the width and height but
not the depth. This was not handled correctly _mesa_init_teximage_fields().
Note: This is a candidate for stable branches
Signed-off-by: Anu
On 02/16/2012 04:40 PM, Eric Anholt wrote:
None of the consumers of this state will be called while the fs or vs
is in place, and the update_texture_state() call will get re-called on
fs/vs change, so it should be safe to skip the computation. Improves
the performance of a VS state change microb
On 02/16/2012 04:40 PM, Eric Anholt wrote:
There are three reasons left for this function flagging it:
Re-computing completeness (and therefore the number of levels),
binding a new current texture object, or you're doing some sort of
fixed function (and nobody cares). For other cases, like rebin
On Fri, 17 Feb 2012 00:45:00 +0100, Marek Olšák wrote:
> I think the problem is not in the process itself, but in the fact that
> this project lacks manpower (at least outside of the Intel camp) and I
> am afraid it will not get better without another 5-10 people working
> full-time on the project
On 02/16/2012 07:08 AM, Brian Paul wrote:
On 02/15/2012 04:28 PM, Ian Romanick wrote:
Over the last six months a lot of feature work has happened in Mesa,
and the load has been carried by a lot of different people /
organization. In the process, we discovered a number of development
process issu
On 02/16/2012 03:45 PM, Marek Olšák wrote:
On Thu, Feb 16, 2012 at 12:28 AM, Ian Romanick wrote:
Over the last six months a lot of feature work has happened in Mesa, and the
load has been carried by a lot of different people / organization. In the
process, we discovered a number of development
On 02/16/2012 04:11 PM, Anuj Phogat wrote:
As suggested by Brian, for a 1D texture array, the border only applies to the
width. For a 2D texture array the border applies to the width and height but
not the depth. This was not handled correctly _mesa_init_teximage_fields().
Note: This is a cand
A winsys is already a private object of a driver.
---
src/gallium/drivers/galahad/glhd_context.c |1 -
src/gallium/drivers/galahad/glhd_screen.c |2 --
src/gallium/drivers/i915/i915_context.c|1 -
src/gallium/drivers/i915/i915_screen.c |2 --
src/gallium/dr
Deprecated and unused.
---
src/gallium/auxiliary/util/u_simple_screen.h | 180 --
src/gallium/drivers/nouveau/nouveau_screen.c |1 -
src/gallium/drivers/nvfx/nvfx_screen.c |1 -
3 files changed, 0 insertions(+), 182 deletions(-)
delete mode 100644 src/galliu
Suggested by José.
---
src/gallium/auxiliary/cso_cache/cso_cache.c | 24 -
src/gallium/auxiliary/cso_cache/cso_cache.h | 16
src/gallium/auxiliary/cso_cache/cso_context.c | 118 -
src/gallium/auxiliary/cso_cache/cso_context.h | 13 ---
4 files changed, 0
On 02/16/2012 05:11 PM, Anuj Phogat wrote:
As suggested by Brian, for a 1D texture array, the border only applies to the
width. For a 2D texture array the border applies to the width and height but
not the depth. This was not handled correctly _mesa_init_teximage_fields().
Note: This is a cand
On 02/16/2012 06:04 PM, Ian Romanick wrote:
On 02/16/2012 04:11 PM, Anuj Phogat wrote:
As suggested by Brian, for a 1D texture array, the border only
applies to the
width. For a 2D texture array the border applies to the width and
height but
not the depth. This was not handled correctly
_mesa_in
On 02/16/2012 04:48 PM, Eric Anholt wrote:
On Tue, 14 Feb 2012 10:57:17 -0800, "Ian Romanick" wrote:
From: Ian Romanick
Before calling _tnl_run_pipeline, the i915 driver maps all textures
used in vertex shaders (via intel_tex_map_images). Later run_vp tries
to map the textures again (via _swr
https://bugs.freedesktop.org/show_bug.cgi?id=46204
Bug #: 46204
Summary: Missing support of pointcoord and point size in Mesa
core
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
OS
https://bugs.freedesktop.org/show_bug.cgi?id=46204
zhao jian changed:
What|Removed |Added
AssignedTo|mesa-dev@lists.freedesktop. |yuanhan@intel.com
|org
As suggested by Brian, for a 1D texture array, the border only applies to the
width. For a 2D texture array the border applies to the width and height but
not the depth. This was not handled correctly _mesa_init_teximage_fields().
Note: This is a candidate for stable branches
Signed-off-by: Anu
https://bugs.freedesktop.org/show_bug.cgi?id=45277
--- Comment #3 from Chris 2012-02-16 20:14:30 PST ---
I can confirm this too.
I also noticed around the same time (I assume the same commit) that Mass Effect
2 has serious rendering issues with some textures through wine.
--
Configure bugmail:
Commit 980f6f1 (mesa: move gl_texture_image::Width/Height/DepthScale
fields to swrast) moved the initialization of the Width, Height, and
DepthScale fields to _swrast_alloc_texture_image_buffer(). However,
i915 doesn't call this function because it performs its own buffer
allocation. As a result,
Mesa 8.0.1 has been released. Mesa 8.0.1 is a bug fix release which
fixes bugs found since the 8.0 release.
The tag in the GIT repository for Mesa 8.0.1 is 'mesa-8.0.1'.
Mesa 8.0.1 is available for download at
ftp://freedesktop.org/pub/mesa/8.0.1/
md5sums:
4855c2d93bd2ebd43f384bdcc92c9a27 M
On 02/16/2012 10:57 PM, Paul Berry wrote:
Commit 980f6f1 (mesa: move gl_texture_image::Width/Height/DepthScale
fields to swrast) moved the initialization of the Width, Height, and
DepthScale fields to _swrast_alloc_texture_image_buffer(). However,
i915 doesn't call this function because it perfo
Improves citybench performance by 39.8638% +/- 2.26632% (n=10) (at
default resolution and about the same for 320x240).
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c |5 -
src/mesa/drivers/dri/intel/intel_context.c | 21 +
2 files changed, 17 insertions(+), 9
63 matches
Mail list logo
