[Mesa-dev] Trouble opening OSMesa Created Image‏

Hello everyone, I have a question regarding to the OSMesa demo code.I have installed OSMesa and trying to play around with the demo code.I have complied the .c file and an executable file has created.After I ran the executable file, a "Windows cursor (image/x-win-bitmap)" type file was created,

Re: [Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.

On 11 July 2013 16:30, Ian Romanick wrote: > On 07/11/2013 03:52 PM, Paul Berry wrote: > >> On 11 July 2013 14:09, Ian Romanick > > wrote: >> >> I like these changes a lot. I have a few comments below. >> >> >> On 07/08/2013 10:40 AM, Paul Berry wrote: >> >>

Re: [Mesa-dev] [PATCH 14/14] glsl: Add support for C-style initializers.

On Thu, Jul 11, 2013 at 4:10 PM, Ian Romanick wrote: > On 07/03/2013 01:59 PM, Matt Turner wrote: >> >> Required by GL_ARB_shading_language_420pack. >> >> Parts based on work done by Todd Previte and Ken Graunke, implementing >> basic support for C-style initializers of arrays. >> --- >> src/gls

Re: [Mesa-dev] [PATCH] glsl: Don't allow vertex shader input arrays until GLSL 1.50.

On Thu, Jul 11, 2013 at 4:24 PM, Paul Berry wrote: > Vertex shader inputs are not allowed to be arrays until GLSL 1.50. We > were accidentally enabling them for GLSL 1.40 (although we haven't > written any tests for them, so it's not clear whether they actually > work). > > NOTE: although this is

Re: [Mesa-dev] [PATCH 1/3] gallium: add expand_resource interface

On Fri, Jul 12, 2013 at 8:31 AM, Marek Olšák wrote: > Let's ignore the function name for now, that's easy to change and I am > open to suggestions. flush_window_resource, flush_shared_resource, and > sync_shared_resource are possible candidates as well as > gonna_put_this_resource_on_the_screen_ri

Re: [Mesa-dev] [PATCH] gallium: fixup definitions of the rsq and sqrt

The ARB_vertex_program specification defines RSQ as: tmp = fabs(ScalarLoad(op0)); result.x = ApproxRSQRT(tmp); result.y = ApproxRSQRT(tmp); result.z = ApproxRSQRT(tmp); result.w = ApproxRSQRT(tmp); The mesa_to_tgsi code looks good, but it's very suboptimal. Source op

Re: [Mesa-dev] [PATCH 1/3] gallium: add expand_resource interface

Let's ignore the function name for now, that's easy to change and I am open to suggestions. flush_window_resource, flush_shared_resource, and sync_shared_resource are possible candidates as well as gonna_put_this_resource_on_the_screen_right_away. :) The idea is to expose a function which will ensu

Re: [Mesa-dev] [PATCH 2/3] tgsi: fix-up KILP comments

On 12.07.2013 01:26, Brian Paul wrote: > KILP is really unconditional fragment kill. > > We've had KIL and KILP transposed forever. I'll fix that next. I think the 'P' meant to indicate that the condition, if there is any, would be a predicate register, whereas KIL no-P is supposed to represent t

[Mesa-dev] [PATCH 3/3] tgsi: rename the TGSI fragment kill opcodes

TGSI_OPCODE_KIL and KILP had confusing names. The former was conditional kill (if any src component < 0). The later was unconditional kill. At one time KILP was supposed to work with NV-style condition codes/predicates but we never had that in TGSI. This patch renames both opcodes: TGSI_OPCODE

[Mesa-dev] [PATCH 2/3] tgsi: fix-up KILP comments

KILP is really unconditional fragment kill. We've had KIL and KILP transposed forever. I'll fix that next. --- src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |3 +-- src/gallium/auxiliary/tgsi/tgsi_exec.c |5 ++--- src/gallium/docs/source/tgsi.rst| 10 +---

[Mesa-dev] [PATCH 1/3] tgsi: exec TGSI_OPCODE_SQRT as a scalar instruction, not vector

To align with the docs and the state tracker. --- src/gallium/auxiliary/tgsi/tgsi_exec.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c index e89fb77..eaf 100644 --- a/src/gallium/auxiliary

[Mesa-dev] [PATCH] glsl: Don't allow vertex shader input arrays until GLSL 1.50.

Vertex shader inputs are not allowed to be arrays until GLSL 1.50. We were accidentally enabling them for GLSL 1.40 (although we haven't written any tests for them, so it's not clear whether they actually work). NOTE: although this is a simple bug fix, it probably isn't sensible to cherry-pick it

