On Sun, 2014-09-21 at 13:41 +1200, Chris Forbes wrote:
> @@ -592,7 +592,7 @@ lower_packed_varyings_visitor::needs_lowering(ir_variable
> *var)
>return false;
>
> const glsl_type *type = var->type;
> - if (this->gs_input_vertices != 0) {
> + if (this->num_vertices != 0) {
Ok with
On 26/09/14 22:47, Ian Romanick wrote:
> And I was just going to start working on the Mesa software rasterizer
> for DOS. Oh well.
>
> Reviewed-by: Ian Romanick
>
Please go ahead. Pretty sure that'll keep you busy for quite a while :P
Thanks
Emil
__
https://bugs.freedesktop.org/show_bug.cgi?id=80821
--- Comment #1 from Kalrish Bäakjen ---
(In reply to comment #0)
> Tip: As a workaround for this issue, the OpenGL version can be forced by the
> MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE environment
> variables, as described in htt
https://bugs.freedesktop.org/show_bug.cgi?id=84242
--- Comment #1 from Kai ---
Created attachment 106957
--> https://bugs.freedesktop.org/attachment.cgi?id=106957&action=edit
Build log showing the FTBFS
I'm seeing the same FTBFS with Mesa from Git HEAD, LLVM 3.6 from SVN.
I've attached the bu
https://bugs.freedesktop.org/show_bug.cgi?id=84242
Kai changed:
What|Removed |Added
CC||emil.l.veli...@gmail.com,
|
https://bugs.freedesktop.org/show_bug.cgi?id=84242
David Kredba changed:
What|Removed |Added
Summary|Mesa-10.3: |FTBFS: libOpenCL.so.1.0.0:
https://bugs.freedesktop.org/show_bug.cgi?id=84242
--- Comment #3 from Emil Velikov ---
Building OpenCL works like a charm here. Can you try to establish which (if
any) of the following components is responsible - llvm, gcc (*cough*
4.9.2_alpha) binutils or clang.
I'm building it on Archlinux (l
With current makefiles the build fails because source and build paths
are generated incorrectly. With Android build system the top_srcdir and
top_builddir variables are undefined and all paths are relative to where
Android.mk is located. This ends up with path likes
external/mesa/src/mesa/src/mesa/
This patch fixes Android build failures by including src/util directory
in compilation. Files inside of this directory are compiled into
libmesa_util static library and linked with resulting libGLES_mesa.
Signed-off-by: Tomasz Figa
CC:
---
Android.mk | 1 +
src/egl
Even though scope outside the switch statement is unreachable, the
compiler generates a warning, which is treated as error by Android
toolchain. Fix the issue by adding dummy return statement.
Signed-off-by: Tomasz Figa
CC:
---
src/glsl/opt_vectorize.cpp | 1 +
1 file changed, 1 insertion(+)
d
Current Android makefiles lack generation of format_info.c, which is
a dependency of main/format.c. This patch adds necessary code to
Android.gen.mk.
Signed-off-by: Tomasz Figa
CC:
---
src/mesa/Android.gen.mk | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/Android.gen.mk b
This series contains patches fixing build issues spotted while trying to
compile current Mesa master in Android build system. The exact Android
version used was AndroidArmv6 [1] which is directly based on CyanogemMod 11
with additional patches for ARMv6. In terms of build system, it does not
differ
https://bugs.freedesktop.org/show_bug.cgi?id=84242
--- Comment #4 from David Kredba ---
I tested it with LLVM 3.4.2 and the same set of gcc-4.9.2 (svn) and binutils
(svn) used to open this bug report and all built fine. So for me it looks like
that LLVM 3.5.0 came with something changed. Is it no
https://bugs.freedesktop.org/show_bug.cgi?id=80615
Emil Velikov changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=61415
--- Comment #11 from Emil Velikov ---
Fwiw I've nuked the configure parameter considering it was broken for 2+ years
as well as somewhat misleading.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=61415
--- Comment #12 from Mike Lothian ---
No complaints from me
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://li
On 27/09/14 15:20, Tomasz Figa wrote:
> Even though scope outside the switch statement is unreachable, the
> compiler generates a warning, which is treated as error by Android
> toolchain. Fix the issue by adding dummy return statement.
>
I fear that other may have a preference to fix the compiler
On 27.09.2014 16:40, Emil Velikov wrote:
> On 27/09/14 15:20, Tomasz Figa wrote:
>> Even though scope outside the switch statement is unreachable, the
>> compiler generates a warning, which is treated as error by Android
>> toolchain. Fix the issue by adding dummy return statement.
>>
> I fear that
Hi Tomasz,
On 27/09/14 15:19, Tomasz Figa wrote:
> This series contains patches fixing build issues spotted while trying to
> compile current Mesa master in Android build system. The exact Android
> version used was AndroidArmv6 [1] which is directly based on CyanogemMod 11
> with additional patche
On Fri, Sep 26, 2014 at 6:09 PM, Matt Turner wrote:
> ... which leads to incorrect results on 32-bit x86.
>
> Reported-by: Mark Janes
> ---
> I tried writing up a nice commit message that explained what was going
> on and why this worked on 64-bit, but then I realized that it was taking
> orders
Hi Marek,
On the 10.2 tree struct si_shader lacks the scratch_bo member, while
gs_copy_shader is around. Can you let me know if we should drop the
scratch_bo unref line or alternatively can you port the commit against 10.2
Thanks
Emil
On 19/09/14 21:17, Marek Olšák wrote:
> From: Marek Olšák
>
Hi Marek,
This commit introduces a couple of compiler warnings
warning: passing argument 1 of 'pipe_resource_reference' from
incompatible pointer type
Afaics the same behaviour is resent on master, and the commit is simply
missing a cast. I've picked up the patch for 10.2 (and 10.3 in a moment)
b
On 07/25/2014 08:43 AM, Knut Andre Tidemann wrote:
On 07/24/2014 07:16 PM, Matt Turner wrote:
On Fri, Jun 27, 2014 at 1:59 AM, Knut Andre Tidemann
wrote:
v2: fix style and wrong major version comparison.
v3: fix version check in context creation.
---
src/gallium/state_trackers/egl/common/egl
https://bugs.freedesktop.org/show_bug.cgi?id=84242
--- Comment #5 from Emil Velikov ---
(In reply to comment #4)
> I tested it with LLVM 3.4.2 and the same set of gcc-4.9.2 (svn) and binutils
> (svn) used to open this bug report and all built fine.
It may be that llvm 3.5 + mesa is "using" gcc/bi
https://bugs.freedesktop.org/show_bug.cgi?id=84242
--- Comment #6 from David Kredba ---
patch -p1 < ../../binutils-2.24-shared-pie.patch
patching file ld/emultempl/elf32.em
Hunk #1 FAILED at 1480.
Hunk #2 FAILED at 1504.
Hunk #3 FAILED at 1620.
3 out of 3 hunks FAILED -- saving rejects to file l
There should be no warning on master. On master, the variables have
the pipe_resource type. On stable branches, the variables have the
pipe_constant_buffer type, so the expression should be changed to
&...ring->buffer. Without that, it probably crashes.
Marek
On Sat, Sep 27, 2014 at 5:45 PM, Emil
You can drop the scratch_bo line. Thanks.
Marek
On Sat, Sep 27, 2014 at 5:25 PM, Emil Velikov wrote:
> Hi Marek,
>
> On the 10.2 tree struct si_shader lacks the scratch_bo member, while
> gs_copy_shader is around. Can you let me know if we should drop the
> scratch_bo unref line or alternatively
On 27/09/14 18:29, Marek Olšák wrote:
> There should be no warning on master. On master, the variables have
> the pipe_resource type. On stable branches, the variables have the
> pipe_constant_buffer type, so the expression should be changed to
> &...ring->buffer. Without that, it probably crashes.
Transform
sqrt a, b
rcp c, a
into
sqrt a, b
rsq c, b
The improvement here is that we've broken a dependency between these
instructions. Leads to 330 fewer INV instructions and 330 more RSQ.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 11 +++
1 file changed, 11 insertions(+
The next patch adds an algebraic optimization for the pattern
sqrt a, b
rcp c, a
and turns it into
sqrt a, b
rsq c, b
but many vertex shaders do
a = sqrt(b);
var1 /= a;
var2 /= a;
which generates
sqrt a, b
rcp c, a
rcp d, a
If we apply the algebraic optimiz
Transform
sqrt a, b
rcp c, a
into
sqrt a, b
rsq c, b
In most cases the sqrt's result is still used, so the improvement here
is that we've broken a dependency between these instructions. Leads to
80 fewer INV instructions and 80 more RSQ.
Occasionally the sqrt's result is no longe
https://bugs.freedesktop.org/show_bug.cgi?id=80821
--- Comment #2 from Matt Turner ---
Presumably you mean EGL_KHR_create_context?
(GL 3.3 is available on Intel Sandybridge and newer, new Nvidia and new
Radeons. Why do you need LLVMpipe for GL 3.3?)
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=80821
Kalrish Bäakjen changed:
What|Removed |Added
Summary|When LIBGL_ALWAYS_SOFTWARE |When LIBGL_ALWAYS_SOFTWARE
https://bugs.freedesktop.org/show_bug.cgi?id=80821
--- Comment #4 from Kalrish Bäakjen ---
(In reply to comment #2)
> Presumably you mean EGL_KHR_create_context?
>
> (GL 3.3 is available on Intel Sandybridge and newer, new Nvidia and new
> Radeons. Why do you need LLVMpipe for GL 3.3?)
Oh, yes.
My attempts to clarify the code with _compacted/_uncompacted prefixed
variables apparently failed. Hopefully this is clearer.
In any case, the previous code wasn't clear enough to gcc to let it
optimize division by a power of two into a shift. No problems now.
Also, the previous code (in the ADD
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index 2807366..e660ad3 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_compact.c
+++ b/
On Sat, Sep 27, 2014 at 8:09 AM, Jordan Justen wrote:
> On Fri, Sep 26, 2014 at 6:09 PM, Matt Turner wrote:
>> ... which leads to incorrect results on 32-bit x86.
>>
>> Reported-by: Mark Janes
>> ---
>> I tried writing up a nice commit message that explained what was going
>> on and why this wor
https://bugs.freedesktop.org/show_bug.cgi?id=80615
--- Comment #10 from Alexandre Demers ---
Thanks for letting me know. I'll have a look at the result soon enough. ;)
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-
As much as memset clears amuse me, I have to nak this patch as is. The
memset you are using doesn't properly account for the Y-tiled format of the
MCs buffer for certain surface sizes. I can explain more later but the
short version is that the total_height parameter we have in
intel_mipmap_tree m
39 matches
Mail list logo
