On 05/23/2013 11:54 PM, Vinson Lee wrote:
Fixes Uninitialized pointer field defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/glsl/lower_named_interface_blocks.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On 06/05/2013 02:42 AM, Andreas Boll wrote:
Both variables had the same value.
Signed-off-by: Andreas Boll andreas.boll@gmail.com
---
Makefile.am |1 -
docs/devinfo.html |1 -
2 files changed, 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 92b792d..29405a0
On 06/05/2013 10:14 AM, Eric Anholt wrote:
Now any caller (such as glCopyPixels()) can benefit from it, and it only
changes the correct subset of the destination instead of a whole teximage.
---
src/mesa/drivers/dri/intel/intel_blit.c | 114 ++
On 06/05/2013 10:14 AM, Eric Anholt wrote:
This gets us support for blitting to attachment types other than
textures.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 129 +++-
src/mesa/drivers/dri/intel/intel_tex.h | 7 --
On 06/05/2013 10:14 AM, Eric Anholt wrote:
This will get reused shortly.
---
src/mesa/drivers/dri/intel/intel_blit.c | 70 +
1 file changed, 36 insertions(+), 34 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_blit.c
On 06/05/2013 03:50 PM, Chris Forbes wrote:
When clipping against a user clip plane, and gl_ClipVertex is provided
in the vertex, use it instead of hpos.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_clip.h | 1 +
src/mesa/drivers/dri/i965/brw_clip_tri.c
Fixes Out-of-bounds access defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/mesa/main/dlist.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index abc8665..8900c89 100644
---
Having figured out what was going on with piglit fbo-depth copypixels
GL_DEPTH_COMPONENT32F (falling all the way back to swrast on CopyPixels to
a float depth buffer), I'm not inclined to fix the problem currently but
it seems worth saving someone else the debug time.
---
https://bugs.freedesktop.org/show_bug.cgi?id=61821
Andreas Boll andreas.boll@gmail.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Michel Dänzer mic...@daenzer.net writes:
On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote:
(2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the
mesa-like ones with msb first. (I'm happy to change the names to
something else though.)
The patch isn't in
It seems that you didn't understand me or I didn't undrstand you. For
example gl_enums.py has all the 3 functions. How do I deal with that
file? I don't thing it's the right way to change for example
_mesa_lookup_prim_by_nr() there, then send this patch, then change
back from _mesa_prim_string()
Because draw_arrays() is only sued in state_tracker's st_draw_feedback.c file,
I moved it from draw_pt.c to there and mate it static.
---
v2: removed draw_arrays_instanced() function and modified draw_arrays()
src/mesa/state_tracker/st_draw_feedback.c | 26 +++---
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=65426
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org
https://bugs.freedesktop.org/show_bug.cgi?id=65426
--- Comment #5 from Grigori Goronzy g...@chown.ath.cx ---
Is this really a problem? Mesa might not always reuse buffer names, but that
does not mean the buffer wasn't properly deleted. As far as I can see, OpenGL
does not require name reuse.
--
On 06.06.2013 10:34, Richard Sandiford wrote:
Michel Dänzer mic...@daenzer.net writes:
On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote:
(2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the
mesa-like ones with msb first. (I'm happy to change the names to
On Thu, Jun 6, 2013 at 10:44 AM, Arnas Milaševičius wrote:
It seems that you didn't understand me or I didn't undrstand you. For
example gl_enums.py has all the 3 functions. How do I deal with that
file? I don't thing it's the right way to change for example
_mesa_lookup_prim_by_nr() there,
On Thu, Jun 06, 2013 at 11:30:50AM +0200, Michel Dänzer wrote:
On Mit, 2013-06-05 at 15:00 +1000, Jonathan Gray wrote:
RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mesa
uses it with drmCommandWriteRead instead of drmCommandWrite
which leads to the ioctl being unmatched and returning an
On Mon, Jun 3, 2013 at 5:59 PM, Brian Paul brian.e.p...@gmail.com wrote:
I seem to recall that this choose a gallium format for a given GL
format/type code appears elsewhere in the state tracker (but haven't
double-checked). In any case, it would be nicer if this code was moved into
a
On Don, 2013-06-06 at 21:23 +1000, Jonathan Gray wrote:
On Thu, Jun 06, 2013 at 11:30:50AM +0200, Michel Dänzer wrote:
On Mit, 2013-06-05 at 15:00 +1000, Jonathan Gray wrote:
RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mesa
uses it with drmCommandWriteRead instead of drmCommandWrite
On Thu, Jun 6, 2013 at 4:56 AM, Arnas Milasevicius giant...@gmail.com wrote:
Because draw_arrays() is only sued in state_tracker's st_draw_feedback.c
file, I moved it from draw_pt.c to there and mate it static.
A couple of typos:
sued - used
mate - made
Also, please try and make your commit
Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced()
---
v2: removed draw_arrays_instanced() function and modified draw_arrays()
v3: improved commit massage
src/mesa/state_tracker/st_draw_feedback.c | 26 +++---
1 file changed, 7 insertions(+), 19
Christoph Bumiller e0425...@student.tuwien.ac.at writes:
On 06.06.2013 10:34, Richard Sandiford wrote:
Michel Dänzer mic...@daenzer.net writes:
On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote:
(2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the
mesa-like ones
So, should I resend it with `git mv` or we will leave this file's name as
it is?
On Thu, Jun 6, 2013 at 3:23 AM, Brian Paul bri...@vmware.com wrote:
On 06/05/2013 03:25 PM, Kenneth Graunke wrote:
On 06/05/2013 12:09 PM, Arnas Milasevicius wrote:
---
src/mesa/Makefile.sources | 2
This is a v2 version, by the way.
On Thu, Jun 6, 2013 at 11:56 AM, Arnas Milasevicius giant...@gmail.comwrote:
Because draw_arrays() is only sued in state_tracker's st_draw_feedback.c
file, I moved it from draw_pt.c to there and mate it static.
---
v2: removed draw_arrays_instanced()
On Don, 2013-06-06 at 14:21 +0200, Michel Dänzer wrote:
On Don, 2013-06-06 at 21:23 +1000, Jonathan Gray wrote:
On Thu, Jun 06, 2013 at 11:30:50AM +0200, Michel Dänzer wrote:
On Mit, 2013-06-05 at 15:00 +1000, Jonathan Gray wrote:
RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mesa
On 06/06/2013 05:40 AM, Arnas Milasevicius wrote:
Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced()
---
v2: removed draw_arrays_instanced() function and modified draw_arrays()
v3: improved commit massage
src/mesa/state_tracker/st_draw_feedback.c | 26
Looks good to me. Is there a piglit test for this?
--Aaron
On Wed, Jun 5, 2013 at 7:12 PM, Tom Stellard t...@stellard.net wrote:
From: Tom Stellard thomas.stell...@amd.com
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git
On 06/05/2013 11:05 PM, Vinson Lee wrote:
Fixes Out-of-bounds access defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/mesa/main/dlist.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
On Wed, Jun 5, 2013 at 10:11 PM, Roland Scheidegger srol...@vmware.comwrote:
Am 06.06.2013 04:16, schrieb Roland Scheidegger:
Am 06.06.2013 02:52, schrieb Brian Paul:
On 06/05/2013 05:44 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Also report if a shader
From: Brian Paul bri...@vmware.com
This change came from the discovery that the STATIC_ASSERT to check that
the number of register file strings didn't actually work.
Similar changes could be make for the other string arrays in tgsi_string.c
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
Am 06.06.2013 17:56, schrieb Brian Paul:
From: Brian Paul bri...@vmware.com
This change came from the discovery that the STATIC_ASSERT to check that
the number of register file strings didn't actually work.
Similar changes could be make for the other string arrays in tgsi_string.c
---
https://bugs.freedesktop.org/show_bug.cgi?id=62647
--- Comment #22 from Eric Anholt e...@anholt.net ---
The debug=wm output looks reasonable to me. Only funky thing I see at the
moment is the gl_FogFragCoord output from the VS not getting dead code
eliminated, but that should be fine (looks like
On Sat, May 25, 2013 at 2:13 AM, Kenneth Graunke kenn...@whitecape.org wrote:
On 05/24/2013 06:28 PM, Matt Turner wrote:
From: Todd Previte tprev...@gmail.com
v2 [mattst88]
- Split infrastructure into separate patch.
- Add preprocessor #define.
Patches 1-5 and 7 are:
Reviewed-by:
Kenneth Graunke kenn...@whitecape.org writes:
On 06/05/2013 10:14 AM, Eric Anholt wrote:
This will get reused shortly.
---
src/mesa/drivers/dri/intel/intel_blit.c | 70
+
1 file changed, 36 insertions(+), 34 deletions(-)
diff --git
On 06/06/2013 09:59 AM, Eric Anholt wrote:
Kenneth Graunke kenn...@whitecape.org writes:
On 06/05/2013 10:14 AM, Eric Anholt wrote:
This will get reused shortly.
---
src/mesa/drivers/dri/intel/intel_blit.c | 70
+
1 file changed, 36 insertions(+), 34
https://bugs.freedesktop.org/show_bug.cgi?id=65426
--- Comment #6 from José Fonseca jfons...@vmware.com ---
(In reply to comment #5)
Is this really a problem? Mesa might not always reuse buffer names, but that
does not mean the buffer wasn't properly deleted. As far as I can see,
OpenGL does
Just like we produce from inside the Intel driver, this can help provide
information quickly about FBO incompatibility problems (particularly when
using apitrace replay).
Currently, in driver-marked incompleteness cases, you'll get both the
driver message and the core message on Intel. Until the
https://bugs.freedesktop.org/show_bug.cgi?id=65475
Priority: medium
Bug ID: 65475
Assignee: mesa-dev@lists.freedesktop.org
Summary: Inconsistent use of both stderr and stdout for debug
output
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=65426
--- Comment #7 from Brian Paul bri...@vmware.com ---
(In reply to comment #6)
(In reply to comment #5)
Is this really a problem? Mesa might not always reuse buffer names, but that
does not mean the buffer wasn't properly deleted. As far as I
On 06/06/2013 11:16 AM, Eric Anholt wrote:
Just like we produce from inside the Intel driver, this can help provide
information quickly about FBO incompatibility problems (particularly when
using apitrace replay).
Currently, in driver-marked incompleteness cases, you'll get both the
driver
Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced()
---
v2: removed draw_arrays_instanced() function and modified draw_arrays()
v3: improved commit massage
v4: removed startInstance and instanceCount parameters from draw_arrays()
https://bugs.freedesktop.org/show_bug.cgi?id=65426
--- Comment #8 from Dan Allen dan.j.al...@ntlworld.com ---
(In reply to comment #5)
Is this really a problem? Mesa might not always reuse buffer names, but that
does not mean the buffer wasn't properly deleted. As far as I can see,
OpenGL does
On 5 June 2013 10:14, Eric Anholt e...@anholt.net wrote:
Intel had brokenness here, and I'd like to continue moving Mesa toward
hiding 1D_ARRAY's ridiculousness inside of the core, like we did with
MapTextureImage. Fixes copyteximage 1D_ARRAY on intel.
There's still an impedance mismatch in
On 06/05/2013 10:14 AM, Eric Anholt wrote:
Intel had brokenness here, and I'd like to continue moving Mesa toward
hiding 1D_ARRAY's ridiculousness inside of the core, like we did with
MapTextureImage. Fixes copyteximage 1D_ARRAY on intel.
There's still an impedance mismatch in meta when
On 06/06/2013 12:28 PM, Arnas Milasevicius wrote:
Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced()
---
v2: removed draw_arrays_instanced() function and modified draw_arrays()
v3: improved commit massage
message
v4: removed startInstance and instanceCount
On 5 June 2013 10:14, Eric Anholt e...@anholt.net wrote:
This will get reused shortly.
---
src/mesa/drivers/dri/intel/intel_blit.c | 70
+
1 file changed, 36 insertions(+), 34 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_blit.c
https://bugs.freedesktop.org/show_bug.cgi?id=65426
--- Comment #9 from Brian Paul bri...@vmware.com ---
(In reply to comment #8)
(In reply to comment #5)
Is this really a problem? Mesa might not always reuse buffer names, but that
does not mean the buffer wasn't properly deleted. As far as I
https://bugs.freedesktop.org/show_bug.cgi?id=65426
--- Comment #10 from Dan Allen dan.j.al...@ntlworld.com ---
(In reply to comment #9)
(In reply to comment #8)
(In reply to comment #5)
Is this really a problem? Mesa might not always reuse buffer names, but
that
does not mean the
https://bugs.freedesktop.org/show_bug.cgi?id=65426
Laurent carlier lordhea...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
One thing you work on if you're interested in that would be the softpipe
driver. This is generally easier than other drivers as it doesn't
require any knowledge of the hw and it is easier to debug, though you'd
need more knowledge about gallium rather than OpenGL directly. The
problem with it is
Noticed by inspection when reviewing the next commit.
---
src/mesa/main/get_hash_params.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 7dfc9db..8b5985a 100644
--- a/src/mesa/main/get_hash_params.py
Part of fixing piglit OpenGL ES 3.0/minmax.
---
src/mesa/main/get.c | 3 ++-
src/mesa/main/get_hash_params.py | 8
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 593c75b..316d453 100644
--- a/src/mesa/main/get.c
piglit OpenGL ES 3.0/minmax now passes. This was also one of the subcase
failures in OpenGL 3.2/minmax (and still is, because our value is too low
for 3.2, but at least we report what it is).
---
src/mesa/main/get.c | 7 +++
src/mesa/main/get_hash_params.py | 3 +++
2 files
Part of fixing piglit OpenGL ES 3.0/minmax.
---
src/mesa/main/get.c | 6 ++
src/mesa/main/get_hash_params.py | 6 --
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 316d453..b14c9f7 100644
---
Brian Paul bri...@vmware.com writes:
On 06/06/2013 11:16 AM, Eric Anholt wrote:
Just like we produce from inside the Intel driver, this can help provide
information quickly about FBO incompatibility problems (particularly when
using apitrace replay).
Currently, in driver-marked
I get random results when I run the spec/!OpenGL 1.1/read-front test.
Sometimes it passes and sometimes it failes, it mostly fails though.
When it fails the observed values are random. I have an AMD 6950,
running mesa git ce67fb4715e0c2fab01de33da475ef4705622020 and kernel
3.10-rc4.
If I insert a
Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced()
---
v5: combined patches together
src/gallium/auxiliary/draw/draw_context.h | 11 -
src/gallium/auxiliary/draw/draw_pt.c | 40 ---
src/mesa/state_tracker/st_draw_feedback.c |
There are bugs in both piglit and DRI2. I haven't looked into the
issue, but Paul Berry seems to be working on it.
See:
http://lists.freedesktop.org/archives/piglit/2013-May/005880.html
http://lists.freedesktop.org/archives/mesa-dev/2013-May/039985.html
Marek
On Fri, Jun 7, 2013 at 12:04 AM,
On Thu, Jun 6, 2013 at 2:56 PM, Eric Anholt e...@anholt.net wrote:
Part of fixing piglit OpenGL ES 3.0/minmax.
---
src/mesa/main/get.c | 3 ++-
src/mesa/main/get_hash_params.py | 8
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/get.c
From: Roland Scheidegger srol...@vmware.com
Transfers always use z/depth for layers no matter if it's a 1d or 2d array
texture, we don't follow OpenGL's crazyness there. Luckily this appears to
only be a doc bug, everyone doing the right thing already.
While here also document z/depth parameter
From: Roland Scheidegger srol...@vmware.com
Believe it or not but these two are actually the first two functions which
really belong in this file nowadays.
---
src/gallium/drivers/llvmpipe/lp_surface.c | 59 -
src/gallium/drivers/llvmpipe/lp_texture.c | 59
From: Roland Scheidegger srol...@vmware.com
These functions must clear all bound layers, not just the first.
---
src/gallium/auxiliary/util/u_surface.c | 190 +--
src/gallium/auxiliary/util/u_transfer.c |1 +
2 files changed, 104 insertions(+), 87 deletions(-)
On 06/06/2013 02:56 PM, Eric Anholt wrote:
Part of fixing piglit OpenGL ES 3.0/minmax.
---
src/mesa/main/get.c | 3 ++-
src/mesa/main/get_hash_params.py | 8
2 files changed, 6 insertions(+), 5 deletions(-)
Series looks good to me.
Reviewed-by: Kenneth Graunke
Signed-off-by: Chia-I Wu olva...@gmail.com
---
src/gallium/auxiliary/util/u_vbuf.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_vbuf.c
b/src/gallium/auxiliary/util/u_vbuf.c
index 244b04d..5936f74 100644
--- a/src/gallium/auxiliary/util/u_vbuf.c
+++
64 matches
Mail list logo
