On Sat, 2011-09-24 at 21:06 -0400, Matt Turner wrote:
> The last discussion about using automake ("[RFC] Convert mesa to
> automake/libtool")
> ended without anything happening, probably because the branch wasn't
> ready.
>
> This patch is an attempt to get the ball rolling again. Without
> rippi
On Sat, 2011-09-24 at 21:06 -0400, Matt Turner wrote:
> The patch has a few problems currently, and a few things that can
> possibly be
> done better:
> - Mainly, that building libmesa.a currently fails.
> - Not sure how to handle shared/static dricore options.
> - libtool
On Sun, 2011-09-25 at 15:41 -0400, Matt Turner wrote:
> On Sun, Sep 25, 2011 at 3:06 PM, Gaetan Nadon wrote:
> > I had a quick look, configure.ac is huge and has a big impact on Makefiles.
> > I think it should be reviewed and cleaned-up to understand how it affects
> > makefiles.
> >
> > Just a
On Sun, 2011-09-25 at 16:55 -0400, Matt Turner wrote:
> On Sun, Sep 25, 2011 at 4:22 PM, Gaetan Nadon wrote:
> > If you are moving towards a non-hacked automake world, the INSTALL variable
> > should not be used for mesa makefiles. It all depends on the end goals and
> > the motivation behind the
Am 26.09.11, 07:21 +0200 schrieb Luc Verhaegen:
* Martin Peres - Nouveau
* Alon Levy - Xspice
* Chris Wilson - Cairo
Only half the amount needed, with 5 days left. Surely we can do better
than that for X/Mesa/Wayland/Anything graphics.
I can talk about ICC colour management on top of a composi
On Tue, Sep 27, 2011 at 12:22 PM, Eric Anholt wrote:
> On Thu, 22 Sep 2011 15:36:07 -0500, Rob Clark wrote:
>> Since I was working on some extensions to DRI2 protocol for handling
>> video, it occurred to me that it might be easier to extend the
>> protocol if there weren't N different copies of
On 09/27/2011 03:28 PM, Chad Versace wrote:
> It was replaced by _mesa_override_glsl_version().
>
> Signed-off-by: Chad Versace
> ---
> src/mesa/drivers/dri/intel/intel_extensions.c | 16
> 1 files changed, 0 insertions(+), 16 deletions(-)
I'd probably just squash these two (
On 09/27/2011 03:08 PM, Eric Anholt wrote:
> They're both implemented the same in GLSL IR (since round() has
> undefined behavior for N.5).
>
> Fixes glsl-1.30/compiler/built-in-functions/round*
> ---
> src/glsl/ir_constant_expression.cpp | 10 ++
> 1 files changed, 10 insertions(+), 0
On 09/27/2011 03:08 PM, Eric Anholt wrote:
> Bitshifts are one of the rare places that GLSL allows mixed base types
> without an implicit conversion occurring.
> ---
> src/glsl/ir_constant_expression.cpp |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/src/glsl/ir_
On 09/27/2011 03:08 PM, Eric Anholt wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> index df43be0..d8ce
On 09/27/2011 03:08 PM, Eric Anholt wrote:
> For hardware drivers, we only have ir_to_mesa called for the purposes
> of potential swrast fallbacks (basically never on a 1.30 driver),
> which we don't really care about. This will allow 1.30 to be
> implemented without rewriting swrast for it.
> ---
Gaetan Nadon writes:
> - The minimum autoconf version should be 2.60. Features above 2.60
> should not be used. Starting v 2.62 there is a license controversy
What is that?
[The NEWS file doesn't show any license changes in 2.62. Autoconf
itself switched to the GPLv3 in 2.65, but I'm not sure w
On Wed, Sep 28, 2011 at 3:54 AM, Miles Bader wrote:
> Gaetan Nadon writes:
>> - The minimum autoconf version should be 2.60. Features above 2.60
>> should not be used. Starting v 2.62 there is a license controversy
>
> What is that?
>
> [The NEWS file doesn't show any license changes in 2.62. Au
On Wed, 28 Sep 2011 01:21:50 -0700, Kenneth Graunke
wrote:
> On 09/27/2011 03:08 PM, Eric Anholt wrote:
> > ---
> > src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |8 +++-
> > 1 files changed, 7 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cp
On Wed, 28 Sep 2011 01:06:14 -0700, Kenneth Graunke
wrote:
> On 09/27/2011 03:08 PM, Eric Anholt wrote:
> > They're both implemented the same in GLSL IR (since round() has
> > undefined behavior for N.5).
> >
> > Fixes glsl-1.30/compiler/built-in-functions/round*
> > ---
> > src/glsl/ir_constan
On Tue, Sep 27, 2011 at 11:28 PM, Chad Versace wrote:
> Override the context's GLSL version if the environment variable
> MESA_GLSL_VERSION_OVERRIDE is set. Valid values for
> MESA_GLSL_VERSION_OVERRIDE are integers, such as "130".
>
> MESA_GLSL_VERSION_OVERRIDE has the same behavior as INTEL_GLSL
This patch fixes many Piglit tests [failing due to assert(region->map_refcount
== 0)]
on SNB when HiZ is enabled, and causes no regressions.
Tested-by: Chad Versace
On 09/27/2011 12:27 PM, Eric Anholt wrote:
From: Brian Paul
Now that we can zero-copy generate the mipmaps into brand new
glTex
On 09/27/2011 01:15 PM, Eric Anholt wrote:
On Fri, 23 Sep 2011 15:04:13 -0600, Brian Paul wrote:
Non-text part: multipart/mixed
On 09/22/2011 07:24 PM, Brian Paul wrote:
On Thu, Sep 22, 2011 at 6:14 PM, Eric Anholt wrote:
Here's an extract of what I had in one of my branches for mti, with a
On 09/27/2011 01:27 PM, Eric Anholt wrote:
From: Brian Paul
Now that we can zero-copy generate the mipmaps into brand new
glTexImage()-generated storage using MapTextureImage(), we no longer
need to allocate image->Data in mipmap generate. This requires
deleting the drivers' old overrides of th
https://bugs.freedesktop.org/show_bug.cgi?id=41263
Marek Olšák changed:
What|Removed |Added
Product|DRI |Mesa
Version|XOrg CVS
v.3. "This time for sure!"
I've cleaned up the series quite a bit, squashing some patches and
splitting others out to try and make it easier to review and avoid
breakage. As such, I've dropped most of the R-b's since this series
doesn't necessarily look much like the last one.
piglit -t op-mod -t
Drivers implementing GLSL 1.30 want to do integer modulus, and until we
can stop generating code via ir_to_mesa, it's easier to make it silently
generate rubbish code. Multiply will do.
Signed-off-by: Kenneth Graunke
---
src/mesa/program/ir_to_mesa.cpp |5 -
1 files changed, 4 insertion
BRW_MATH_FUNCTION_REMAINDER was missing. Also, it seems worthwhile to
assert that INT DIV's arguments are signed/unsigned integers.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/
Both POW and INT DIV need a message length of 2; previously, we only
checked for POW.
Also, BRW_MATH_FUNCTION_INT_DIV_QUOTIENT_AND_REMAINDER has a response
length of 2; previously, we only checked for SINCOS. We don't use this
message, but in case we ever decide to, we may as well fix it now.
Wh
It never mattered before since we only did floating point math.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_eu_emit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_defines.h|2 ++
src/mesa/drivers/dri/i965/brw_fs.cpp | 16 ++--
src/mesa/drivers/dri/i965/brw_fs.h |2 ++
src/mesa/drivers/dri/i965/brw_fs_emit.cpp |2 ++
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.cpp |2 ++
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp|4 +++-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 22 +++---
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/sr
Apparently on Gen4 and 5, the denominator comes first.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp| 17 +++--
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 17 +++--
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/sr
Signed-off-by: Kenneth Graunke
Reviewed-by: Eric Anholt
---
src/mesa/drivers/dri/i965/brw_shader.cpp |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index c938c75..974905d 100644
--- a/s
We were checking whether render_condition is set. That was not reliable,
because it's always set with trace and noop regardless of driver support.
---
src/gallium/drivers/nv50/nv50_screen.c |1 +
src/gallium/drivers/nvc0/nvc0_screen.c |1 +
src/gallium/drivers/r300/
Same issue as with conditional_render.
---
src/gallium/drivers/nv50/nv50_screen.c |1 +
src/gallium/drivers/nvc0/nvc0_screen.c |1 +
src/gallium/drivers/r300/r300_screen.c |1 +
src/gallium/drivers/r600/r600_pipe.c |1 +
src/gallium/include/pipe/p_defines.h |3 ++-
src/mesa
This removes:
- PIPE_CAP_MAX_TEXTURE_IMAGE_UNITS
- PIPE_CAP_MAX_VERTEX_TEXTURE_UNITS
in favor of the that new per-shader cap.
---
src/gallium/auxiliary/tgsi/tgsi_exec.h |2 +
src/gallium/drivers/cell/ppu/cell_screen.c |9 --
src/gallium/drivers/i915/i915_screen.c
Hi everyone,
I plan on moving all files from winsys/r600 into drivers/r600. The
r600 winsys sits between drivers/r600 and winsys/radeon and has had no
longer access to the DRM file descriptor, so it's pretty much a
non-winsys.
What would get merged is here (there are some other cleanups too, 6
co
On , Matt Turner wrote:
> In short, 2.62 is the first version that includes GPLv3 tools to build
> autoconf, even though what is installed is GPLv2.
>
> [1] http://lists.x.org/archives/xorg-devel/2011-June/022724.html
Thanks, that explains the significance of 2.62 -- but it doesn't
actually expla
On 09/28/11 09:58 AM, Miles Bader wrote:
On , Matt Turner wrote:
[1] http://lists.x.org/archives/xorg-devel/2011-June/022724.html
Thanks, that explains the significance of 2.62 -- but it doesn't
actually explain the problem; it just says "In order to build it, I
would have to accept GPLv3 (wh
On Don, 2011-09-29 at 02:47 +0200, Marek Olšák wrote:
> Hi everyone,
>
> I plan on moving all files from winsys/r600 into drivers/r600. The
> r600 winsys sits between drivers/r600 and winsys/radeon and has had no
> longer access to the DRM file descriptor, so it's pretty much a
> non-winsys.
>
>
2011/9/29 Alan Coopersmith :
>> _Why_ is the GPLv3 "not acceptable", when the GPLv2 was?
>
> Note his employer, which is well known as not accepting the GPLv3,
> possibly due to it being a mobile phone manufacturer, and the GPLv3's
> free patent license grant not fitting well with the current mobil
37 matches
Mail list logo
