brw_SAMPLE is full of complex workarounds for original Broadwater
hardware, and I'd rather avoid all that for my next Ivybridge patch.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_eu.h | 11 +++
src/mesa/drivers/dri/i965/brw_eu_emit.c |
Substantially increases performance in GLBenchmark PRO:
- 320x240 = 3.28x
- 1920x1080 = 1.47x
- 2560x1440 = 1.27x
The LD message ignores the sampler unit index and SAMPLER_STATE pointer,
instead relying on hard-wired default state. Thus, there's no need to
worry about running out of sampler
On Wed, Jan 25, 2012 at 09:40, Jose Fonseca jfons...@vmware.com wrote:
Thanks Stephane. Much better.
I still think the flush flags semantics are quite confusing, but the problem
comes from way before this change. Take e.g. the chunk:
+ /* don't prepare if we only are flushing the
Sorry, guys.
The wayland macros is missing, but i'm not sure how to properly solve this.
We could use m4_ifdef to include it only when wayland is actually available,
but that will require that the packager has it available when creating
the tarballs.
Attaching a patch for that, have you got
Thanks. Your patch lets me build successfully. I can't install wayland
development packages on ubuntu 11.10 due to package conflicts, so there's no
alternative for me here.
I'm not sure about the tarball case. Perhaps you could disable/fail tarball
creation when these macros are missing. But
On Thu, Jan 26, 2012 at 2:24 AM, Eric Anholt e...@anholt.net wrote:
On Wed, 25 Jan 2012 23:56:27 +0100, Marek Olšák mar...@gmail.com wrote:
Hi Eric,
I don't like this, because I don't have drirc in my system. Obviously
Canonical decided not to include it and that also means some of my
users
https://bugs.freedesktop.org/show_bug.cgi?id=45263
Bug #: 45263
Summary: git mesa configure error
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=45263
José Fonseca jfons...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Stephane,
This commit caused a segmentation fault on glean texSwizzle test + llvmpipe:
$ gdb --args glean --run results --overwrite --quick --tests texSwizzle
(gdb) r
Starting program: glean --run results --overwrite --quick --tests texSwizzle
[Thread debugging using libthread_db enabled]
On Wed, Jan 25, 2012 at 8:51 PM, Eric Anholt e...@anholt.net wrote:
Fixes piglit ARB_copy_buffer-overlap, which previously assertion failed.
---
src/mesa/main/bufferobj.c | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git
On Wed, Jan 25, 2012 at 8:51 PM, Eric Anholt e...@anholt.net wrote:
The INVALID_ENUM here may have been trying to catch someone passing
something bogus as the target rather than having a non-buffer bound.
The extension spec and the GL 3.2 specs doesn't say anything specific
for error results
On Wed, Jan 25, 2012 at 8:22 AM, Marek Olšák mar...@gmail.com wrote:
The check for ctx-API was unnecessary, because OES extensions are not exposed
in desktop GL.
Also require renderbuffer support for ARB_texture_rgb10_a2ui,
as per the spec.
Tested by comparing old and new glxinfo with
On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
Color clamping should be enabled in glGetTexImage if texture dataType is
GL_UNSIGNED_NORMALIZED and format is GL_LUMINANCE or GL_LUMINANCE_ALPHA
Fixes 2 Intel oglconform test cases: pxconv-gettex and pxtrans-gettex
On Wed, Jan 25, 2012 at 2:34 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
The warning is absolutely useless. It doesn't actually say that there
are
uninitialized variables. It points out the fact that there are
missing
initializers and that variables are
Hmm, I'll take a look later today.
Stéphane
2012/1/26 Jose Fonseca jfons...@vmware.com:
Stephane,
This commit caused a segmentation fault on glean texSwizzle test + llvmpipe:
$ gdb --args glean --run results --overwrite --quick --tests texSwizzle
(gdb) r
Starting program: glean --run
https://bugs.freedesktop.org/show_bug.cgi?id=45277
Bug #: 45277
Summary: [bisected] Shading not working properly in Heroes of
Newerth
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
Hi list
Just reporting that Unigine folks have already fixed the issue(s):
http://phoronix.com/forums/showthread.php?p=248294#post248294
- Lauri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On Thu, 26 Jan 2012 08:32:08 -0800, Kenneth Graunke kenn...@whitecape.org
wrote:
Substantially increases performance in GLBenchmark PRO:
- 320x240 = 3.28x
- 1920x1080 = 1.47x
- 2560x1440 = 1.27x
The LD message ignores the sampler unit index and SAMPLER_STATE pointer,
instead relying on
On 01/26/2012 11:23 AM, Ian Romanick wrote:
So far, I've only see cases that this series fixes. I have another patch
on top of this (that I'll send out today) that fixes a couple more cases
on i965. I'd like to nominate this entire series for inclusion in 8.0.
If there are no objections, I can
On Tue, Jan 10, 2012 at 6:20 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On Tue, Jan 10, 2012 at 5:15 PM, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
The flag is optional, it doesn't have to implemented by everybody.
If
we do the
On i965, _mesa_ir_link_shader is never called. As a consequence, the
current fragment program (ctx-FragmentProgram-_Current) exists but does
not differ from the fixed function fragment program
(ctx-FragmentProgram-_TexEnvProgram). This confuses swrast.
To fix the confusion, this patch replaces
On Thu, 26 Jan 2012 11:23:24 -0800, Ian Romanick i...@freedesktop.org wrote:
So far, I've only see cases that this series fixes. I have another
patch on top of this (that I'll send out today) that fixes a couple more
cases on i965. I'd like to nominate this entire series for inclusion in
On Thu, Jan 26, 2012 at 2:23 PM, Ian Romanick i...@freedesktop.org wrote:
So far, I've only see cases that this series fixes. I have another patch on
top of this (that I'll send out today) that fixes a couple more cases on
i965. I'd like to nominate this entire series for inclusion in 8.0.
On 01/26/2012 06:40 AM, Brian Paul wrote:
On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogatanuj.pho...@gmail.com wrote:
Color clamping should be enabled in glGetTexImage if texture dataType is
GL_UNSIGNED_NORMALIZED and format is GL_LUMINANCE or GL_LUMINANCE_ALPHA
Fixes 2 Intel oglconform test
On 01/26/2012 01:53 PM, Brian Paul wrote:
On Thu, Jan 26, 2012 at 2:23 PM, Ian Romanicki...@freedesktop.org wrote:
So far, I've only see cases that this series fixes. I have another patch on
top of this (that I'll send out today) that fixes a couple more cases on
i965. I'd like to nominate
On 01/25/2012 05:51 PM, Eric Anholt wrote:
Fixes piglit ARB_copy_buffer-overlap, which previously assertion failed.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
One other orthogonal question below...
---
src/mesa/main/bufferobj.c | 25 +++--
1 files changed,
On 01/25/2012 05:51 PM, Eric Anholt wrote:
The INVALID_ENUM here may have been trying to catch someone passing
something bogus as the target rather than having a non-buffer bound.
The extension spec and the GL 3.2 specs doesn't say anything specific
for error results for either bad target enums
On Thu, Jan 26, 2012 at 4:55 PM, Ian Romanick i...@freedesktop.org wrote:
On 01/26/2012 06:40 AM, Brian Paul wrote:
On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogatanuj.pho...@gmail.com
wrote:
Color clamping should be enabled in glGetTexImage if texture dataType is
GL_UNSIGNED_NORMALIZED and
On 01/25/2012 02:56 PM, Marek Olšák wrote:
Hi Eric,
I don't like this, because I don't have drirc in my system. Obviously
In addition to what Eric and Ken said, each user can have their own
~/.drirc or can set the options via environment variables.
force_glsl_extensions_warn=true
On 01/25/2012 02:29 PM, Eric Anholt wrote:
---
src/glsl/glsl_parser_extras.cpp |3 +++
src/mesa/main/mtypes.h |6 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 0b53232..7f8d47c
On Thu, Jan 26, 2012 at 2:56 PM, Brian Paul brian.e.p...@gmail.com wrote:
On Thu, Jan 26, 2012 at 4:55 PM, Ian Romanick i...@freedesktop.org wrote:
On 01/26/2012 06:40 AM, Brian Paul wrote:
On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogatanuj.pho...@gmail.com
wrote:
Color clamping
On Fri, Jan 27, 2012 at 12:26 AM, Ian Romanick i...@freedesktop.org wrote:
On 01/25/2012 02:56 PM, Marek Olšák wrote:
Hi Eric,
I don't like this, because I don't have drirc in my system. Obviously
In addition to what Eric and Ken said, each user can have their own ~/.drirc
or can set the
https://bugs.freedesktop.org/show_bug.cgi?id=44928
Eric Anholt e...@anholt.net changed:
What|Removed |Added
Status|NEW |RESOLVED
As per OpenGL 3.0 specification section 3.9, page 187 in pdf the maximum
allowable width, height, or depth of a texel array must be at least
2^(k−lod) + 2*bt for image arrays of level-of-detail (lod) 0 through k,
where k is the log base 2 of MAX_3D_TEXTURE_SIZE, and bt is the maximum
border width
https://bugs.freedesktop.org/show_bug.cgi?id=38970
--- Comment #16 from Ian Romanick i...@freedesktop.org 2012-01-26 17:22:05
PST ---
The test fails because the second glXCreateGLXPixmap or glXCreatePixmap tries
to add the same drawable ID to priv-drawHash. The call fails because the key
On Thu, 26 Jan 2012 12:46:03 -0800, Chad Versace chad.vers...@linux.intel.com
wrote:
On i965, _mesa_ir_link_shader is never called. As a consequence, the
current fragment program (ctx-FragmentProgram-_Current) exists but does
not differ from the fixed function fragment program
From: Ian Romanick ian.d.roman...@intel.com
Eventually this path leads to _intel_batchbuffer_flush. The first
thing there is an assertion that nothing is mapped.
Fixes the afore mentioned assertion failure in piglit's
fbo-mipmap-copypix, and is related to bug #43328.
NOTE: This is a candidate
https://bugs.freedesktop.org/show_bug.cgi?id=44039
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Status|NEW |RESOLVED
On 01/26/2012 06:29 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Eventually this path leads to _intel_batchbuffer_flush. The first
thing there is an assertion that nothing is mapped.
Fixes the afore mentioned assertion failure in piglit's
fbo-mipmap-copypix, and is
In preparation for adding GL_PACK/UNPACK_SWAP_BYTES support.
---
src/mesa/main/formats.c | 37 -
1 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index d11b167..834d4c8 100644
---
Not actually used yet though.
---
src/mesa/main/formats.c | 10 ++
src/mesa/main/formats.h |3 ++-
src/mesa/main/readpix.c |3 ++-
src/mesa/swrast/s_drawpix.c |3 ++-
4 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/formats.c
This will let us use memcpy in more situations. We can also remove
the checks for byte spapping that happen before the calls to
_mesa_format_matches_format_and_type().
---
src/mesa/main/formats.c | 131 +--
1 files changed, 93 insertions(+), 38
---
src/mesa/main/formats.c | 24 ++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index a52b38b..cecb70c 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -2733,7 +2733,7 @@
This simplifies the code quite a bit, consolidates some cases and
possibly catches more cases for the memcpy path.
More such changes will follow. Do just a few at a time to help bisect
any possible regressions.
---
src/mesa/main/texstore.c | 48 +++--
1
For rgb565, argb, rgb888, argb functions.
---
src/mesa/main/texstore.c | 26 --
1 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index a3f311a..ef8d097 100644
--- a/src/mesa/main/texstore.c
+++
For rgba5551, argb1555, argb2101010 formats.
---
src/mesa/main/texstore.c | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index ef8d097..3bfea8c 100644
--- a/src/mesa/main/texstore.c
+++
For rgb332, signed rgba, signed rgba888_rev functions.
---
src/mesa/main/texstore.c | 23 ---
1 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 3bfea8c..9a12cc1 100644
--- a/src/mesa/main/texstore.c
For rgb9_e5, r11_g11_b10f, argb2101010_uint functions.
---
src/mesa/main/texstore.c | 19 +++
1 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 9a12cc1..55156e7 100644
--- a/src/mesa/main/texstore.c
+++
It's handled by _mesa_format_matches_format_and_type() now.
---
src/mesa/main/readpix.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 71de0b3..908a55e 100644
--- a/src/mesa/main/readpix.c
+++
I just took a look at it in gdb. Basically the jit_func pointer is
corrupted by the free_gallivm_state function (in lp_bld_init.c). There
is a comment to that effect already. It seems like the bug was always
there but hidden because we regenerated state more than we had to.
I'll keep digging...
So actually it's a case of a use-after free. The variant is freed with
draw_llvm_destroy_variant and then reused through
llvm_pipeline_generic after free_gallium_state (and llvm) reused the
memory for something else. What prevents a variant bound to an fpme
from being freed by the garbage
Ok so I'm thinking of adding a refcount to the variant to know if they
are bound, and not garbage collect them in that case. Let me know what
you think.
Stéphane
2012/1/26 Stéphane Marchesin stephane.marche...@gmail.com:
So actually it's a case of a use-after free. The variant is freed with
---
Please give this a try.
OSMesa is broken with shared-glapi. I'll fix that (it'll be much
easier) when I automake glapi.
configs/autoconf.in |2 -
configure.ac | 10 +++-
src/mesa/Makefile| 17 +--
https://bugs.freedesktop.org/show_bug.cgi?id=44618
Matt Turner matts...@gmail.com changed:
What|Removed |Added
CC||matts...@gmail.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=44618
--- Comment #9 from Thierry Reding thierry.red...@avionic-design.de
2012-01-26 23:32:19 PST ---
(In reply to comment #8)
I think I can partially fix this with automake.
Automake doesn't have a concept for host vs target $(CC)s, so you can't
55 matches
Mail list logo
