Kenneth Graunke 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 before pushing)
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 re-factor
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 conv
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: Ro
On Wed, Apr 16, 2014 at 2:12 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> 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 --
On 04/16/2014 06:18 AM, Jose Fonseca wrote:
Module: Mesa
Branch: master
Commit: e3c58cdfd97d390cb4c1a02852ab0417bd68c861
URL:
https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3De3c58cdfd97d390cb4c1a02852ab0417bd68c861&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D
From: Marek Olšák
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 a/src/gallium/winsys/radeon/drm/radeo
From: Marek Olšák
---
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
--- a/src/gallium/winsys/rad
From: Marek Olšák
---
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
b/src/gallium/winsys/radeon/drm/radeon
From: Marek Olšák
---
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 380316e..0ebe196 100644
--- a/
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 16, 2014 at 8:12 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> 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 ice
On Wed, Apr 16, 2014 at 03:12:47PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> 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 Me
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 attrib
---
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
in
---
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
in
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 se
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
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 1:25
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, wrote:
> From: Roland Scheidegger
>
> Just adjust to the ever-changing API, pass in MCC
Kenneth Graunke 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 have had no effect.
>
Timothy Arceri 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.
OK. Thanks for f
Eric Anholt 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 candidate p
From: José Fonseca
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 +++
1 file changed, 3 i
From: José Fonseca
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 removes support for the GA
From: José Fonseca
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 +++---
1 file
- Original Message -
> On 04/16/2014 06:18 AM, Jose Fonseca wrote:
> > Module: Mesa
> > Branch: master
> > Commit: e3c58cdfd97d390cb4c1a02852ab0417bd68c861
> > URL:
> > https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3De3c58cdfd97d390cb4c1a02852ab
On 04/16/2014 10:46 AM, jfons...@vmware.com wrote:
From: José Fonseca
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.
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 cod
On Wed, Apr 16, 2014 at 1:51 PM, Carl Worth 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 the correc
https://bugs.freedesktop.org/show_bug.cgi?id=77500
Roland Scheidegger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Ilia Mirkin 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 on the 10.1 b
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 4e
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 fil
---
.../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
--- a/s
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.
total
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%)
instruct
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: 4
On Wed, Apr 16, 2014 at 9:09 AM, Thomas Hellstrom 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 the first 3
but g
Ian Romanick 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 for
the stable seri
On Tue, Apr 15, 2014 at 7:15 PM, Chris Forbes 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: Use scissor i
On 16.04.2014 22:30, Marek Olšák wrote:
> From: Marek Olšák
This series is
Reviewed-by: Michel Dänzer
--
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 ---
(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 run with curre
https://bugs.freedesktop.org/show_bug.cgi?id=74717
--- Comment #18 from Dieter Nützel ---
(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): error: length call
On Wed, Apr 16, 2014 at 10:51 AM, Carl Worth 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 the corre
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 b207e88b25e526d0f1ada7b19605b880a2
On 04/14/2014 04:23 PM, Anuj Phogat wrote:
> Cc:
> Signed-off-by: Anuj Phogat
> ---
> 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
> b/src/mesa/drivers/dri/i965/gen7_sol_state.c
> index 1b58efb..0
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 do
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
> ---
> src/mesa/drivers/dri/i965/intel_fbo.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
>
On 04/03/2014 06:57 PM, Anuj Phogat wrote:
> Fixes failures in Khronos OpenGL CTS test proxy_textures_invalid_samples
>
> Cc:
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/main/teximage.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/main/t
https://bugs.freedesktop.org/show_bug.cgi?id=76894
Kenneth Graunke changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
> At any rate, Anuj's patches make in-range values actually work, instead
> of nothing working at all, so I think we should take them regardless.
> If we absolutely have to support out-of-range values being copied
> unmodified, then we can revisit this.
Sounds reasonable.
In that case, the series
On 04/02/2014 11:30 PM, Samuel Iglesias Gonsalvez wrote:
> According to the spec:
For future reference, it's really helpful to say which spec you're
quoting. Otherwise it's not clear whether you mean the
ARB_framebuffer_object extension spec, or the GL 3.0, 3.1, 3.2 specs.
Occasionally, those spe
On 03/31/2014 02:00 PM, Anuj Phogat wrote:
> In OpenGL 3.1 attribute 0 becomes non-magic, just like in
> OpenGL ES 2.0. Earlier versions of OpenGL used attribute 0
> exclusively for vertex position.
>
> Fixes 4 Khronos OpenGL CTS failures:
> glGetVertexAttrib
> depth24_basic
> depth24_precision
>
On 04/14/2014 12:14 AM, Iago Toral Quiroga wrote:
> ---
> src/glsl/ast_to_hir.cpp | 1575
> +++
> 1 file changed, 782 insertions(+), 793 deletions(-)
I reviewed the output of "git show -b" to make sure there were no
non-whitespace changes slipped in wi
On 04/12/2014 10:30 PM, Chris Forbes wrote:
> The ARB_fragment_coord_conventions spec, section 4.3.x (Input Layout
> Qualifiers) says:
>
> "All redeclarations of gl_FragCoord in all fragment shaders in a
> single program must have the same set of qualifiers. Within any
> shader, the first re
On 04/15/2014 03:30 AM, Iago Toral Quiroga wrote:
> Once the relevant branch has been identified do not iterate over the
> instructions in the branch, do a linked list insertion instead to avoid the
> loop.
> ---
> src/glsl/opt_if_simplification.cpp | 10 ++
> 1 file changed, 2 insertions(
59 matches
Mail list logo