[Mesa-dev] Fwd: [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.

Eek, my last reply was too big to be accepted by mesa-dev. Let's try snipping that down and sending it again: -- Forwarded message -- From: Paul Berry Date: 11 July 2013 15:52 Subject: Re: [Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication. T

Re: [Mesa-dev] [PATCH 01/14] glsl: Remove unnecessary #include from ast_type.cpp.

I had a few style comments in patch 14. The series is Reviewed-by: Ian Romanick On 06/29/2013 07:43 PM, Matt Turner wrote: --- src/glsl/ast_type.cpp | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/glsl/ast_type.cpp b/src/glsl/ast_type.cpp index 29493e2..be84550 100644 --- a/src/g

Re: [Mesa-dev] [PATCH 12/14] glsl: Add an is_declaration field to ast_struct_specifier.

On 07/11/2013 04:09 PM, Matt Turner wrote: On Thu, Jul 11, 2013 at 3:53 PM, Ian Romanick wrote: On 06/29/2013 07:44 PM, Matt Turner wrote: + bool is_declaration; Does this need to be explicitly initialized to false in the constructor? It's initialized to true in the hunk below, since exc

Re: [Mesa-dev] [PATCH 14/14] glsl: Add support for C-style initializers.

On 07/03/2013 01:59 PM, Matt Turner wrote: Required by GL_ARB_shading_language_420pack. Parts based on work done by Todd Previte and Ken Graunke, implementing basic support for C-style initializers of arrays. --- src/glsl/ast.h | 5 ++ src/glsl/ast_to_hir.cpp | 14

Re: [Mesa-dev] [PATCH 12/14] glsl: Add an is_declaration field to ast_struct_specifier.

On Thu, Jul 11, 2013 at 3:53 PM, Ian Romanick wrote: > On 06/29/2013 07:44 PM, Matt Turner wrote: >> + bool is_declaration; > > Does this need to be explicitly initialized to false in the constructor? It's initialized to true in the hunk below, since except for later uses in this series all ast

Re: [Mesa-dev] [PATCH] gallium: fixup definitions of the rsq and sqrt

Am 11.07.2013 21:44, schrieb Zack Rusin: > GLSL spec says that rsq is undefined for src<=0, but the D3D10 > spec says it needs to be a NaN, so lets stop taking an absolute > value of the source which completely breaks that behavior. For > the gl program we can simply insert an extra abs instrunctio

[Mesa-dev] [PATCH] gallivm: handle srgb-to-linear and linear-to-srgb conversions

From: Roland Scheidegger srgb-to-linear is using 3rd degree polynomial for now which should be _just_ good enough. Reverse is using some rational polynomials and is quite accurate, though not hooked into llvmpipe's blend code yet and hence unused (untested). Using a table might also be an option

Re: [Mesa-dev] [PATCH 12/14] glsl: Add an is_declaration field to ast_struct_specifier.

On 06/29/2013 07:44 PM, Matt Turner wrote: Will be used in a later commit to differentiate between a structure type declaration and a variable declaration of a struct type. I.e., the difference between struct S { float x; }; (is_declaration = true) and S s; (is_declar

Re: [Mesa-dev] [PATCH] gallium: fixup definitions of the rsq and sqrt

On 07/11/2013 01:44 PM, Zack Rusin wrote: GLSL spec says that rsq is undefined for src<=0, but the D3D10 spec says it needs to be a NaN, so lets stop taking an absolute value of the source which completely breaks that behavior. For the gl program we can simply insert an extra abs instrunction whi

Re: [Mesa-dev] [PATCH 2/2] gallivm: handle srgb-to-linear and linear-to-srgb conversions

Am 11.07.2013 19:41, schrieb Jose Fonseca: >>> Please use lp_build_polynomial. It tries to avoid data dependency. >>> Furthermore, if we start using FMA, then it's less one place to update. >> Ok. Are you sure it's worth avoiding data dependency at the cost of extra >> instructions (the way I built

Re: [Mesa-dev] [PATCH] glsl: Remove outdated FINISHME comment.

On 07/11/2013 11:41 AM, Matt Turner wrote: Explicit index support was added by commit 1256a5dc. Lol. Reviewed-by: Ian Romanick --- src/glsl/glsl_parser.yy | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index c8c660f..f0b6357 100644

[Mesa-dev] [Bug 66775] Chromium compilation broken: "no member named 'b_GL_ARB_sync'"

https://bugs.freedesktop.org/show_bug.cgi?id=66775 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Mesa-dev] [Bug 66833] Text rendering problems on Dota 2, all mesa drivers

https://bugs.freedesktop.org/show_bug.cgi?id=66833 Ian Romanick changed: What|Removed |Added CC||cwo...@cworth.org, |

Re: [Mesa-dev] [PATCH] glsl: Mark "row_major" as not a reserved word in GLSL ES 3.0.

On 07/11/2013 10:13 AM, Matt Turner wrote: We mark ARB_uniform_buffer_object as enabled under ES 3 since it contains that functionality, which tricked the compiler into tokenizing "row_major". I believe this is a candidate for stable. You should mail it to mesa-stable after it lands. It will

Re: [Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.

I like these changes a lot. I have a few comments below. On 07/08/2013 10:40 AM, Paul Berry wrote: Previously, we had a separate function for setting up the built-in variables for each combination of shader stage and GLSL version (e.g. generate_110_vs_variables to generate the built-in variable

Re: [Mesa-dev] [PATCH RFC 2/3] glsl: Make gl_TexCoord compatibility-only

On 07/08/2013 10:40 AM, Paul Berry wrote: gl_TexCoord was deprecated in GLSL 1.30. In GLSL 1.40 it was marked as ARB_compatibility-only, and in GLSL 1.50 and above it was marked as only appearing in the compatibility profile. It has never appeared in GLSL ES. However, Mesa erroneously included

Re: [Mesa-dev] [PATCH RFC 1/3] glsl ES: Fix magnitude of gl_MaxVertexUniformVectors.

On 07/08/2013 10:40 AM, Paul Berry wrote: Previously, we set it equal to MaxVertexUniformComponents. It should be MaxVertexUniformComponents / 4. NOTE: This is a candidate for the stable branches. Cc: mesa-sta...@lists.freedesktop.org Reviewed-by: Ian Romanick --- src/glsl/builtin_varia

Re: [Mesa-dev] [PATCH 1/3] gallium: add expand_resource interface

Am 11.07.2013 20:15, schrieb Marek Olšák: > Hi Roland, > > The fast color clear on Radeon doesn't touch the memory of the texture > resource. Instead, it changes some GPU meta data that say the resource > is cleared (the location of the meta data is stored in pipe_resource). > This works fine as l

Re: [Mesa-dev] [PATCH 07/12] r600g: don't call buffer_wait in buffer_mmap_sync_with_rings

On 07/01/2013 05:53 AM, Marek Olšák wrote: The winsys should do this, because it measures how much time we spend in buffer_map doing synchronization, which can be viewed with the gallium HUD. --- src/gallium/drivers/r600/r600_pipe.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff

[Mesa-dev] [Bug 66833] Text rendering problems on Dota 2, all mesa drivers

https://bugs.freedesktop.org/show_bug.cgi?id=66833 --- Comment #2 from Vedran Rodic --- Proprietary nVidia drivers (ver 319, 325) don't show the same issues. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailin

[Mesa-dev] [Bug 66833] Text rendering problems on Dota 2, all mesa drivers

https://bugs.freedesktop.org/show_bug.cgi?id=66833 --- Comment #1 from Vedran Rodic --- Recording a trace is not possible, Dota 2 segfaults when run with apitrace. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev

[Mesa-dev] [Bug 66833] New: Text rendering problems on Dota 2, all mesa drivers

https://bugs.freedesktop.org/show_bug.cgi?id=66833 Priority: medium Bug ID: 66833 Assignee: mesa-dev@lists.freedesktop.org Summary: Text rendering problems on Dota 2, all mesa drivers Severity: normal Classification: Unclassified

[Mesa-dev] [PATCH] gallium: fixup definitions of the rsq and sqrt

GLSL spec says that rsq is undefined for src<=0, but the D3D10 spec says it needs to be a NaN, so lets stop taking an absolute value of the source which completely breaks that behavior. For the gl program we can simply insert an extra abs instrunction which produces the desired behavior there. Sig

[Mesa-dev] [Bug 66775] Chromium compilation broken: "no member named 'b_GL_ARB_sync'"

https://bugs.freedesktop.org/show_bug.cgi?id=66775 Andreas Reis changed: What|Removed |Added Assignee|i...@freedesktop.org |mesa-dev@lists.freedesktop.

[Mesa-dev] [Bug 62647] Wrong rendering of Dota 2 on Wine (apitrace attached) - Intel IVB HD4000

https://bugs.freedesktop.org/show_bug.cgi?id=62647 --- Comment #31 from Chris Forbes --- Can we have a new bug for issues in the native client? -- You are receiving this mail because: You are on the CC list for the bug. ___ mesa-dev mailing list mesa-

Re: [Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.

On Mon, Jul 8, 2013 at 10:40 AM, Paul Berry wrote: > + const glsl_type *typ(const char *name) This must not be a typo, since it's consistent. The series is Reviewed-by: Matt Turner with the caveat that the third patch is hard to review and I could easily have missed something, since it's nea

[Mesa-dev] [Bug 62647] Wrong rendering of Dota 2 on Wine (apitrace attached) - Intel IVB HD4000

https://bugs.freedesktop.org/show_bug.cgi?id=62647 --- Comment #30 from Vedran Rodic --- Some interesting bugs on Mesa/Intel, and afaik on all Mesa using machines clients: https://github.com/ValveSoftware/Dota-2/issues/38 On Thu, Jul 11, 2013 at 8:25 PM, wrote: > Comment # 29 on bug 62647 from

[Mesa-dev] [PATCH] glsl: Remove outdated FINISHME comment.

Explicit index support was added by commit 1256a5dc. --- src/glsl/glsl_parser.yy | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index c8c660f..f0b6357 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -1211,9 +1211,6 @@ l

Re: [Mesa-dev] [PATCH] glsl: Add comment explaining "row_major" parsing.

On 07/11/2013 11:29 AM, Matt Turner wrote: --- src/glsl/glsl_parser.yy | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index f0b6357..c079cdd 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -1189,6 +1189,12 @@ la

Re: [Mesa-dev] [PATCH 1/3] gallium: add expand_resource interface

On 11.07.2013 20:15, Marek Olšák wrote: > Hi Roland, > > The fast color clear on Radeon doesn't touch the memory of the texture > resource. Instead, it changes some GPU meta data that say the resource > is cleared (the location of the meta data is stored in pipe_resource). > This works fine as long

[Mesa-dev] [PATCH] glsl: Add comment explaining "row_major" parsing.

--- src/glsl/glsl_parser.yy | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index f0b6357..c079cdd 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -1189,6 +1189,12 @@ layout_qualifier_id: $$.flags.q.

[Mesa-dev] [Bug 62647] Wrong rendering of Dota 2 on Wine (apitrace attached) - Intel IVB HD4000

https://bugs.freedesktop.org/show_bug.cgi?id=62647 --- Comment #29 from Kenneth Graunke --- Also, the native Linux client is now available on Steam (admittedly in beta testing), so you may want to try that. -- You are receiving this mail because: You are on the CC list for the bug.

Re: [Mesa-dev] [PATCH] glsl: Mark "row_major" as not a reserved word in GLSL ES 3.0.

On 07/11/2013 10:57 AM, Anuj Phogat wrote: On Thu, Jul 11, 2013 at 10:13 AM, Matt Turner wrote: We mark ARB_uniform_buffer_object as enabled under ES 3 since it contains that functionality, which tricked the compiler into tokenizing "row_major". --- src/glsl/glsl_lexer.ll | 4 ++-- 1 file ch

Re: [Mesa-dev] [PATCH 1/3] gallium: add expand_resource interface

Hi Roland, The fast color clear on Radeon doesn't touch the memory of the texture resource. Instead, it changes some GPU meta data that say the resource is cleared (the location of the meta data is stored in pipe_resource). This works fine as long as the gallium pipe_resource structure is used for

Re: [Mesa-dev] [PATCH] glsl: Mark "row_major" as not a reserved word in GLSL ES 3.0.

On Thu, Jul 11, 2013 at 10:13 AM, Matt Turner wrote: > We mark ARB_uniform_buffer_object as enabled under ES 3 since it > contains that functionality, which tricked the compiler into tokenizing > "row_major". > --- > src/glsl/glsl_lexer.ll | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(

Re: [Mesa-dev] [PATCH 2/2] gallivm: handle srgb-to-linear and linear-to-srgb conversions

- Original Message - > Am 11.07.2013 18:54, schrieb Jose Fonseca: > > - Original Message - > >> From: Roland Scheidegger > >> > >> srgb-to-linear is using 3rd degree polynomial for now which should be > >> _just_ > >> good enough. Reverse is using some rational polynomials and is

Re: [Mesa-dev] [PATCH 2/2] gallivm: handle srgb-to-linear and linear-to-srgb conversions

Am 11.07.2013 18:54, schrieb Jose Fonseca: > - Original Message - >> From: Roland Scheidegger >> >> srgb-to-linear is using 3rd degree polynomial for now which should be _just_ >> good enough. Reverse is using some rational polynomials and is quite >> accurate, >> though not hooked into ll

[Mesa-dev] [PATCH] glsl: Mark "row_major" as not a reserved word in GLSL ES 3.0.

We mark ARB_uniform_buffer_object as enabled under ES 3 since it contains that functionality, which tricked the compiler into tokenizing "row_major". --- src/glsl/glsl_lexer.ll | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll i

Re: [Mesa-dev] [PATCH 2/2] gallivm: handle srgb-to-linear and linear-to-srgb conversions

- Original Message - > From: Roland Scheidegger > > srgb-to-linear is using 3rd degree polynomial for now which should be _just_ > good enough. Reverse is using some rational polynomials and is quite > accurate, > though not hooked into llvmpipe's blend code yet and hence unused (untested

Re: [Mesa-dev] [PATCH] gallivm: fix rsq behavior

Am 11.07.2013 18:18, schrieb Zack Rusin: > GLSL spec says that rsq is undefined for src<=0, but the D3D10 > spec says it needs to be a NaN, so lets stop taking an absolute > value of the source which completely breaks that behavior. > > Signed-off-by: Zack Rusin > --- > src/gallium/auxiliary/gal

Re: [Mesa-dev] [PATCH 1/2] gallivm: better support for fast rsqrt

Looks good. Thanks for the updates. Jose - Original Message - > From: Roland Scheidegger > > We had to disable fast rsqrt before because it wasn't precise enough etc. > However in situations when we know we're not going to need more precision > we can still use a fast rsqrt (which can b

[Mesa-dev] [PATCH 2/2] gallivm: handle srgb-to-linear and linear-to-srgb conversions

From: Roland Scheidegger srgb-to-linear is using 3rd degree polynomial for now which should be _just_ good enough. Reverse is using some rational polynomials and is quite accurate, though not hooked into llvmpipe's blend code yet and hence unused (untested). Using a table might also be an option

[Mesa-dev] [PATCH 1/2] gallivm: better support for fast rsqrt

From: Roland Scheidegger We had to disable fast rsqrt before because it wasn't precise enough etc. However in situations when we know we're not going to need more precision we can still use a fast rsqrt (which can be several times faster than the quite expensive sqrt). Hence introduce a new helpe

[Mesa-dev] [PATCH] gallivm: fix rsq behavior

GLSL spec says that rsq is undefined for src<=0, but the D3D10 spec says it needs to be a NaN, so lets stop taking an absolute value of the source which completely breaks that behavior. Signed-off-by: Zack Rusin --- src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c |2 -- 1 file changed, 2

Re: [Mesa-dev] [PATCH 2/2] gallivm: handle srgb-to-linear and linear-to-srgb conversions

- Original Message - > Am 11.07.2013 15:50, schrieb Jose Fonseca: > > > > > > - Original Message - > >> From: Roland Scheidegger > >> > >> srgb-to-linear is using 3rd degree polynomial for now which should be > >> _just_ > >> good enough. Reverse is using some rational polynomial

Re: [Mesa-dev] [PATCH 2/2] gallivm: handle srgb-to-linear and linear-to-srgb conversions

Am 11.07.2013 15:50, schrieb Jose Fonseca: > > > - Original Message - >> From: Roland Scheidegger >> >> srgb-to-linear is using 3rd degree polynomial for now which should be _just_ >> good enough. Reverse is using some rational polynomials and is quite >> accurate, >> though not hooked i

[Mesa-dev] [Bug 66809] Compiz segfault with latest mesa-git

https://bugs.freedesktop.org/show_bug.cgi?id=66809 --- Comment #4 from Eric <3rik...@gmail.com> --- Hi, Hope you'll find what you need. If it's not good, please tell me. The program is not being run. Undefined command: "". Try "help". Temporary breakpoint 1 at 0x40c160 Starting program: /usr/bi

Re: [Mesa-dev] [PATCH 1/2] gallivm: better support for fast rsqrt

Am 11.07.2013 16:13, schrieb Brian Paul: > Just minor things below. Ok, I'll fix this (and the things Jose mentioned). > > Reviewed-by: Brian Paul > > On 07/10/2013 06:21 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> We had to disable fast rsqrt before because it wasn't preci

Re: [Mesa-dev] [PATCH 1/2] gallivm: better support for fast rsqrt

Just minor things below. Reviewed-by: Brian Paul On 07/10/2013 06:21 PM, srol...@vmware.com wrote: From: Roland Scheidegger We had to disable fast rsqrt before because it wasn't precise enough etc. However in situations when we know we're not going to need more precision we can still use a f

Re: [Mesa-dev] [PATCH 2/2] gallivm: handle srgb-to-linear and linear-to-srgb conversions

- Original Message - > From: Roland Scheidegger > > srgb-to-linear is using 3rd degree polynomial for now which should be _just_ > good enough. Reverse is using some rational polynomials and is quite > accurate, > though not hooked into llvmpipe's blend code yet and hence unused (untest

[Mesa-dev] [Bug 66806] [softpipe] glxgears floating point exception

https://bugs.freedesktop.org/show_bug.cgi?id=66806 --- Comment #3 from Roland Scheidegger --- (In reply to comment #2) > Indeed > http://software.intel.com/en-us/articles/x87-and-sse-floating-point-assists- > in-ia-32-flush-to-zero-ftz-and-denormals-are-zero-daz > > suggests to mask certain exc

Re: [Mesa-dev] [PATCH 05/13] i965: Delete "the data cache is the sampler cache" comments on Gen7+.

On Wed, Jul 10, 2013 at 04:27:59PM -0700, Kenneth Graunke wrote: > I cut and pasted these comments from the Gen4 code during Ivybridge > enabling, and didn't understand what they meant at the time. > > The data cache is NOT the same as the sampler cache on Ivybridge. > The sampler cache has L1 and

[Mesa-dev] [Bug 66809] Compiz segfault with latest mesa-git

https://bugs.freedesktop.org/show_bug.cgi?id=66809 --- Comment #3 from Eric <3rik...@gmail.com> --- I've bisected on the computer which has a GTX 680. The first bad commit is just the same. Thank you for help, I do this as soon as I can. Best regards, Eric -- You are receiving this mail beca

[Mesa-dev] [Bug 66809] Compiz segfault with latest mesa-git

https://bugs.freedesktop.org/show_bug.cgi?id=66809 --- Comment #2 from Marek Olšák --- I need a backtrace. 1) Open a terminal window under X. 2) Type "screen", you'll get a new shell not connected to your X session. 3) Type "gdb --args compiz --replace ccp" 4) In gdb, type "start" and if it stop

Re: [Mesa-dev] [PATCH 3/4] mesa: Track the TexImage being rendered to in the gl_renderbuffer.

On Thu, Jul 11, 2013 at 8:44 PM, Dave Airlie wrote: > On Thu, Jul 11, 2013 at 11:31 AM, Stéphane Marchesin > wrote: >> On Wed, Jul 10, 2013 at 6:27 PM, Dave Airlie wrote: >>> On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin >>> wrote: On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke

Re: [Mesa-dev] [PATCH 3/4] mesa: Track the TexImage being rendered to in the gl_renderbuffer.

On Thu, Jul 11, 2013 at 11:31 AM, Stéphane Marchesin wrote: > On Wed, Jul 10, 2013 at 6:27 PM, Dave Airlie wrote: >> On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin >> wrote: >>> On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke >>> wrote: On 07/09/2013 04:33 PM, Stéphane Marchesin wr

Re: [Mesa-dev] [PATCH] st/xvmc/tests: avoid non portable error.h functions

Am 11.07.2013 05:04, schrieb Jonathan Gray: On Wed, Jun 26, 2013 at 09:13:13AM +0200, Christian König wrote: Am 26.06.2013 09:10, schrieb Jonathan Gray: Signed-off-by: Jonathan Gray Looks good on first glance, patch is: Reviewed-by: Christian König Can you push it to the repo then? Pushe

[Mesa-dev] [Bug 66809] Compiz segfault with latest mesa-git

https://bugs.freedesktop.org/show_bug.cgi?id=66809 --- Comment #1 from Eric <3rik...@gmail.com> --- Just tried on my other computer (GTX 680). The same issue happens. I'll bisect. Eric -- You are receiving this mail because: You are the assignee for the bug. __

[Mesa-dev] [Bug 66806] [softpipe] glxgears floating point exception

https://bugs.freedesktop.org/show_bug.cgi?id=66806 --- Comment #2 from José Fonseca --- Indeed http://software.intel.com/en-us/articles/x87-and-sse-floating-point-assists-in-ia-32-flush-to-zero-ftz-and-denormals-are-zero-daz suggests to mask certain exceptions together with the FTZ/DAZ bits: