On 21 September 2011 18:44, Ian Romanick wrote:
> -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: -
> | Sta
https://bugs.freedesktop.org/show_bug.cgi?id=41023
Lucas Stach changed:
What|Removed |Added
CC||e0425...@student.tuwien.ac.
-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
|
-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
| futu
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 flo
From: Brian Paul
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
From: Brian Paul
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 --
src/mesa/swrast/
From: Brian Paul
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
src/mesa
https://bugs.freedesktop.org/show_bug.cgi?id=41023
Alexandre Demers changed:
What|Removed |Added
Summary|[bisected] d3d1x: error |[PATCH] d3d1x: error when
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
> +++ b/src
On 22 September 2011 01:10, Eric Anholt 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 related bugs as
On Wed, 21 Sep 2011 15:32:52 -0600, Brian Paul 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 in the extensi
https://bugs.freedesktop.org/show_bug.cgi?id=40920
--- Comment #5 from Andreas Betz 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.
This file contains a win32
https://bugs.freedesktop.org/show_bug.cgi?id=40920
--- Comment #4 from Andreas Betz 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 contains a win32 visual stu
https://bugs.freedesktop.org/show_bug.cgi?id=40920
--- Comment #3 from Andreas Betz 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/u
On 09/21/2011 02:20 PM, Eric Anholt wrote:
> On Wed, 21 Sep 2011 11:22:25 -0700, Kenneth Graunke
> 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.
>>> ---
>>> src/m
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 Wed, 21 Sep 2011 11:22:25 -0700, Kenneth Graunke
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.
> > ---
> > src/mesa/drivers/dri/intel/intel_tex_image.c |3 -
On 20 September 2011 18:28, Kenneth Graunke wrote:
> Here's a few cleanups to our compiler's IR that I've been wanting to do
> for a very long time. With this series, expression trees are finally
> guaranteed to be pure; you can no longer put calls with side effects in
> them. ir_call is now a
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 21 September 2011 10:21, Eric Anholt wrote:
> On Tue, 20 Sep 2011 18:28:15 -0700, 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 ra
On 09/21/2011 10:21 AM, Eric Anholt wrote:
> On Tue, 20 Sep 2011 18:28:15 -0700, 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
On 20 September 2011 18:28, Kenneth Graunke 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;
> }
>
> +ir_constant
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
I don'
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 Mon, 19 Sep 2011 13:40:47 -0700, Paul Berry wrote:
Non-text part: multipart/alternative
> On 19 September 2011 11:10, Ian Romanick wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 09/15/2011 04:40 PM, Paul Berry wrote:
> > > In i965 GEN6+ (and I suspect most other har
On Tue, 20 Sep 2011 18:28:17 -0700, 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 (deeply nestable, pure, typed ex
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 th
On Tue, 20 Sep 2011 18:28:15 -0700, 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 future commit will
> change ir_calls fro
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 +
---
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
--- a/src/mesa/drivers/dri/
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
b/src/mes
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 hardware-re
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
---
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 del
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
http://lists.freedesktop.org/
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
b/src/mesa/drivers/dri/intel/intel
On Tue, 20 Sep 2011 12:01:56 -0700, Chad Versace 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) gl_shader_state::Acti
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 wrote:
Am 21.09.2011 14:24, schrieb Fabio:
>
>
>> Messaggio originale
>> Da: kei...@vmware.com
>> Data: 20/09/2011 16.45
>> A: "Roland Scheidegger"
>> Cc: "Fabio",
>> Ogg: Re: [Mesa-dev] Building with -fno-builtin-memcmp for improved
> performance
>>
>> On Tue, 2011-09-20 at 16:35 +0200, Rolan
>Messaggio originale
>Da: kei...@vmware.com
>Data: 20/09/2011 16.45
>A: "Roland Scheidegger"
>Cc: "Fabio",
>Ogg: Re: [Mesa-dev] Building with -fno-builtin-memcmp for improved
performance
>
>On Tue, 2011-09-20 at 16:35 +0200, Roland Scheidegger wrote:
>> Am 20.09.2011 16:15, schrieb Keit
https://bugs.freedesktop.org/show_bug.cgi?id=41065
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=41074
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=41074
Knut Petersen changed:
What|Removed |Added
CC||knut_peter...@t-online.de
--
Configure
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, M
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 Tue, 20 Sep 2011 08:20:27 -0700
Paul Berry wrote:
> On 20 September 2011 01:05, Tolga Dalman wrote:
> Tolga, your uneasiness is certainly justified in terms of conventional
> wisdom. As someone who used to write numerical analysis software, I cringe
> whenever I see floats compared using ==,
https://bugs.freedesktop.org/show_bug.cgi?id=40920
--- Comment #2 from Andreas Betz 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 slow ...
The point is ... i
48 matches
Mail list logo
