Starting KDE on i965 makes the X server die in a fire with the following
assertion:
X: intel_fbo.c:94: intel_delete_renderbuffer: Assertion `irb' failed.
Obviously, this is rather unpleasant. Bisecting revealed that:
006918c0db77e945ac56b15bc64eba502b86d56c is the first bad commit
commit
Both patches look good to me
Reviewed-by: Jose Fonseca jfons...@vmware.com
- Original Message -
From: Dave Airlie airl...@redhat.com
Noticed would fail, we were doing two things wrong
a) 1d arrays require the layers in height
b) minifying the layers field.
Signed-off-by: Dave
Reviewed-by: Jose Fonseca jfons...@vmware.com
Series looks excellent Brian. Thanks for nailing this issue. I never stop to be
amazed on how state derivation bugs go unnoticed for so long, just because most
apps ends up touch a lot of state at the same time. One could try to write
piglit tests
https://bugs.freedesktop.org/show_bug.cgi?id=57969
José Fonseca jfons...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
From: José Fonseca jose.r.fons...@gmail.com
---
src/gallium/drivers/softpipe/sp_query.c |8
src/gallium/drivers/softpipe/sp_screen.c |2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_query.c
https://bugs.freedesktop.org/show_bug.cgi?id=58012
Priority: medium
Bug ID: 58012
Assignee: mesa-dev@lists.freedesktop.org
Summary: Regression: Half Life 2 random crashes since 56e95d3c
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=58012
--- Comment #1 from Stefan Dösinger stefandoesin...@gmx.at ---
Another note: My other benchmark programs seem to run fine. Those include
3DMark2000, 3DMark2001, Unigine Heaven(gl mode, inside wine), Trackmania
Nations, World in Conflict and some
https://bugs.freedesktop.org/show_bug.cgi?id=58012
--- Comment #2 from Henri Verbeet hverb...@gmail.com ---
(In reply to comment #0)
Thanks to Steam's crash handler it is tricky to get a backtrace.
This is perhaps slightly OT here, but note that you can disable the steam crash
handler by passing
On 12/08/2012 03:48 AM, Jose Fonseca wrote:
Reviewed-by: Jose Fonsecajfons...@vmware.com
Series looks excellent Brian. Thanks for nailing this issue. I never stop to be
amazed on how state derivation bugs go unnoticed for so long, just because most
apps ends up touch a lot of state at the
On 12/08/2012 01:10 AM, Kenneth Graunke wrote:
Starting KDE on i965 makes the X server die in a fire with the following
assertion:
X: intel_fbo.c:94: intel_delete_renderbuffer: Assertion `irb' failed.
Obviously, this is rather unpleasant. Bisecting revealed that:
On 12/07/2012 05:34 PM, Matt Turner wrote:
The GL 3.1 and ES 3.0 specs say of glGetActiveUniformsiv:
If an error occurs, nothing will be written to params.
So, make a pass through the indices and check that they're valid before
the pass that actually writes to params. Checking pname happens
On 6 December 2012 21:34, Tom Stellard t...@stellard.net wrote:
I asked idr about this on IRC and he said that IEEE rules are required for
GLSL = 1.30 and they are compliant, but not required for GLSL 1.30.
stringfellow added that the d3d9 spec required 0*anything = 0, which is
probably why
It doesn't work and it's not clear how it's supposed to work.
---
src/mesa/state_tracker/st_atom_rasterizer.c |3 +--
src/mesa/state_tracker/st_context.c | 17 -
src/mesa/state_tracker/st_context.h |4
src/mesa/state_tracker/st_manager.c |
---
src/gallium/auxiliary/cso_cache/cso_context.c | 26 +
src/gallium/auxiliary/cso_cache/cso_context.h |5 +
src/gallium/auxiliary/postprocess/pp_run.c|3 +++
src/gallium/auxiliary/util/u_blit.c |3 +++
---
src/gallium/auxiliary/cso_cache/cso_context.c | 37 -
src/gallium/auxiliary/cso_cache/cso_context.h | 28 ---
2 files changed, 24 insertions(+), 41 deletions(-)
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c
---
src/gallium/auxiliary/util/u_blitter.c | 146 -
src/gallium/auxiliary/util/u_blitter.h | 11 ---
src/gallium/auxiliary/util/u_surface.c | 160
src/gallium/auxiliary/util/u_surface.h |4 +
There are only 2 possible usages: render target and depth stencil.
Both can be derived from the surface format, so the flag is redundant.
And it's going away...
---
src/gallium/drivers/svga/svga_surface.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git
Not really used by anybody.
---
src/gallium/auxiliary/postprocess/pp_init.c |4 ++--
src/gallium/auxiliary/postprocess/pp_program.c|1 -
src/gallium/auxiliary/postprocess/pp_run.c|1 -
src/gallium/auxiliary/util/u_blitter.c
On Sat, Dec 8, 2012 at 8:55 AM, Henri Verbeet hverb...@gmail.com wrote:
On 6 December 2012 21:34, Tom Stellard t...@stellard.net wrote:
I asked idr about this on IRC and he said that IEEE rules are required for
GLSL = 1.30 and they are compliant, but not required for GLSL 1.30.
stringfellow
On 8 December 2012 16:01, Alex Deucher alexdeuc...@gmail.com wrote:
What about a mesa specific extension? Most people will be using wine
on Linux anyway.
Sure, that works for us. Assuming Mesa is interested in a such an
extension, of course.
___
---
.../AMDGPU/MCTargetDesc/R600MCCodeEmitter.cpp | 4 +-
lib/Target/AMDGPU/R600ISelLowering.cpp | 6 +-
lib/Target/AMDGPU/R600Instructions.td | 99 --
3 files changed, 60 insertions(+), 49 deletions(-)
diff --git
---
lib/Target/AMDGPU/R600ISelLowering.cpp | 91 --
lib/Target/AMDGPU/R600Instructions.td | 9 ++--
2 files changed, 58 insertions(+), 42 deletions(-)
diff --git a/lib/Target/AMDGPU/R600ISelLowering.cpp
b/lib/Target/AMDGPU/R600ISelLowering.cpp
index
---
.../AMDGPU/MCTargetDesc/R600MCCodeEmitter.cpp | 2 +
lib/Target/AMDGPU/R600ISelLowering.cpp | 31 +++
lib/Target/AMDGPU/R600Instructions.td | 65 ++
lib/Target/AMDGPU/R600Intrinsics.td| 2 +
Reviewed-By: Vincent Lejeune vljn at ovi.com
Le jeudi 06 décembre 2012 à 14:09 -0800, Tom Stellard a écrit :
From: Tom Stellard thomas.stell...@amd.com
---
lib/Target/AMDGPU/AMDGPUISelLowering.cpp | 1 +
lib/Target/AMDGPU/AMDGPUISelLowering.h | 1 +
https://bugs.freedesktop.org/show_bug.cgi?id=58012
Jordan Justen jljus...@gmail.com changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |jljus...@gmail.com
From: Kenneth Graunke kenn...@whitecape.org
The GLSL 1.40 spec says:
Uniform block names and variable names declared within uniform
blocks are scoped at the program level.
Track the block name in the symbol table and emit errors when conflicts
exist.
Fixes es3conform's
The set_entry pointer can become invalid if the set table
is re-hashed.
This likely will fix
https://bugs.freedesktop.org/show_bug.cgi?id=58012
(Regression since 56e95d3c)
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Stefan Dösinger stefandoesin...@gmx.at
Cc: Matt Turner
I sent an earlier proof-of-concept patch for adding support to #line for a
filename as a string, (rather than just a numeric source number).
Here in version 2, is a much more complete series, with the following changes:
1. The first patch in the series updates the previously-sent patch to
Such as:
#line 23 foo.c
Having a filename here is quite useful and many other OpenGL implementations
allow this.
Note that for GLES we take the hard line and insist on a numeric source string
number as per the specification and which glcpp has always supported:
#line 23 3
---
For which we just added support to the preprocessor.
---
src/glsl/glcpp/tests/117-hash-line-with-filename.c |3 +++
src/glsl/glcpp/tests/117-hash-line-with-filename.c.expected |5 +
2 files changed, 8 insertions(+)
create mode 100644
The {HASH} alias is identical to the open-coded regular expressions being
replaced here, so no behavioral change, (just easier-to-read code).
---
src/glsl/glsl_lexer.ll |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll
Verifing that both the source number and line number get correctly reflected
into error messages.
Note that this is distinct from existing testing of the proeprocessor,
(in glcpp/tests), since here we are testing that the GLSL compiler
itself is correctly handling those #line directives that are
The #line directive specifies the line number for the subsequent line of text.
So, since we will see another newline before that line, (and hence, increment
yylineno one more time), we have to set the yylineno value to one less than
we would otherwise.
This is in addition to setting it to one
We were going through the work to parse a directive like #line 0 2 and
setting the source to 2. But then, we were re-setting the source to 0
at the beginning of every lex action. Instead, reset it to 0 only once at
the beginning of all lexing.
With this fix, correct source numbers will actually
This one is unavoidable as C is inherently ambiguous, (from the point-of-view
of the parser), in the dangling-else case. Now, C is unambiguous in that the
dangling else should bind to the innermost if. This is exactly what bison
accomplishes by preferring to shift rather than reduce.
The expect
Such as:
#line 23 foo.c
Having a filename here is quite useful and many other OpenGL implementations
allow this.
---
src/glsl/ast.h |2 +-
src/glsl/glsl_lexer.ll | 56 ++-
src/glsl/glsl_parser.yy |2 +-
We have arranged for the lexer function to receive an argument of type
struct _mesa_gls_parse_state* but it comes in as void *yyextra.
By including code immediately after the %% separator, we can declare a local
variable of the correct type and name, (state), to hold this value for use
by all
Verifying that the filename from the #line directive appears in subsequent
error messages.
---
src/glsl/tests/directives/04-hash-line-source-filename.glsl | 11 +++
.../directives/04-hash-line-source-filename.glsl.expected |2 ++
2 files changed, 13 insertions(+)
create mode
---
src/mesa/drivers/dri/intel/intel_extensions.c |5 +
src/mesa/main/bufferobj.c |4 ++--
src/mesa/main/extensions.c|2 +-
src/mesa/main/get.c |9 -
src/mesa/main/teximage.c | 15
Death to driver-specific hacks!
---
src/mesa/drivers/dri/intel/intel_extensions.c |6 +-
src/mesa/main/version.c |6 ++
src/mesa/state_tracker/st_extensions.c|5 +
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git
---
src/gallium/drivers/r300/r300_flush.c |3 +--
src/gallium/drivers/r300/r300_query.c |4 ++--
src/gallium/drivers/r300/r300_screen_buffer.c | 12 ++--
src/gallium/drivers/r300/r300_texture.c |4 ++--
src/gallium/drivers/r600/r600_buffer.c|
On 12/08/2012 02:02 PM, Marek Olšák wrote:
Death to driver-specific hacks!
This looks good to me, but Dave Airlie may have a different opinion. :)
Drivers could enable GLSL 1.40 without 3.1 if they can support the full
ARB_texbo. We didn't enable texbos on compatibility profiles because L,
This patch series removes all the swrast_texture_image references in
the texture (de)compression code.
Instead of exposing a bunch of _mesa_fetch_texel_XXX() functions
there's a new _mesa_get_compressed_fetch_func() function that returns
a texel fetcher given a compressed format. It's called by
Hi Jerome,
I'm okay with the simplification of r600_flush_emit, I'm not so okay
with some other things. There's also some cruft unrelated to flushing.
1) R600_CONTEXT_FLUSH could have a better name, because it's not clear
what it does. (it looks like it only flushed read-only bindings)
2) Don't
On Sat, Dec 8, 2012 at 7:27 PM, Marek Olšák mar...@gmail.com wrote:
Hi Jerome,
I'm okay with the simplification of r600_flush_emit, I'm not so okay
with some other things. There's also some cruft unrelated to flushing.
1) R600_CONTEXT_FLUSH could have a better name, because it's not clear
On 12/08/2012 05:40 AM, Brian Paul wrote:
On 12/08/2012 01:10 AM, Kenneth Graunke wrote:
Starting KDE on i965 makes the X server die in a fire with the following
assertion:
X: intel_fbo.c:94: intel_delete_renderbuffer: Assertion `irb' failed.
Obviously, this is rather unpleasant. Bisecting
On 12/08/2012 12:45 PM, Ian Romanick wrote:
From: Kenneth Graunke kenn...@whitecape.org
The GLSL 1.40 spec says:
Uniform block names and variable names declared within uniform
blocks are scoped at the program level.
Track the block name in the symbol table and emit errors when
47 matches
Mail list logo
