On 12/08/2012 12:45 PM, Ian Romanick wrote:
From: Kenneth Graunke
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 e
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 re
On Sat, Dec 8, 2012 at 7:27 PM, Marek Olšák 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
> what it doe
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
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 t
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,
---
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| 1
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 a/src/mesa/drivers/
---
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 +
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 10064
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
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 +-
src
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 "expe
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
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 less
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 e
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
inde
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 src/glsl/glcpp/tests/117-hash-line-with-fi
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
---
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
corr
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
Cc: Stefan Dösinger
Cc: Matt Turner
---
src/mesa/main/mtypes.h |1 -
src/mesa/main/sync
From: Kenneth Graunke
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 uniform_buffer_object_block_name_con
https://bugs.freedesktop.org/show_bug.cgi?id=58012
Jordan Justen changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |jljus...@gmail.com
|or
Reviewed-By: Vincent Lejeune
Le jeudi 06 décembre 2012 à 14:09 -0800, Tom Stellard a écrit :
> From: Tom Stellard
>
> ---
> lib/Target/AMDGPU/AMDGPUISelLowering.cpp | 1 +
> lib/Target/AMDGPU/AMDGPUISelLowering.h | 1 +
> lib/Target/AMDGPU/AMDGPUInstrInfo.td | 3 +++
> lib/Target/AMDG
---
.../AMDGPU/MCTargetDesc/R600MCCodeEmitter.cpp | 2 +
lib/Target/AMDGPU/R600ISelLowering.cpp | 31 +++
lib/Target/AMDGPU/R600Instructions.td | 65 ++
lib/Target/AMDGPU/R600Intrinsics.td| 2 +
lib/Target/AMDGPU/R600Machi
---
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 7787599..1b6
---
.../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 a/lib/Target/AMDGPU/MCTargetDes
On 8 December 2012 16:01, Alex Deucher 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.
___
mesa-dev mailing list
m
On Sat, Dec 8, 2012 at 8:55 AM, Henri Verbeet wrote:
> On 6 December 2012 21:34, Tom Stellard 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 req
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|
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
---
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 +
src/mesa/state_tracker/st_cb_texture.
---
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
b/src/gallium/auxiliary/cso_
---
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/util/u_gen_mipma
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 |
On 6 December 2012 21:34, Tom Stellard 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 the hardware
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 happen
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:
006918c0db77e945ac56b15bc64eb
On 12/08/2012 03:48 AM, Jose Fonseca wrote:
Reviewed-by: Jose Fonseca
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 tr
https://bugs.freedesktop.org/show_bug.cgi?id=58012
--- Comment #2 from Henri Verbeet ---
(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 "-nobreakpad" to
https://bugs.freedesktop.org/show_bug.cgi?id=58012
--- Comment #1 from Stefan Dösinger ---
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 very simple Direct3D ov
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
From: José Fonseca
---
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
b/src/gallium/drivers/softpipe/sp_query.c
index c173736..2d
https://bugs.freedesktop.org/show_bug.cgi?id=57969
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Reviewed-by: Jose Fonseca
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 that draw something,
Both patches look good to me
Reviewed-by: Jose Fonseca
- Original Message -
> From: Dave Airlie
>
> 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 Airlie
> ---
> src/gallium/
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 006918
47 matches
Mail list logo
