Fixes a uninitialized pointer read defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/svga/svga_swtnl_draw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/svga/svga_swtnl_draw.c
b/src/gallium/drivers/svga/svga_swtnl_draw.c
in
https://bugs.freedesktop.org/show_bug.cgi?id=55856
runetmem...@gmail.com changed:
What|Removed |Added
CC||runetmem...@gmail.com
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=55856
Matt Turner changed:
What|Removed |Added
CC||rob...@linux.intel.com
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=55856
wojtek changed:
What|Removed |Added
Assignee|i...@freedesktop.org |mesa-dev@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=55998
--- Comment #29 from wojtek ---
(In reply to comment #21)
> wojtek, your issue with GLES is also reproducible on nouveau and radeon
> drivers. Your issue is not duplicate of this bug.
git bisect bad
e1cb50b15dbb75d1ba0fe184d05be7d302b058ee is th
I removed that code almost a year ago.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 10a8c7f..bb6dfbe 100644
--- a/src/mesa/drivers/dri/intel/int
Now that we have W-tiled S8, we can't just region_map and poke at bits --
there has to be some swizzling. Rely on intel_miptree_map to get that job
done. This should also get the highest performance path we know of for the
mapping.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 101 ++
The kind of data you're copying is definitely an interesting variable.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index
Fixes a theoretical problem where we had an aligned depth buffer and a
misaligned stencil buffer with a matching tile offset, so we would fail
to rebase depth even after the needed tile offset changed due to the
rebase of stencil.
It should also fix double-rebase of a misaligned packed depth/stenc
We were always passing 0 for one of the two fields, and the code just used
whichever one wasn't 0.
---
src/mesa/drivers/dri/i915/i830_texstate.c |2 +-
src/mesa/drivers/dri/i965/brw_blorp.cpp |2 +-
src/mesa/drivers/dri/intel/intel_blit.c |1 -
src/mesa/drivers/dr
Given that we have the mask information here (assuming the rebase is to
the same tiling, which is safe), we can just save a set of miptrees and
offsets and the global intra-tile offset in the context and cut out a
bunch of logic. This will also save emitting the next fix I need to do
twice.
---
s
For a packed depth/stencil buffer on separate stencil hardware, the
separate depth miptree is set up with alignment of 4,4 and the separate
stencil miptree is setup with alignment of 8,8. We can't just use the
irb->draw_{x,y} offsets for stencil, since that is the offset in the
depth miptree.
Fix
I noticed these in the next patch where these paths were using the Face of a
teximage but didn't have array handling.
---
src/mesa/drivers/dri/intel/intel_blit.c |3 +++
src/mesa/drivers/dri/intel/intel_tex_copy.c |5 +
src/mesa/drivers/dri/intel/intel_tex_image.c |6 ++
I hate this code. I've written 5 branches trying to fix this problem; this is
one of two non-regressing branches, and it's the one I hate less.
At this point, the 1024-sized tests are all passing, and only 292/146 tests
are left failing. I haven't debugged any of the remaining failures. The
sim
---
src/mesa/drivers/dri/intel/intel_fbo.h |5 -
1 file changed, 5 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.h
b/src/mesa/drivers/dri/intel/intel_fbo.h
index 9ae961e..9c48e9c 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.h
+++ b/src/mesa/drivers/dri/intel/intel_f
On Mon, Nov 05, 2012 at 08:17:03PM +, Andy Furniss wrote:
> Maybe I am messing up somewhere, but I was previously OK with llvm 3.1.
>
> 32 bit old LFS setup with a 4890 card.
>
> Now I need to use git tstellar/llvm with
> --enable-experimental-targets=AMDGPU.
>
> On head I get a gpu lock wit
https://bugs.freedesktop.org/show_bug.cgi?id=56787
Priority: medium
Bug ID: 56787
Assignee: mesa-dev@lists.freedesktop.org
Summary: Build failure – not checking correct location for
glsl_parser.{cc,h} (source ≠ build)
Severit
New piglit test:
http://lists.freedesktop.org/archives/piglit/2012-November/003690.html
On Mon, Nov 5, 2012 at 12:04 PM, Frank Henigman wrote:
> Should have mentioned it does pass piglit, but now that I look I don't see
> any tests generating an out-of-bounds array index. I also made my own test
On Thu, Nov 1, 2012 at 3:19 PM, Paul Berry wrote:
> This patch series replaces the hand-coded function
> _mesa_create_exec_table() with an equivalent function that is
> generated at compile-time based on the XML in src/mapi/glapi/gen.
> This function is responsible for populating the static entrie
Am 05.11.2012 19:06, schrieb Adhemerval Zanella:
> This patch add correct vector addition and subtraction intrisics when
> using Altivec with PPC. Current code uses default path and LLVM backend
> ends up issuing carry-out arithmetic instruction while it is expected
> saturated ones.
>
> It also i
Am 05.11.2012 18:45, schrieb Adhemerval Zanella:
> Hi all,
>
> This patch adds PPC Altivec support for pack/unpack operations using Altivec
> supported vector type (8xi8, 16xi16, 4xi32, 4xf32). I focused my work on the
> lp_test_conv testcase for llvmpipe and this patch corrects all the failing
>
Maybe I am messing up somewhere, but I was previously OK with llvm 3.1.
32 bit old LFS setup with a 4890 card.
Now I need to use git tstellar/llvm with
--enable-experimental-targets=AMDGPU.
On head I get a gpu lock with anything gl, this from gears -
radeon :01:00.0: GPU lockup CP stall
From: Tom Stellard
---
src/gallium/drivers/r600/r600_pipe.c | 3 +--
src/gallium/drivers/r600/r600_shader.c | 6 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index abe7ad7..c95d6df 100644
---
From: Tom Stellard
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/drivers/r600/r600_pipe.c | 2 ++
src/gallium/drivers/radeonsi/radeonsi_pipe.c | 1 +
src/gallium/include/pipe/p_defines.h | 3 ++-
4 files changed, 7 insertions(+), 1 deletion(-)
diff --git a
From: Tom Stellard
---
src/mesa/main/mtypes.h | 1 +
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 31 +-
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index c8f2ca3..4aba5e8 100644
-
From: Tom Stellard
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 12
src/gallium/auxiliary/tgsi/tgsi_ureg.h | 3 +++
2 files changed, 15 insertions(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 3c2a923..154f4f5 100644
--- a/s
Brian Paul writes:
> On 10/25/2012 10:13 AM, Eric Anholt wrote:
>> The previous 1023-entry chaining hash table never resized, so it was very
>> inefficient when there were many objects live. While one could have an even
>> more efficient implementation than this (keep an array for genned names w
These were only used for geometry shader support back in the days before
the new GLSL compiler. Future geometry shader support will not use
these.
---
src/mesa/program/prog_instruction.c | 2 --
src/mesa/program/prog_instruction.h | 2 --
src/mesa/program/prog_print.c| 6 ---
On 10/30/2012 04:56 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> The parameters and operation of this function changed, but I didn't
> bother to change the prologue comment.
>
> Signed-off-by: Ian Romanick
Reviewed-by: Chad Versace
___
mesa-dev
This patch add correct vector addition and subtraction intrisics when
using Altivec with PPC. Current code uses default path and LLVM backend
ends up issuing carry-out arithmetic instruction while it is expected
saturated ones.
It also includes a fix for PowerPC where char are unsigned by default,
On 11/05/2012 03:54 PM, Adhemerval Zanella wrote:
> This patch adds the PPC Altivec instrics max/min instruction for
> supported Altivec vector types (16xi8, 8xi16, 4xi32, 4xf32).
>
> I focused my testing on the lp_test_conv, which on default behavior
> expands the max/min on vectors. The lp_test_c
This extension is functionally the same as GL_MESA_pack_invert,
but is also available in GLES.
---
docs/relnotes-9.1.html |1 +
src/mapi/glapi/gen/es_EXT.xml|7 +++
src/mesa/main/extensions.c |1 +
src/mesa/main/get_hash_params.py |3 +++
src/mesa/main/glhea
This patch adds the PPC Altivec instrics max/min instruction for
supported Altivec vector types (16xi8, 8xi16, 4xi32, 4xf32).
I focused my testing on the lp_test_conv, which on default behavior
expands the max/min on vectors. The lp_test_conv JIT generation
works as intended, generating vminXXX in
Hi all,
This patch adds PPC Altivec support for pack/unpack operations using Altivec
supported vector type (8xi8, 16xi16, 4xi32, 4xf32). I focused my work on the
lp_test_conv testcase for llvmpipe and this patch corrects all the failing
issues for conversion using the aforementioned vector types.
Should have mentioned it does pass piglit, but now that I look I don't see
any tests generating an out-of-bounds array index. I also made my own test
program which does go out of bounds, and I'll submit that for inclusion in
piglit.
On Fri, Nov 2, 2012 at 4:51 PM, Ian Romanick wrote:
> On 11/02
Regarding 08/17, es/check: This does sound like a worthwhile thing to
investigate for the series.
Regarding 10/17, function suffix: I agree that it would be nice to
cleanup the names. But, this cleanup seems like something that could
wait for a separate series. (And, the python support for alterin
36 matches
Mail list logo
