On 06/17/2011 06:46 PM, Eric Anholt wrote:
We're need this workaorund a lot more than we're currently doing, so
let's reuse it.
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c | 29 +--
1 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dr
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36987
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel
Our hardware doesn't have a sample_d_c message, so we have to do a
regular sample_d and emit instructions to manually perform the
comparison.
This requires a state dependent recompile whenever the sampler's compare
mode or function change. This adds the per-sampler comparison functions
to brw_wm_
The next patch will add a few additional uses.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.h |2 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 28 +
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers
This makes it available earlier, which will soon be necessary.
(Separating code motion from actual changes.)
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_emit.cpp|4 ++-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 37 +-
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
b/src/mesa/drivers
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 32 +-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 7255946..638eaa4 10
This is somewhat ugly, but I couldn't think of a nicer way to handle the
interleaved coordinate/derivative parameter loading.
Ironlake and Sandybridge will still hit an assertion in visit().
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_emit.cpp|3 +-
src/mesa/driv
Prior to this patch, it would attempt to optimize and allocate registers
for the program even if it failed to compile. This seems wasteful.
More importantly, the "message length > 11" failure seems to choke the
instruction scheduler, making it somehow use an undefined value and
segmentation fault
Hey!
Version 2 of my GL_ARB_shader_texture_lod patches. Patches 1, 5, and 8
are the same; unfortunately, the rest changed.
I added ten new piglit tests for shadow2DGradARB---essentially, copy and
paste of glsl-fs-shadow2D-0*.shader_test, but using dPdx and dPdy. The
tenth one combines them all
Fixes a 100% reproducible GPU hang in topogun-1.06-orc-84k.trace.
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 23 +++
src/mesa/drivers/dri/intel/intel_batchbuffer.c | 21 -
src/mesa/drivers/dri/intel/intel_batchbuffer.h |1 +
3 files changed
We're about to call this function in a bunch of state emits, so let's
not spam the hardware with flushes too hard.
---
src/mesa/drivers/dri/i965/brw_draw.c |2 ++
src/mesa/drivers/dri/i965/brw_vtbl.c |5 +
src/mesa/drivers/dri/intel/intel_batchbuffer.c |5 +
This was spectacularly unsafe. On my system, address 0 happens to be
the hardware status page for the render ring, and the first quadword
of that happens to contain nothing we ever look at, but I sure didn't
look forward to having to debug some day when, for example, the kernel
happened to bind th
We're need this workaorund a lot more than we're currently doing, so
let's reuse it.
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c | 29 +--
1 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers
There are three changes from the patch set I published on 6/15:
1) Removed IR pointers from AST classes and moved them to glsl_parser_state,
2) Manage the new IR in a stack-like manner to properly handle nesting, and
3) Squash 6/7 and 7/7 together, since both deal with IR generation
#1 was in res
Beware! Here be dragons!
Up until now modyfing the GLSL compiler has been pretty straightforward.
This is where things get interesting.
Switch statement processing leverages infrastructure that was previously
created (specifically for break statements, which are encountered in both
loops and swit
Pretty trivial stuff. Simply print the structure of the ASTs. No magic here.
---
src/glsl/glsl_parser_extras.cpp | 38 --
1 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index a3
We now tie the grammar to the ctors of the ASTs they reference.
This requires that we actually have definitions of the ctors.
In addition, we also need to define "print" and "hir" methods for the AST
classes. At this stage of the development, we simply stub out the "print"
and "hir" methods and f
Previously we added productions for:
switch_body
case_label_list
case_statement
case_statement_list
Now add AST structs corresponding to those productions.
---
src/glsl/ast.h | 49 +
1 files changed, 49 insertions(+)
The grammar is modified to support switch statements. Rather than follow the
grammar in the appendix, which allows case labels to be placed ANYWHERE
as a regular statement, we follow the development of the grammar as
described in the body of the GLSL.
In this variation, the switch statement has a
Data structures for switch statement and case label are created that parallel
the structure of other AST data.
---
src/glsl/ast.h | 24
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 878f48b..39a59d4 100644
--- a/src
This patch set adds support for switch statements to the GLSL compiler. We
modify the grammar for the compiler with productions for switch statements
and case labels, while adding supporting supporting productions not already
present. New AST classes are defined to support those productions. Howev
https://bugs.freedesktop.org/show_bug.cgi?id=9951
Eric Anholt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
2011/6/17 Brian Paul :
> On 06/17/2011 12:34 PM, Stéphane Marchesin wrote:
>>
>> If we can find it, that means we don't need to do texture format
>> conversion
>> and therefore we get fast texture uploads for natively supported formats.
>> ---
>> src/mesa/state_tracker/st_format.c | 25 +
Now all infrastructure is in place to support s8_z24 non-texture
renderbuffers for gen7.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_fbo.c | 84 ++-
1 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel
Hiz buffer allocation can only occur if the 'else' branch has been taken,
so move the hiz buffer allocation into the 'else' branch.
Having the hiz buffer allocation dangling outside of the if-tree was just
damn confusing.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_fbo.c |
Add the following fields:
intel_renderbuffer.wrapped_depth;
intel_renderbuffer.wrapped_stencil
If the intel_context is using separate stencil and the renderbuffer has
a packed depth/stencil format, then wrapped_depth and wrapped_stencil are
the real renderbuffers.
Alter the following func
Commit b5c847c7ca06823af3b72324056a2e478caca70b erroneously disabled
support for S8_Z24 texture format when the context required separate
stencil (intel_context.must_use_separate_stencil).
But the GL spec requires implementations to support GL_DEPTH24_STENCIL8.
So we better find a way to fake it..
This adds all necessary infrastructure to support s8_z24 non-texture
renderbuffers on gen7.
Chad Versace (4):
intel: Unconditionally enable support for S8_Z24 texture format
intel: Add fields to intel_renderbuffer for unwrapping packed depth/stencil
buffers
intel: Unobfuscate intel_alloc_re
On 06/17/2011 02:36 PM, Eric Anholt wrote:
---
tests/all.tests|1 +
.../arb_vertex_buffer_object/CMakeLists.gl.txt |1 +
.../mixed-immediate-and-vbo.c | 108
3 files changed, 110 insertions(+), 0 delet
On 06/17/2011 02:36 PM, Eric Anholt wrote:
In fixed function, stride == 0 (e.g. glColor4f() outside of the draw
call) would get turned into uniform inputs, which is why it was
ignored originally in this test. For shaders, drivers end up seeing a
need to upload stride == 0 data, and get confused
On 06/17/2011 02:36 PM, Eric Anholt wrote:
We would still want to consider that data as being in a VBO even if we
managed to produce this case, which as far as I know we can't.
---
src/mesa/vbo/vbo_rebase.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/mesa/vbo
---
tests/all.tests|1 +
.../arb_vertex_buffer_object/CMakeLists.gl.txt |1 +
.../mixed-immediate-and-vbo.c | 108
3 files changed, 110 insertions(+), 0 deletions(-)
create mode 100644
tests/spec/arb_verte
We would still want to consider that data as being in a VBO even if we
managed to produce this case, which as far as I know we can't.
---
src/mesa/vbo/vbo_rebase.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/mesa/vbo/vbo_rebase.c b/src/mesa/vbo/vbo_rebase.c
index
In fixed function, stride == 0 (e.g. glColor4f() outside of the draw
call) would get turned into uniform inputs, which is why it was
ignored originally in this test. For shaders, drivers end up seeing a
need to upload stride == 0 data, and get confused by needing to upload
when vbo_all_varyings_in
---
tests/all.tests |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/all.tests b/tests/all.tests
index 69c6477..6f0378a 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -873,7 +873,7 @@ add_texwrap_test2(arb_texture_compression, '2D',
'GL_COMPRESSED_RGBA')
a
We want to bind to our context before calling __glXSetCurrentContext or
messing with the gc rect in order to properly handle error conditions.
Signed-off-by: Jeremy Huddleston
---
src/glx/glxcurrent.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff --gi
FramebufferTextureLayer is an alias of FramebufferTextureLayerEXT, so
FramebufferTextureLayerARB needs to be listed as an alias of
FramebufferTextureLayerEXT rather than FramebufferTextureLayer.
Signed-off-by: Jeremy Huddleston
---
src/mapi/glapi/gen/ARB_geometry_shader4.xml |2 +-
1 files
This fixes a regression introduced by 49d7e48b33264d94e30af6129c281b6acafa9427
Signed-off-by: Jeremy Huddleston
---
src/glx/glxcurrent.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git origin/master/src/glx/glxcurrent.c origin/master/src/glx/glxcurrent.c
inde
On Thu, Jun 16, 2011 at 10:14 AM, Jose Fonseca wrote:
>
> Younes,
>
> If the thread you quote had been last word on the subject, then then this
> thread would have never happened:
>
> http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg09601.html
>
> and this conversation would not b
On 06/17/2011 12:34 PM, Stéphane Marchesin wrote:
If we can find it, that means we don't need to do texture format conversion
and therefore we get fast texture uploads for natively supported formats.
---
src/mesa/state_tracker/st_format.c | 25 +
1 files changed, 17 i
Current LIT implementation uses dst components for storing temp
results, possibly overwriting still needed values (depends on the
swizzles).
This patch uses temp reg for one of such cases (found in etqw) and
fixes "LIT R.z, R.xyzz".
Tested on evergreen. Fixes some etqw-demo rendering glitches when
fixes https://bugs.freedesktop.org/show_bug.cgi?id=36917
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_shader.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index b8a86b0
Source box needs to be adjusted for blitting from compressed formats.
fixes https://bugs.freedesktop.org/show_bug.cgi?id=35434
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_blit.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/gallium/d
These bugs were found while testing etqw-demo2 with r600g.
There are no regressions with piglit r600.tests on evergreen,
but 3rd patch is touching common code path for r600-eg,
and I have no r600/700 hw to test, so test results are welcome.
I think r600&r700 are affected by the bug 3 too, and the
If we can find it, that means we don't need to do texture format conversion
and therefore we get fast texture uploads for natively supported formats.
---
src/mesa/state_tracker/st_format.c | 25 +
1 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/src/mesa/st
If you'd check the output of the tar check you'd see files linked to
itself that seems to break it. That wasn't the case in the releases
before. It's all related to r300.
There's probably something wrong with links pointing to the source file.
BTW: I've used the 'zip' source to build our package.
On Thu, Jun 16, 2011 at 2:41 PM, Kenneth Graunke wrote:
> On 06/14/2011 12:22 PM, Chad Versace wrote:
>>
>> On Tue, 14 Jun 2011 13:09:50 +0200, Andreas Radke
>> wrote:
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Can you please confirm the tarballs. gzip and bzip2 tarballs wo
On 6/15/11 6:22 PM, Stéphane Marchesin wrote:
The current dri context unbind logic will leak drawables until the process
dies (they will then get released by the GEM code). There are two ways to fix
this: either always call driReleaseDrawables every time we unbind a context
(but that costs us rou
Hello Stéphane,
I've applied your Patch against git mesa from yesterday.
It also results in the same SEGFAULT running simple from
the gtkglext examples. (see backtrace below, in
st_visual_to_context_mode(..) visual is not initialized properly).
When I try pure mesa git from yesterday, no SEGFAULT
50 matches
Mail list logo
