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
---
src/mesa/drivers/dri/i965/brw_eu.h | 11 +++
src/mesa/drivers/dri/i965/brw_eu_emit.c | 21 +++
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
Benjamin,
I'm getting build failures with your commit:
+ ./autogen.sh --prefix=/usr --enable-gles1 --enable-gles2 --enable-openvg
--enable-xorg --enable-xa --disable-glut --enable-gallium-egl
--enable-gallium-llvm --with-dri-drivers=swrast
--with-gallium-drivers=i915,nouveau,r300,r600,svga,swr
On Wed, Jan 25, 2012 at 09:40, Jose Fonseca 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 backend */
> +
Fails here too (fedora 15).
Stéphane
On Thu, Jan 26, 2012 at 01:35, Jose Fonseca wrote:
> Benjamin,
>
> I'm getting build failures with your commit:
>
> + ./autogen.sh --prefix=/usr --enable-gles1 --enable-gles2 --enable-openvg
> --enable-xorg --enable-xa --disable-glut --enable-gallium-egl
>
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 bette
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 fo
On Thu, Jan 26, 2012 at 2:24 AM, Eric Anholt wrote:
> On Wed, 25 Jan 2012 23:56:27 +0100, Marek Olšák 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 don't have it. Please
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 changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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]
Progra
On Wed, Jan 25, 2012 at 8:51 PM, Eric Anholt 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 a/src/mesa/main/bufferobj.c b/src/m
On Wed, Jan 25, 2012 at 8: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 ba
On Wed, Jan 25, 2012 at 8:22 AM, Marek Olšák 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 softpipe and r
On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogat 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
> https://bugs.freedes
On Wed, Jan 25, 2012 at 2:34 PM, Jose Fonseca 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 initialized to zer
Hmm, I'll take a look later today.
Stéphane
2012/1/26 Jose Fonseca :
> 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 --overwri
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
http://lists.freedesktop.org/mailman/listinfo/mesa-
On Thu, 26 Jan 2012 08:32:08 -0800, Kenneth Graunke
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 hard-wired d
On Wed, 25 Jan 2012 19:38:10 -0800, Chad Versace
wrote:
> On i965, _mesa_ir_link_shader is never called. As a consequence,
> ctx->FragmentProgram->_Current exists but contains no instructions. This
> greatly confuses swrast.
I don't think this is valid. You're replacing checks for "is there a
f
On 01/26/2012 09:03 AM, Eric Anholt wrote:
On Thu, 26 Jan 2012 08:32:08 -0800, Kenneth Graunke
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 point
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 cherry pick this Friday morning.
Friday
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 ch
On Tue, Jan 10, 2012 at 6:20 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On Tue, Jan 10, 2012 at 5:15 PM, Jose Fonseca
>> wrote:
>> > - Original Message -
>> >> The flag is optional, it doesn't have to implemented by everybody.
>> >> If
>> >> we do the uploads in the sta
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 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 objectio
On Thu, 26 Jan 2012 11:23:24 -0800, 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 ar
On Thu, Jan 26, 2012 at 2:23 PM, 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 o
On 01/26/2012 06:40 AM, Brian Paul wrote:
On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogat 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
On 01/26/2012 01:53 PM, Brian Paul wrote:
On Thu, Jan 26, 2012 at 2:23 PM, 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
On 01/25/2012 05:51 PM, Eric Anholt wrote:
Fixes piglit ARB_copy_buffer-overlap, which previously assertion failed.
Reviewed-by: Ian Romanick
One other orthogonal question below...
---
src/mesa/main/bufferobj.c | 25 +++--
1 files changed, 19 insertions(+), 6 deleti
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 o
On Thu, Jan 26, 2012 at 4:55 PM, Ian Romanick wrote:
> On 01/26/2012 06:40 AM, Brian Paul wrote:
>>
>> On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogat
>> wrote:
>>>
>>> Color clamping should be enabled in glGetTexImage if texture dataType is
>>> GL_UNSIGNED_NORMALIZED and format is GL_LUMINANCE or
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 ./some_gl_
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 100
On Thu, Jan 26, 2012 at 2:56 PM, Brian Paul wrote:
> On Thu, Jan 26, 2012 at 4:55 PM, Ian Romanick wrote:
> > On 01/26/2012 06:40 AM, Brian Paul wrote:
> >>
> >> On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogat
> >> wrote:
> >>>
> >>> Color clamping should be enabled in glGetTexImage if texture da
On Fri, Jan 27, 2012 at 12:26 AM, Ian Romanick 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 options
https://bugs.freedesktop.org/show_bug.cgi?id=44928
Eric Anholt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 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
already exists.
--
Confi
On Thu, 26 Jan 2012 12:46:03 -0800, Chad Versace
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
> (ctx->FragmentProgram->_TexEnvProgram)
From: Ian Romanick
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 for the 8.0 branch.
Sign
https://bugs.freedesktop.org/show_bug.cgi?id=44039
Ian Romanick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 01/26/2012 06:29 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> 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 #4
GL_UNPACK_LSB_FIRST only applies to bitmap data, not glReadPixels.
---
src/mesa/main/readpix.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index c1489d2..84b5224 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/mai
The outer conditional already did the test.
---
src/mesa/main/pack.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index f874ab2..1712003 100644
--- a/src/mesa/main/pack.c
+++ b/src/mesa/main/pack.c
@@ -2020,14 +2020,10
---
src/mesa/main/formats.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index 96317db..e14aa75 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -2568,7 +2568,7 @@ _mesa_format_matches_format_and_ty
---
src/mesa/main/formats.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index e14aa75..d11b167 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -2571,7 +2571,7 @@ _mesa_format_matches_format_and_ty
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
--- a/src/mesa/main
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 b/src/mes
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 deletio
---
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 @@ _mesa_forma
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
+++ b/s
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
+++ b/src/mesa/mai
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
+++ b/src
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
+++ b/src/mesa/main/rea
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...
St
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 collectio
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 :
> So actually it's a case of a use-after free. The variant is freed with
> draw_llvm_destroy_variant an
---
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 +--
src/mesa/drivers/osmes
https://bugs.freedesktop.org/show_bug.cgi?id=44618
Matt Turner changed:
What|Removed |Added
CC||matts...@gmail.com
--- Comment #8 from Mat
https://bugs.freedesktop.org/show_bug.cgi?id=44618
--- Comment #9 from Thierry Reding
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 really
> compile a single bina
65 matches
Mail list logo
