https://bugs.freedesktop.org/show_bug.cgi?id=40920
--- Comment #2 from Andreas Betz andreas.b...@elektrobit.com 2011-09-21
00:29:40 PDT ---
Hi,
sry that i forgot to mention it ... im using the llvmpipe (because ... it is
simply faster ...).
Using the soft-pipe it look good ... but it is very
On Tue, 20 Sep 2011 08:20:27 -0700
Paul Berry stereotype...@gmail.com wrote:
On 20 September 2011 01:05, Tolga Dalman tolga.dal...@googlemail.comwrote:
Tolga, your uneasiness is certainly justified in terms of conventional
wisdom. As someone who used to write numerical analysis software, I
https://bugs.freedesktop.org/show_bug.cgi?id=41074
Summary: Build broken - CHAN_TYPE undeclared
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: blocker
Priority: medium
On Die, 2011-09-20 at 12:55 -0600, Brian Paul wrote:
On 09/20/2011 10:40 AM, Michel Dänzer wrote:
On Don, 2011-09-15 at 13:01 -0600, Brian Paul wrote:
On 09/15/2011 10:08 AM, Michel Dänzer wrote:
On Don, 2011-09-15 at 09:01 -0600, Brian Paul wrote:
On 09/15/2011 04:55 AM, Michel Dänzer
https://bugs.freedesktop.org/show_bug.cgi?id=41074
Brian Paul brian.e.p...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=41065
Brian Paul brian.e.p...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Messaggio originale
Da: kei...@vmware.com
Data: 20/09/2011 16.45
A: Roland Scheideggersrol...@vmware.com
Cc: Fabiofabio@libero.it, mesa-dev@lists.freedesktop.org
Ogg: Re: [Mesa-dev] Building with -fno-builtin-memcmp for improved
performance
On Tue, 2011-09-20 at 16:35 +0200, Roland
Am 21.09.2011 14:24, schrieb Fabio:
Messaggio originale
Da: kei...@vmware.com
Data: 20/09/2011 16.45
A: Roland Scheideggersrol...@vmware.com
Cc: Fabiofabio@libero.it, mesa-dev@lists.freedesktop.org
Ogg: Re: [Mesa-dev] Building with -fno-builtin-memcmp for improved
On 09/21/2011 03:36 AM, Michel Dänzer wrote:
On Die, 2011-09-20 at 12:55 -0600, Brian Paul wrote:
On 09/20/2011 10:40 AM, Michel Dänzer wrote:
On Don, 2011-09-15 at 13:01 -0600, Brian Paul wrote:
On 09/15/2011 10:08 AM, Michel Dänzer wrote:
On Don, 2011-09-15 at 09:01 -0600, Brian Paul
On Tue, 20 Sep 2011 12:01:56 -0700, Chad Versace c...@chad-versace.us wrote:
The mismatch below caused ActiveProgram to be incorrectly saved/restored:
_meas_meta_begin:
line 465) ActiveShader := gl_shader_state::CurrentFragmentProgram
_mesa_meta_end:
line 741)
This hasn't been true since dd26899ca39111e0866afed9df94bfb1618dd363
in 2009.
---
src/mesa/drivers/dri/intel/intel_buffer_objects.h |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffer_objects.h
This came up in a chat with Chad a while back. I was in the area
because I'm planning out how to use the MapTextureImage changes to gut
even more of our texture code.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
This also improves the debugging output in the failure paths so you
get more than just failed, and don't get spammed with failed when
you didn't even have a PBO to try.
---
src/mesa/drivers/dri/intel/intel_tex_image.c | 54 +++---
1 files changed, 31 insertions(+), 23
The core code does this before calling in to us.
---
src/mesa/drivers/dri/intel/intel_tex_image.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image.c
index fd719e4..16a0a24 100644
---
There were notes about the possibility of slowdowns due to zcopy from
a PBO due to thrashing around of the region. Slowdowns are even more
likely now that textures are generally tiled, which a zcopy wouldn't
get. Additionally, there were no checks on the buffer size to ensure
that the
Since the blit gets sequenced after other batchbuffer rendering like
normal, there's no need to push things out early.
---
src/mesa/drivers/dri/intel/intel_tex_image.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
---
src/mesa/drivers/dri/intel/intel_tex_image.c | 30 +++--
1 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image.c
index ac3489b..5cfd3a7 100644
---
All that matters here is the format of the texture, not the
internalformat (which might mean various different pixel formats). In
one case, the pbo upload for MESA_FORMAT_YCBCR would have swapped the
channels for MESA_FORMAT_YCBCR_REV.
---
src/mesa/drivers/dri/intel/intel_tex_image.c | 38
On Tue, 20 Sep 2011 18:28:15 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
All this does is generate a bogus value with error type; the fact that
it was in ir_call was rather arbitrary to begin with. ir_constant is an
equally arbitrary place. The rationale is that a future commit will
I'm suprised that fragile code lasted as long as it did...
Looks good to me.
Keith
On Wed, 2011-09-21 at 10:15 -0700, Eric Anholt wrote:
There were notes about the possibility of slowdowns due to zcopy from
a PBO due to thrashing around of the region. Slowdowns are even more
likely now that
On Tue, 20 Sep 2011 18:28:17 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
This begins the process of cleaning up and un-muddling our IR.
Aside from ir_call, our IR is cleanly split into two classes:
- Statements (typeless; used for side effects, control flow)
- Values (deeply
On Mon, 19 Sep 2011 13:40:47 -0700, Paul Berry stereotype...@gmail.com wrote:
Non-text part: multipart/alternative
On 19 September 2011 11:10, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/15/2011 04:40 PM, Paul Berry wrote:
In i965
On 09/21/2011 10:15 AM, Eric Anholt wrote:
Since the blit gets sequenced after other batchbuffer rendering like
normal, there's no need to push things out early.
---
src/mesa/drivers/dri/intel/intel_tex_image.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git
On 09/21/2011 10:15 AM, Eric Anholt wrote:
This came up in a chat with Chad a while back. I was in the area
because I'm planning out how to use the MapTextureImage changes to gut
even more of our texture code.
For the series, except for patches 2 and 6:
Reviewed-by: Kenneth Graunke
On 20 September 2011 18:28, Kenneth Graunke kenn...@whitecape.org wrote:
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index d6594cd..70d0ae2 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -725,6 +725,15 @@ ir_constant::zero(void *mem_ctx, const glsl_type
*type)
return c;
}
On 09/21/2011 10:21 AM, Eric Anholt wrote:
On Tue, 20 Sep 2011 18:28:15 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
All this does is generate a bogus value with error type; the fact that
it was in ir_call was rather arbitrary to begin with. ir_constant is an
equally arbitrary place.
On 21 September 2011 10:21, Eric Anholt e...@anholt.net wrote:
On Tue, 20 Sep 2011 18:28:15 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
All this does is generate a bogus value with error type; the fact that
it was in ir_call was rather arbitrary to begin with. ir_constant is an
On 09/21/2011 11:48 AM, Paul Berry wrote:
On 20 September 2011 18:28, Kenneth Graunke wrote:
@@ -1446,16 +1455,6 @@ ir_function::has_user_signature()
return false;
}
-
-ir_call *
-ir_call::get_error_instruction(void *ctx)
-{
- ir_call *call =
On Wed, 21 Sep 2011 11:22:25 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
On 09/21/2011 10:15 AM, Eric Anholt wrote:
Since the blit gets sequenced after other batchbuffer rendering like
normal, there's no need to push things out early.
---
I don't know if many apps use this extension but I doubt that it works
properly in Mesa. We have no piglit or mesa tests for it.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 09/21/2011 02:20 PM, Eric Anholt wrote:
On Wed, 21 Sep 2011 11:22:25 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
On 09/21/2011 10:15 AM, Eric Anholt wrote:
Since the blit gets sequenced after other batchbuffer rendering like
normal, there's no need to push things out early.
---
https://bugs.freedesktop.org/show_bug.cgi?id=40920
--- Comment #3 from Andreas Betz andreas.b...@elektrobit.com 2011-09-21
14:59:51 PDT ---
Created an attachment (id=51472)
-- (https://bugs.freedesktop.org/attachment.cgi?id=51472)
Picture showing the defective pixels
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=40920
--- Comment #4 from Andreas Betz andreas.b...@elektrobit.com 2011-09-21
15:09:33 PDT ---
Created an attachment (id=51473)
-- (https://bugs.freedesktop.org/attachment.cgi?id=51473)
A win32 studio project showing the defective pixels.
This file
https://bugs.freedesktop.org/show_bug.cgi?id=40920
--- Comment #5 from Andreas Betz andreas.b...@elektrobit.com 2011-09-21
15:10:38 PDT ---
Created an attachment (id=51474)
-- (https://bugs.freedesktop.org/attachment.cgi?id=51474)
PART II of A win32 studio project showing the defective pixels.
On Wed, 21 Sep 2011 15:32:52 -0600, Brian Paul bri...@vmware.com wrote:
I don't know if many apps use this extension but I doubt that it works
properly in Mesa. We have no piglit or mesa tests for it.
wined3d is the only potential consumer I've ecountered. I don't think I
have any interest
On 22 September 2011 01:10, Eric Anholt e...@anholt.net wrote:
wined3d is the only potential consumer I've ecountered. I don't think I
Yeah, although I'm not entirely convinced of the usefulness of wined3d
using the extension either. Apple seems to have their fair share of
APPLE_client_storage
On 09/21/2011 01:47 PM, Paul Berry wrote:
On 20 September 2011 18:28, Kenneth Graunke wrote:
[...]
diff --git a/src/glsl/ir_constant_expression.cpp
b/src/glsl/ir_constant_expression.cpp
index 4264847..bc0b589 100644
--- a/src/glsl/ir_constant_expression.cpp
+++
https://bugs.freedesktop.org/show_bug.cgi?id=41023
Alexandre Demers alexandre.f.dem...@gmail.com changed:
What|Removed |Added
Summary|[bisected] d3d1x: error |[PATCH]
From: Brian Paul bri...@vmware.com
It's only used by swrast.
---
src/mesa/main/mtypes.h|1 -
src/mesa/main/teximage.c |7 ---
src/mesa/swrast/s_context.h |3 ++-
src/mesa/swrast/s_texfilter.c | 27 ++-
src/mesa/swrast/s_texture.c |8
From: Brian Paul bri...@vmware.com
These fields were only used for swrast so move them into
swrast_texture_image.
---
src/mesa/main/mtypes.h|3 ---
src/mesa/main/teximage.c | 13 -
src/mesa/swrast/s_context.h |2 +-
src/mesa/swrast/s_fragprog.c |6 --
From: Brian Paul bri...@vmware.com
AFAIK, there are few users of this extension and I can see a couple
reasons why this is probably broken in Mesa anyway.
---
docs/relnotes-7.12.html |1 +
src/mesa/drivers/dri/intel/intel_extensions.c |1 -
src/mesa/main/attrib.c
On 09/15/2011 04:40 PM, Paul Berry wrote:
In i965 GEN6+ (and I suspect most other hardware), gl_ClipDistance
needs to be laid out as a pair of vec4's (the first containing clip
distances 0-3, and the second containing clip distances 4-7).
However, it is declared in GLSL as an array of 8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/20/2011 06:28 PM, Kenneth Graunke wrote:
| All this does is generate a bogus value with error type; the fact
| that it was in ir_call was rather arbitrary to begin with.
| ir_constant is an equally arbitrary place. The rationale is that a
|
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/20/2011 06:28 PM, Kenneth Graunke wrote:
| This begins the process of cleaning up and un-muddling our IR.
|
| Aside from ir_call, our IR is cleanly split into two classes: -
| Statements (typeless; used for side effects, control flow) - Values
44 matches
Mail list logo
