From: Michel Dänzer michel.daen...@amd.com
For graphics, the LLVM compiler backend currently has many shortcomings
compared to the non-LLVM one. E.g. it can't handle geometry shaders yet,
but that's just the tip of the iceberg.
So building Mesa with --enable-r600-llvm-compiler is currently not
Kenneth Graunke kenn...@whitecape.org writes:
On 04/15/2014 05:59 PM, Carl Worth wrote:
Hi folks,
I've been through all of my email backlog to the mesa-stable@ list and
just pushed out a few additional fixes to the 10.1 branch, (perhaps with
a bit less testing than I would normally do
Prior to commit b207e88b25e526d0f1ada7b19605b880a27866dc (i965/fs:
Support pull parameters in SIMD16 mode.), we only supported pull
constants in SIMD8 mode. SIMD8 shaders are always uncompressed, so
forcing this SEND to be uncompressed should have had no effect.
However, once we began supporting
This is not a review but just a side remark: I strongly believe that in the
medium/long term translate_sse and rtasm modules should be abandoned, and
replaced with a new translate_llvm.c module. All the functionality for doing
so is already in draw/gallivm modules, it's really just a
Michel Dänzer schrieb am 15.04.2014 09:27:
On 23.03.2014 04:53, Kai Wasserbäch wrote:
Dear Mesa devs,
I'm not sure whether this is a bug in Mesa, LLVM or in eglibc. The crash
happens
in _int_malloc, but since that is certainly one of the more often used
functions, I'm not yet convinced, the
Hi, Rob,
Do you think we can push patches 1 trough 3 with a CC to stable for
patch 3?
(It for some reason fixes a rendering error with motif on vmwgfx).
I'm still looking into patches 4 and 5 to investigate why I get
rendering errors.
/Thomas
On 04/08/2014 10:48 PM, Rob Clark wrote:
From:
On Wed, Apr 16, 2014 at 2:12 AM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
For graphics, the LLVM compiler backend currently has many shortcomings
compared to the non-LLVM one. E.g. it can't handle geometry shaders yet,
but that's just the tip of the
On 04/16/2014 06:18 AM, Jose Fonseca wrote:
Module: Mesa
Branch: master
Commit: e3c58cdfd97d390cb4c1a02852ab0417bd68c861
URL:
From: Marek Olšák marek.ol...@amd.com
Use index -1 if a buffer is not added.
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 60 +++
src/gallium/winsys/radeon/drm/radeon_drm_cs.h | 4 +-
2 files changed, 34 insertions(+), 30 deletions(-)
diff --git
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index 45920e8..549a87c 100644
---
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 12 +---
src/gallium/winsys/radeon/drm/radeon_drm_cs.h | 7 +++
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 36 ++-
1 file changed, 8 insertions(+), 28 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Wed, Apr 16, 2014 at 8:12 AM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
For graphics, the LLVM compiler backend currently has many shortcomings
compared to the non-LLVM one. E.g. it can't handle
On Wed, Apr 16, 2014 at 03:12:47PM +0900, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
For graphics, the LLVM compiler backend currently has many shortcomings
compared to the non-LLVM one. E.g. it can't handle geometry shaders yet,
but that's just the tip of the iceberg.
There's no SVGA3D_DECLTYPE that directly corresponds to
PIPE_FORMAT_R8G8B8_SNORM. Previously, we used the swtnl fallback
path to handle this but that's slow and causes invariance issues.
Now we fetch the attribute as SVGA3D_DECLTYPE_UBYTE4N and insert
some extra VS instructions to remap the
---
src/gallium/drivers/svga/svga_tgsi_emit.h | 17 +
src/gallium/drivers/svga/svga_tgsi_insn.c | 21 +
2 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi_emit.h
b/src/gallium/drivers/svga/svga_tgsi_emit.h
---
src/gallium/drivers/svga/svga_tgsi_emit.h | 17 +
src/gallium/drivers/svga/svga_tgsi_insn.c | 21 -
2 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi_emit.h
b/src/gallium/drivers/svga/svga_tgsi_emit.h
This reverts commit c875d6e57a817bb6a8163a8a98ebd2768ee91848.
Conflicts:
src/gallium/drivers/svga/svga_context.c
This work-around will no longer be needed after the next patch
which properly supports signed-byte vertex attributes.
---
src/gallium/drivers/svga/svga_context.c |
There's a few 3-component vertex attribute formats that have no
equivalent SVGA3D_DECLTYPE_x format. Previously, we had to use
the swtnl code to handle them. This patch lets us use hwtnl for
more vertex attribute types by fetching 3-component attributes as
4-component attributes and explicitly
On Wed, Apr 16, 2014 at 02:36:19PM +0200, Kai Wasserbäch wrote:
Michel Dänzer schrieb am 15.04.2014 09:27:
On 23.03.2014 04:53, Kai Wasserbäch wrote:
Dear Mesa devs,
I'm not sure whether this is a bug in Mesa, LLVM or in eglibc. The crash
happens
in _int_malloc, but since that is
We've been testing with Eric's patch as well and it resolves the memory
corruption we were seeing.
Concur with Ken, on going discussion is really about what long term fix /
strategy should be for issues like this.
So, please include in 10.1 stable.
Thanks,
Courtney
On Wed, Apr 16, 2014 at
On 16.04.2014 21:36, Kai Wasserbäch wrote:
P.S.: Sorry for not coming back with a Valgrind log, but after
waiting for almost twelve hours I killed the job and didn't have time
to start a new one.
I don't think valgrind is the right tool for this job anyway.
--
Earthling Michel Dänzer
Fixes the build here as well (r600g+clover,radeonsi+clover). Code
changes look ok, but I'm not super-familiar with the details and I'll
let Tom's reviewed-by stand.
--Aaron
On Tue, Apr 15, 2014 at 8:49 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Just adjust to
Kenneth Graunke kenn...@whitecape.org writes:
Prior to commit b207e88b25e526d0f1ada7b19605b880a27866dc (i965/fs:
Support pull parameters in SIMD16 mode.), we only supported pull
constants in SIMD8 mode. SIMD8 shaders are always uncompressed, so
forcing this SEND to be uncompressed should
Timothy Arceri t_arc...@yahoo.com.au writes:
After a quite look the new series doesnt apply cleanly to 10.1 as there
have been a number of cleanups in between. I don't think I will get
around to rebasing in time for the stable release but I don't think its
a big deal if this fix doesn't go in.
Eric Anholt e...@anholt.net writes:
So, I'd be happy to have it cherry-picked to 10.1.
Yeah, that's my conclusion, too.
OK. Consensus all around. I'll land that (and some other recent fixes),
do one last round of testing and push 10.1.1 out.
I'll be doing 10.0.5 at the same time. I pushed the
From: José Fonseca jfons...@vmware.com
Mostly for consistency; as MSVC's static source code analysis doesn't
seem to rely on assertions, but instead on different kind of source
annotations( http://msdn.microsoft.com/en-us/library/hh916383.aspx ).
---
src/gallium/auxiliary/util/u_debug.h | 3 +++
From: José Fonseca jfons...@vmware.com
Now that _debug_assert_fail() has the noreturn attribute, it is better
that execution truly never returns. Not just for sake of silencing the
warning, but because the code at the return IP address may be invalid or
lead to inconsistent results.
This
From: José Fonseca jfons...@vmware.com
Same intent as commit a45a50a4828e1357e9555474bc127c5585b3a420,
but this the C compiler is detected via C-preprocessor macros,
similar to how autotools do it, as that seems to be the most
reliable method.
---
scons/gallium.py | 38
- Original Message -
On 04/16/2014 06:18 AM, Jose Fonseca wrote:
Module: Mesa
Branch: master
Commit: e3c58cdfd97d390cb4c1a02852ab0417bd68c861
URL:
On 04/16/2014 10:46 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Same intent as commit a45a50a4828e1357e9555474bc127c5585b3a420,
but this the C compiler is detected via C-preprocessor macros,
similar to how autotools do it, as that seems to be the most
reliable method.
Hi folks,
Here are patches that were nominated for the stable branch over one
month ago, but have apparently not yet landed on master. Maybe some of
these have been neglected or missed in the review process?
nv30: report the correct max varying limit (Jan 29, Ilia Mirkin)
mesa: Fix error
On Wed, Apr 16, 2014 at 1:51 PM, Carl Worth cwo...@cworth.org wrote:
Hi folks,
Here are patches that were nominated for the stable branch over one
month ago, but have apparently not yet landed on master. Maybe some of
these have been neglected or missed in the review process?
nv30: report
https://bugs.freedesktop.org/show_bug.cgi?id=77500
Roland Scheidegger srol...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Ilia Mirkin imir...@alum.mit.edu writes:
nv30: report the correct max varying limit (Jan 29, Ilia Mirkin)
I believe this one should have been superceded with commit
356aff3a5c08be (nv30: report 8 maximum inputs), also tagged for
stable.
Thanks for letting me know. And that one is in place
Otherwise there's nothing to do.
---
src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
index
And avoid rewriting other instructions unnecessarily. Removes a few
self-moves we weren't able to handle because they were components of a
large VGRF.
instructions in affected programs: 830 - 826 (-0.48%)
---
src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp | 16 +---
1
---
.../drivers/dri/i965/brw_fs_register_coalesce.cpp | 55 +++---
1 file changed, 28 insertions(+), 27 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
index 8b37ed0..5836fb7 100644
---
We previously only allowed coalescing registers that interfere (i.e.,
whose live ranges overlap) if the destination register's live range was
entirely inside the source's live range. This is unnecessary -- we only
need to check for interfering writes in the intersection of their live
ranges.
We were starting at the beginning of the instruction list, rather than
with the MOV instruction itself. This allows us to coalesce after
control flow.
Excluding the shaders from an unreleased title, the shader-db results:
total instructions in shared programs: 1603791 - 1594215 (-0.60%)
Rather than any old control flow. Muchnick's algorithm just checks for
interfering writes between the MOV and the end of the program. Handling
this when you have backward branches is hard, so don't, but there's no
reason to bail if you see forward branches.
instructions in affected programs:
On Wed, Apr 16, 2014 at 9:09 AM, Thomas Hellstrom thellst...@vmware.com wrote:
Hi, Rob,
Do you think we can push patches 1 trough 3 with a CC to stable for
patch 3?
yes please.. you can push, or I can.. I was just waiting to hear back
from you on the later patches. I meant to propose merging
Ian Romanick i...@freedesktop.org writes:
variable. That's never passed to set_uniform_binding, and it's easier
to just remove the function (especially for later patches in the series)
than to add another parameter.
Hi Ian,
I should have looked closer at this commit when I was reviewing it
On Tue, Apr 15, 2014 at 7:15 PM, Chris Forbes chr...@ijw.co.nz wrote:
Fixes piglit's fbo-blit-stretch test on drivers which use the meta path.
(i965: should fix Broadwell, but also fixes Sandybridge/Ivybridge/Haswell
since this test falls off the blorp path now due to format conversion)
V2:
On 16.04.2014 22:30, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This series is
Reviewed-by: Michel Dänzer michel.daen...@amd.com
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
https://bugs.freedesktop.org/show_bug.cgi?id=74717
--- Comment #17 from Dieter Nützel die...@nuetzel-hh.de ---
(In reply to comment #13)
(In reply to comment #12)
I'm not able to reproduce it (tested with RV770 and CYPRESS) with current
master Mesa 10.2.0-devel (git-f74cf5f).
Both do NOT
https://bugs.freedesktop.org/show_bug.cgi?id=74717
--- Comment #18 from Dieter Nützel die...@nuetzel-hh.de ---
(In reply to comment #16)
$ MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=150
./build/Release/gl-320-primitive-shading
OpenGL Version Needed 3.2 ( 3.2 Found )
0:22(34):
On Wed, Apr 16, 2014 at 10:51 AM, Carl Worth cwo...@cworth.org wrote:
Hi folks,
Here are patches that were nominated for the stable branch over one
month ago, but have apparently not yet landed on master. Maybe some of
these have been neglected or missed in the review process?
nv30:
This sets up the proper execution mask for sends in SIMD16 mode.
Fixes Piglit's glsl-fs-normalmatrix, glsl-fs-uniform-array-2,
glsl-fs-uniform-array-6, and glsl-fs-uniform-array-7 on Ironlake,
which regressed when I enabled SIMD16 pull parameter support in
commit
On 04/14/2014 04:23 PM, Anuj Phogat wrote:
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/drivers/dri/i965/gen7_sol_state.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_sol_state.c
On 04/14/2014 06:59 PM, Chris Forbes wrote:
Are the streamout values allowed to be restricted to the ranges of the
vertex header fields, or do they have to reflect exactly what the
shader wrote?
(I ran into a similar issue with ARB_fragment_layer_viewport, and
while nothing has been done
On 04/07/2014 10:55 AM, Anuj Phogat wrote:
Fixes failures in Khronos OpenGL CTS test conditional_render_test9
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/drivers/dri/i965/intel_fbo.c | 8
1 file changed, 8 insertions(+)
diff --git
On 04/03/2014 06:57 PM, Anuj Phogat wrote:
Fixes failures in Khronos OpenGL CTS test proxy_textures_invalid_samples
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/main/teximage.c | 16 +---
1 file changed, 13 insertions(+),
53 matches
Mail list logo
