From: Michel Dänzer michel.daen...@amd.com
4 more little piglits.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeonsi/si_state_draw.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git
From: Michel Dänzer michel.daen...@amd.com
17 more little piglits.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_pipe.h | 1 -
src/gallium/drivers/radeonsi/radeonsi_shader.c | 62
From: Michel Dänzer michel.daen...@amd.com
Two more little piglits.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_pipe.h | 1 -
src/gallium/drivers/radeonsi/radeonsi_shader.c | 4 +++-
From: Michel Dänzer michel.daen...@amd.com
Just enough to support an additional internal constant buffer for the user
clip planes.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeonsi/r600_buffer.c | 30 ---
From: Marek Olšák mar...@gmail.com
and add assertions to prevent buffer overflow. This fixes corruption
of the si_shader struct.
NOTE: This is a candidate for the 9.1 branch.
[ Cherry-pick of r600g commit da33f9b919039442e9ab51f9b1d1c83a73607133 ]
Signed-off-by: Michel Dänzer
https://bugs.freedesktop.org/show_bug.cgi?id=64649
--- Comment #4 from bartosz.brzos...@11bitstudios.com ---
The swap control extension is not required by the game to function. The exit
must be caused by something else. What exactly happens? Does it look like
graceful exit or a segfault? What
https://bugs.freedesktop.org/show_bug.cgi?id=64668
--- Comment #13 from edg...@yandex.ru ---
As far as I've been able to tell from experimenting with the nVidia
proprietary driver, its behaviour in this corner case is to not clip at all.
You're absolutely correct, it doesn't clip.
I see that
From: José Fonseca jfons...@vmware.com
- recent gdb handles DWARF fine (tested both with version
7.1.90.20100730 from mingw-w64 project, and 7.5-1 from mingw project)
- http://people.freedesktop.org/~jrfonseca/bfdhelp/ was updated to
handle DWARF
- it requires ugly hacks to prevent
On Mit, 2013-05-15 at 14:26 -0700, Tom Stellard wrote:
The attached patches add some new patterns and instructions for SI and
are a prerequisite for more invasive compute shader changes that I'm
working on.
Please Review.
The SI changes are
Reviewed-by: Michel Dänzer
- Original Message -
Am 16.05.2013 21:44, schrieb Adam Jackson:
These were mostly just a waste of memory and cache pressure, and were
really only used for debugging.
This change reduces instruction count (as measured by callgrind's Ir
event) of gnome-shell-perf-tool on
Vinson,
Why is this necessary?
(I'd prefer that LLVM is statically linked by default. )
Jose
- Original Message -
This patch fixes SCons builds on Fedora 18.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
scons/llvm.py | 10 +-
1 file changed, 9 insertions(+), 1
_mesa_get_attachment_teximage has no side effects so looks good to me.
Jose
- Original Message -
All uses of 'texImage' were removed in commit
77a405dba7f70f8a47655e90774a5ecf5c88a6ed.
Fixes Unused pointer value defect reported by Coverity.
Signed-off-by: Vinson Lee
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Fri, May 17, 2013 at 11:27 AM, Michel Dänzer mic...@daenzer.net wrote:
From: Marek Olšák mar...@gmail.com
and add assertions to prevent buffer overflow. This fixes corruption
of the si_shader struct.
NOTE: This is a candidate for the 9.1
- Original Message -
From: Richard Sandiford r.sandif...@uk.ibm.com
RGBA has R at byte 0 and A at byte 3, regardless of platform
endianness.
Maybe I'm missing something, but this naming convention seems to me the exact
opposite of what was decided [1], which is:
- R at byte 0,
Thanks for doing this Roland.
- Original Message -
From: Roland Scheidegger srol...@vmware.com
We do rendering to linear color buffers for quite some time, and since
switching to linear depth buffers all the tiled/linear logic was unused.
So get rid of (most) of it - there's still
From: José Fonseca jfons...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 20
src/gallium/auxiliary/gallivm/lp_bld_arit.h | 15 ++
src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c | 51 ++---
3 files changed, 60 insertions(+), 26
From: José Fonseca jfons...@vmware.com
This change was meant as a stepping stone to use PMADDUBSW SSSE3
instruction, but actually this refactoring by itself yields a 10%
speedup on texture intensive shaders (e.g, Google Earth's ocean water
w/o S3TC on a Ivy Bridge machine), while giving yielding
Hello!
This patch series bumps the kernel requirement to 3.6 for Gen6+,
meaning that we actually get to rely on hardware context support.
That's a little painful, but even Debian ships 3.8 now, and this
isn't going to make it into an actual release for several more
months.
It then splits our
Kernel 3.3 introduced the SOL reset execbuf parameter, needed for GL 3.0
on Ivybridge. Bumping the requirement will give an obvious error
message rather than simply reporting GL 2.1.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/intel/intel_extensions.c | 5
Hardware contexts are necessary to reasonably support OpenGL 3.2.
In particular, we currently maintain software counters for transform
feedback buffer offsets and counters, which relies on knowing the number
of primitives generated. Geometry shaders violate that assumption.
At the time of
BLORP is used for operations like glClear, glCopyTexImage, and
glBlitFramebuffer which aren't supposed to contribute fragments toward
occlusion queries.
This prevents Piglit tests from breaking in the next commit.
Cc: Eric Anholt e...@anholt.net
Cc: Paul Berry stereotype...@gmail.com
Hardware contexts greatly simplify the query object code. The pipeline
statistics counters get saved and restored with the context, which means
that we don't need to worry about other workloads polluting them.
This means that we can simply write a single pair of values (one at
BeginQuery and one
These come from the Ivybridge PRM, Volume 1, Part 3.
Cc: Eric Anholt e...@anholt.net
Cc: Paul Berry stereotype...@gmail.com
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/intel/intel_reg.h | 13 +
1 file changed, 13 insertions(+)
diff --git
We don't currently use the clipper statistics, but we'll soon use
CL_INVOCATIONS_COUNT to implement the GL_PRIMITIVES_GENERATED query.
The number of primitives generated is not supposed to be altered during
operations such as glGenerateMipmap.
Prevents spec/EXT_transform_feedback/generatemipmap
In order to implement the GL_PRIMITIVES_GENERATED query in a sane
fashion on our hardware, we can't discard primitives until the clipper.
The patch after next explains the rationale.
By setting the clipper to REJECT_ALL mode, all primitives get thrown away,
so rendering is still appropriately
This has more of a negative impact than the previous patch, as on Gen6
passing primitives through to the clipper means we actually have to make
the GS thread write them to the URB.
I don't see another good solution though, and rasterizer discard is not
the most common of cases, so hopefully it
Now that we have hardware contexts and can use MI_STORE_REGISTER_MEM,
we can use the GPU's pipeline statistics counters rather than going out
of our way to count primitives in software.
Aside from being simpler, this also paves the way for Geometry Shaders,
which can output an arbitrary number of
Some Gallium drivers were crashing, because the array was not large enough.
v2: clamp the per-shader maximum in st/mesa, then sum them all up
NOTE: This is a candidate for the stable branches.
---
src/mesa/main/bufferobj.c | 10 ++
src/mesa/main/config.h |
brw_link_shader() unconditionally calls lower_vector_insert() with true
as the second parameter. This means that both constant and variable
indexed expressions will get lowered, so we should never see this in the
backend.
Cc: Ian Romanick i...@freedesktop.org
Cc: Paul Berry
do_vec_index_to_swizzle() should remove any vector extract operations
with a constant index. It's unconditionally called from
do_common_optimization().
do_vec_index_to_cond_assign() should remove the rest, and it is
unconditionally called from brw_link_shader(). This means that we
should never
On Fri, May 17, 2013 at 10:43 AM, Kenneth Graunke kenn...@whitecape.org wrote:
do_vec_index_to_swizzle() should remove any vector extract operations
with a constant index. It's unconditionally called from
do_common_optimization().
do_vec_index_to_cond_assign() should remove the rest, and it
Divick Kishore divick.kish...@gmail.com writes:
By default we sync to vblank, which for you is 60. The software
rasterizer lacks this feature.
I meant that even with h/w rasterizer I get fps = 60 with vblank=0 set.
The weird thing is that he said he ran it with vblank_mode=0. Makes me
On Fri, May 17, 2013 at 7:44 AM, Jose Fonseca jfons...@vmware.com wrote:
Vinson,
Why is this necessary?
(I'd prefer that LLVM is statically linked by default. )
Jose
The SCons build fails on systems that only provide a LLVM shared
library. 'llvm-config --libs' always enumerates the
Kenneth Graunke kenn...@whitecape.org writes:
do_vec_index_to_swizzle() should remove any vector extract operations
with a constant index. It's unconditionally called from
do_common_optimization().
do_vec_index_to_cond_assign() should remove the rest, and it is
unconditionally called from
vblank_mode was broken for a long time in EGL, but current 9.0 and 9.1
have it fixed. Not sure what version you're on.
I am using version 8.0.5. I have been unable to build the 9.1 for
softpipe renderer using the same options that I was using for building
8.0.5. I have posted separately on the
Eric Anholt e...@anholt.net writes:
Kenneth Graunke kenn...@whitecape.org writes:
do_vec_index_to_swizzle() should remove any vector extract operations
with a constant index. It's unconditionally called from
do_common_optimization().
do_vec_index_to_cond_assign() should remove the rest,
Kenneth Graunke kenn...@whitecape.org writes:
We don't currently use the clipper statistics, but we'll soon use
CL_INVOCATIONS_COUNT to implement the GL_PRIMITIVES_GENERATED query.
The number of primitives generated is not supposed to be altered during
operations such as glGenerateMipmap.
Kenneth Graunke kenn...@whitecape.org writes:
It's just not necessary.
I'd squash this with the previous, and lower-case Kernel -- it seems
to be the convention when it's not part of some other proper noun.
pgpObc4KqS0OC.pgp
Description: PGP signature
Kenneth Graunke kenn...@whitecape.org writes:
In order to implement the GL_PRIMITIVES_GENERATED query in a sane
fashion on our hardware, we can't discard primitives until the clipper.
The patch after next explains the rationale.
By setting the clipper to REJECT_ALL mode, all primitives get
Kenneth Graunke kenn...@whitecape.org writes:
Hello!
This patch series bumps the kernel requirement to 3.6 for Gen6+,
meaning that we actually get to rely on hardware context support.
That's a little painful, but even Debian ships 3.8 now, and this
isn't going to make it into an actual
On Fri, May 17, 2013 at 2:31 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On Fri, May 17, 2013 at 7:44 AM, Jose Fonseca jfons...@vmware.com wrote:
Vinson,
Why is this necessary?
(I'd prefer that LLVM is statically linked by default. )
Jose
The SCons
From: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/r600/evergreen_compute.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 5f67759..4d490c4
From: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/r600/evergreen_compute.c | 68 ++--
1 file changed, 24 insertions(+), 44 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index
From: Roland Scheidegger srol...@vmware.com
Two (somewhat related) issues:
1) We did mask checks between depth/stencil testing and depth/stencil write.
This meant that if the depth/stencil test killed off all fragments we never
actually wrote the new stencil value. This issue affected all
git://people.freedesktop.org/~jljusten/mesa
ivb-layered-color-renderbuffer-v1
This series updates gen7 to allow layered color
render buffers. With these changes we can support
the AMD_vertex_shader_layer extension for color
renderbuffers.
Once depth is also supported, then we can
actually
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/intel/intel_fbo.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 69f8629..a8a7ab3 100644
---
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |6 +-
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |3 +++
src/mesa/drivers/dri/intel/intel_context.h|1 +
3 files changed, 9 insertions(+), 1 deletion(-)
Set the renderbuffer's Depth field to match the texture's
Depth when rendering to a texture.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/intel/intel_fbo.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
Rather than pointing the surface_state directly at a single
sub-image of the texture for rendering, we now point the
surface_state at the top level of the texture, and configure
the surface_state as needed based on this.
We now also need to stop setting the FORCE_ZERO_RTAINDEX bit
in the clip
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/main/texformat.c | 13 +
src/mesa/main/texformat.h |2 ++
2 files changed, 15 insertions(+)
diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
index ed40b7e..a7df868 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=64649
--- Comment #5 from romula...@gmail.com ---
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV770
[Radeon HD 4870]
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=64649
--- Comment #6 from romula...@gmail.com ---
Created attachment 79488
-- https://bugs.freedesktop.org/attachment.cgi?id=79488action=edit
full steam logfile
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=64649
--- Comment #7 from romula...@gmail.com ---
(In reply to comment #4)
Does it look like agraceful exit or a segfault?
No segfault so a graceful exit.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=64730
Priority: medium
Bug ID: 64730
Keywords: regression
CC: jfons...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] piglit array-texture regression
https://bugs.freedesktop.org/show_bug.cgi?id=64730
Roland Scheidegger srol...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Sat, May 18, 2013 at 2:17 AM, Tom Stellard t...@stellard.net wrote:
From: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/r600/evergreen_compute.c | 68
++--
1 file changed, 24 insertions(+), 44 deletions(-)
diff --git
On Sat, May 18, 2013 at 10:11 AM, Jordan Justen
jordan.l.jus...@intel.com wrote:
Rather than pointing the surface_state directly at a single
sub-image of the texture for rendering, we now point the
surface_state at the top level of the texture, and configure
the surface_state as needed based
57 matches
Mail list logo
