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
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-
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
---
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/
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
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.
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 #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
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
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.
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
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
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
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
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
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
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
>
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 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 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
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
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
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=80615
Emil Velikov changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
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
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
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
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
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
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
Kai changed:
What|Removed |Added
CC||emil.l.veli...@gmail.com,
|
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=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
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
__
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
39 matches
Mail list logo
