On 04/15/2013 11:22 PM, Martin Andersson wrote:
There is a hardware bug on Cayman where a BREAK/CONTINUE followed by
LOOP_STARTxxx for nested loops may put the branch stack into a state
such that ALU_PUSH_BEFORE doesn't work as expected. Workaround this
by replacing the ALU_PUSH_BEFORE with a PUS
This is required in case a wrapper or symlink is used. This patch
has also been sent upstream, awaiting moderation.
Signed-off-by: Andreas Oberritter
---
m4/ax_prog_flex.m4 |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/m4/ax_prog_flex.m4 b/m4/ax_prog_flex.m4
index 117f8f
On 04/15/2013 03:53 PM, Matt Turner wrote:
---
src/mesa/drivers/dri/i965/brw_eu_emit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 704f219..a98892b 100644
--- a/src/mesa/drive
On 04/15/2013 05:53 PM, Ian Romanick wrote:
From: Ian Romanick
Assume the maximum pixel size (16 bytes per pixel). In addition to
moving redundant malloc and free calls outside the loop, this fixes a
potential resource leak when a surface is mapped and the malloc fails.
This also makes blit_ne
Brian Paul writes:
> For the i915 driver, make it a local macro.
> ---
> src/mesa/drivers/dri/i915/intel_tris.c |3 ++-
> src/mesa/main/debug.c |3 +--
> src/mesa/main/enable.c |1 -
> src/mesa/main/mtypes.h |1 -
> src/mesa/main/s
Signed-off-by: Vadim Girlin
---
src/gallium/include/state_tracker/st_api.h | 1 +
src/gallium/state_trackers/dri/common/dri_context.c | 2 ++
src/gallium/state_trackers/dri/common/dri_screen.c | 3 ++-
src/mesa/state_tracker/st_extensions.c | 3 +++
4 files changed, 8 inser
Use alternate code in intel, r200, radeon drivers.
---
src/mesa/drivers/dri/i915/intel_tris.c |3 +++
src/mesa/drivers/dri/r200/r200_state.c |5 +++--
src/mesa/drivers/dri/r200/r200_swtcl.c | 14 +++---
src/mesa/drivers/dri/radeon/radeon_state.c |5 +++--
src/mesa
No longer needed anywhere.
---
src/mesa/drivers/dri/i915/intel_tris.c |7 ---
src/mesa/main/mtypes.h |5 -
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/intel_tris.c
b/src/mesa/drivers/dri/i915/intel_tris.c
index 9a0fef1..
This series removes the _TriangleCaps field and its DD_ flags. They
were basically only used by the legacy i915, radeon and r200 DRI
drivers. Some flags were completely unused. Others are easily
replaced by quering other state. Or, call helper function such as
_mesa_need_secondary_color().
---
src/mesa/drivers/dri/i915/intel_tris.c |2 ++
src/mesa/drivers/dri/r200/r200_swtcl.c | 12 +++-
src/mesa/drivers/dri/radeon/radeon_swtcl.c | 11 +++
src/mesa/main/debug.c | 12
src/mesa/main/debug.h |1
---
src/mesa/drivers/dri/r200/r200_tcl.c|3 ++-
src/mesa/drivers/dri/radeon/radeon_maos_verts.c |3 ++-
src/mesa/drivers/dri/radeon/radeon_tcl.c|3 ++-
src/mesa/main/debug.c |3 +--
src/mesa/main/mtypes.h |1
Make it a local macro for the i915 driver.
---
src/mesa/drivers/dri/i915/intel_tris.c |2 ++
src/mesa/main/debug.c |3 +--
src/mesa/main/enable.c |1 -
src/mesa/main/mtypes.h |1 -
src/mesa/main/state.c |2 --
5
---
src/mesa/main/debug.c |5 ++---
src/mesa/main/enable.c |1 -
src/mesa/main/mtypes.h |1 -
src/mesa/main/state.c |2 --
4 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/debug.c b/src/mesa/main/debug.c
index 77629b9..418f0e2 100644
--- a/src/mesa/mai
For the i915 driver, make it a local macro.
---
src/mesa/drivers/dri/i915/intel_tris.c |3 ++-
src/mesa/main/debug.c |3 +--
src/mesa/main/enable.c |1 -
src/mesa/main/mtypes.h |1 -
src/mesa/main/state.c |8
---
src/mesa/main/debug.c |3 +--
src/mesa/main/enable.c |1 -
src/mesa/main/mtypes.h |1 -
src/mesa/main/state.c |2 --
4 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/debug.c b/src/mesa/main/debug.c
index aee8ae2..4f3d3f6 100644
--- a/src/mesa/main/
For the i915 driver, make it a local macro.
---
src/mesa/drivers/dri/i915/intel_tris.c |5 -
src/mesa/main/debug.c |5 ++---
src/mesa/main/mtypes.h |1 -
src/mesa/main/points.c |5 -
src/mesa/main/state.c |
Make it a local macro for the i915 driver.
---
src/mesa/drivers/dri/i915/intel_tris.c |4
src/mesa/main/debug.c |3 +--
src/mesa/main/mtypes.h |1 -
src/mesa/main/state.c | 23 ---
4 files changed, 5 insertion
---
src/mesa/drivers/dri/r200/r200_swtcl.c |2 +-
src/mesa/drivers/dri/r200/r200_tcl.c |2 +-
src/mesa/main/debug.c |3 +--
src/mesa/main/enable.c |1 -
src/mesa/main/mtypes.h |1 -
src/mesa/main/state.c |2
On Mon, Apr 15, 2013 at 6:53 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/swrast/s_blit.c | 40 +++-
> 1 file changed, 11 insertions(+), 29 deletions(-)
>
>
For the series: Reviewed-by: Brian Paul
___
From: Ian Romanick
Assume the maximum pixel size (16 bytes per pixel). In addition to
moving redundant malloc and free calls outside the loop, this fixes a
potential resource leak when a surface is mapped and the malloc fails.
This also makes blit_nearest look a bit more like blit_linear.
Signe
From: Ian Romanick
This was originally discovered by Klocwork analysis:
Possible memory leak. Dynamic memory stored in 'srcBuffer0'
allocated through function 'malloc' at line 566 can be lost at line
746
However, I think the problem is actually much worse. Since the memory
is freed
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/mesa/swrast/s_blit.c | 40 +++-
1 file changed, 11 insertions(+), 29 deletions(-)
diff --git a/src/mesa/swrast/s_blit.c b/src/mesa/swrast/s_blit.c
index 051354d..f77981f 100644
--- a/src/mesa/swrast/s_bl
Squashed commit of the following:
commit a0df0a0e86c55c1bdc0b9c0f5a739e5adef4b056
Author: Aaron Watry
Date: Mon Apr 15 18:42:04 2013 -0500
libclc: Rename clz.ll to clz_if.ll to ensure it gets built.
configure.py treats files that have the same name with the .cl and .ll
extensions
configure.py allows overloading *.cl with *.ll, but will only ever build
the first file listed in SOURCES of ${file}.cl and ${file}.ll
add_sat, sub_sat, (and the soon to be submitted clz) all define interfaces in
${function_name}.ll which are implemented in ${function_name}_impl.ll.
Renaming the
---
src/mesa/drivers/dri/i965/brw_eu_emit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 704f219..a98892b 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/driver
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 2578bf8..704f219 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/
On Monday 15 April 2013, Marek Olšák wrote:
> I think the problem is _DrawArrays points to a deleted VAO, because we
> don't reset _DrawArrays to NULL. The attached patch should fix it. Please
> review.
I think we should check the first enabled array, since the vbo module
will set up the others to
Marek Olšák writes:
> The main motivation behind NewDriverState is to map GL states to driver
> state groups in a driver-specific manner. For example, some driver may want
> the colormask to be in the framebuffer state, while some other driver may
> want the colormask to be in the blend state. So
https://bugs.freedesktop.org/show_bug.cgi?id=63569
Priority: medium
Group: Mesa Security
Bug ID: 63569
CC: anuj.pho...@gmail.com, bri...@vmware.com,
jljus...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
There is a hardware bug on Cayman where a BREAK/CONTINUE followed by
LOOP_STARTxxx for nested loops may put the branch stack into a state
such that ALU_PUSH_BEFORE doesn't work as expected. Workaround this
by replacing the ALU_PUSH_BEFORE with a PUSH + ALU
Fixes piglit tests EXT_transform_feedback
The main motivation behind NewDriverState is to map GL states to driver
state groups in a driver-specific manner. For example, some driver may want
the colormask to be in the framebuffer state, while some other driver may
want the colormask to be in the blend state. So let's say we have
ctx->Driver
I think the problem is _DrawArrays points to a deleted VAO, because we
don't reset _DrawArrays to NULL. The attached patch should fix it. Please
review.
Marek
On Mon, Apr 15, 2013 at 7:56 PM, Fredrik Höglund wrote:
> Otherwise gl_array_attrib::_DrawArrays can end up pointing at free'd
> memory
s/ReadPixels/ReadBuffer/ in the subject.
I need a bit more time to think about the NewDriverState idea in the
surrounding patches. I don't see there being a meaningful distinction
between which state ends up in NewState versus NewDriverState in this
patch series, and I'd like to actually understa
Marek Olšák writes:
> We don't want to set the flag for Gallium.
>
> I think only swrast needs the flag to be set for occlusion queries.
intel pre-gen6 needs a flag as well to trigger WM key updates for
stats_wm that is updated by BeginQuery. Right now that's provided by
_NEW_DEPTH.
Patch 12-1
Marek Olšák writes:
> No driver checks the flag. Nobody uses it.
>
> I also removed the FLUSH_VERTICES calls, because PixelStorei has no effect
> on rendering.
Patch 7-10 are:
Reviewed-by: Eric Anholt
pgpjEoVP2zN0V.pgp
Description: PGP signature
__
Otherwise gl_array_attrib::_DrawArrays can end up pointing at free'd
memory when the array object is deleted.
Note: This is a candidate for the stable branches.
---
The slightly longer explanation is that the mesa state tracker accesses
_DrawArrays during state validation, and state validation ca
On Thu, Apr 11, 2013 at 01:08:40PM +, Akshay Murarka wrote:
> I wanted to know if it would be possible for me to do the project if I am a
> good coder in the C language but have never used OpenGL.If you would guide me
> from were to read then I would definitely do that .
From: Tom Stellard
---
r600/lib/workitem/get_group_id.ll | 12 ++--
r600/lib/workitem/get_local_size.ll | 12 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/r600/lib/workitem/get_group_id.ll
b/r600/lib/workitem/get_group_id.ll
index 5131648..0dc86e5 1006
On Thu, Apr 11, 2013 at 01:07:50PM +0530, Sreyanth wrote:
> Hi all
>
> I am interested to participate in GSoC this year in X.org. I have gone
> through the proposed ideas and I am interested in working on finding common
> patterns in real GLSL shaders.
>
> I understand that this is a datamining p
https://bugs.freedesktop.org/show_bug.cgi?id=47607
--- Comment #12 from Jordan Justen ---
(In reply to comment #11)
> I wanted to add one note. The game now works for me with
> Mesa 9.0.3 via Steam, but it is crashing for me with Mesa 9.1.1
> after the intro movie. I'll work with the game develop
NAK. I got access to < gen6, and tested this patch. This backport is invalid.
On Wed, Apr 10, 2013 at 8:40 PM, Jordan Justen
wrote:
> From: Eric Anholt
>
> We are intentionally not allocating a slot for gl_ClipVertex. But by
> leaving the bit set in the slots_valid, the fragment shader's comput
On Mon, Apr 15, 2013 at 7:17 AM, Marek Olšák wrote:
> because the code looks at the visual if there is a depth or stencil buffer
> before enabling depth or stencil, respectively.
>
> NOTE: This is a candidate for the stable branches.
> ---
> src/mesa/state_tracker/st_atom_depth.c |2 +-
> 1
On 04/11/2013 04:48 AM, Marek Olšák wrote:
for the env var string not to be awfully long
---
src/gallium/auxiliary/hud/hud_context.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
For the series:
Reviewed-by: Brian Paul
___
On 04/15/2013 08:59 AM, Brian Paul wrote:
On 04/12/2013 05:41 AM, Emil Velikov wrote:
relnotes-*html> relnotes/*html
RELNOTES-*> relnotes/*
fix links, css and frames
Signed-off-by: Emil Velikov
---
For the series: Reviewed-by: Brian Paul
Do you need me to commit this for you?
Nevermind.
On 04/12/2013 05:41 AM, Emil Velikov wrote:
relnotes-*html> relnotes/*html
RELNOTES-*> relnotes/*
fix links, css and frames
Signed-off-by: Emil Velikov
---
For the series: Reviewed-by: Brian Paul
Do you need me to commit this for you?
___
mesa-de
On Fre, 2013-04-12 at 16:29 -0400, Tom Stellard wrote:
> From: Tom Stellard
>
> Instead of emitting configuration values (e.g. number of gprs used) in a
> predefined order, the LLVM backend now emits these values in
> register/value pairs. The first dword contains the register address and
> the
---
src/mesa/main/ffvertex_prog.c |6 --
src/mesa/program/prog_execute.c | 135 -
src/mesa/program/prog_instruction.c |9 --
src/mesa/program/prog_instruction.h | 11 ---
src/mesa/program/prog_opt_constant_fold.c |4 -
sr
---
src/mesa/main/clear.c | 49 -
1 file changed, 12 insertions(+), 37 deletions(-)
diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
index af94333..596b3a1 100644
--- a/src/mesa/main/clear.c
+++ b/src/mesa/main/clear.c
@@ -46,10 +46,6 @@
There used to be a derived state _ClampReadColor, so setting _NEW_COLOR
made sense. The state is gone now.
---
src/mesa/main/blend.c |1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/main/blend.c b/src/mesa/main/blend.c
index 09a1c9a..77fdd61 100644
--- a/src/mesa/main/blend.c
+++ b/s
We don't want to set the flag for Gallium.
I think only swrast needs the flag to be set for occlusion queries.
---
src/mesa/main/queryobj.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index f0db740..29ab149 1006
---
src/mesa/main/depth.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/src/mesa/main/depth.c b/src/mesa/main/depth.c
index 8aec94a..ad19834 100644
--- a/src/mesa/main/depth.c
+++ b/src/mesa/main/depth.c
@@ -46,13 +46,7 @@ _mesa_ClearDepth( GLclampd depth )
if (
The functions don't affect driver state. There is no code that would rely
on vertices being flushed prior to changing the states, and no code that
would check for _NEW_STENCIL before using the states.
---
src/mesa/main/stencil.c |5 -
1 file changed, 5 deletions(-)
diff --git a/src/mesa/m
both functions don't change the framebuffer in any way
(if mesa_meta is not used)
---
src/mesa/main/fbobject.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index fc2b262..f3a14b2 100644
--- a/src/mesa/main/fbobject.c
No driver checks the flag. Nobody uses it.
I also removed the FLUSH_VERTICES calls, because PixelStorei has no effect
on rendering.
---
src/mesa/drivers/dri/i965/brw_state_upload.c |1 -
src/mesa/main/attrib.c |2 --
src/mesa/main/debug.c|
---
src/mesa/drivers/dri/i965/brw_context.c |1 +
src/mesa/drivers/dri/i965/brw_context.h |2 ++
src/mesa/drivers/dri/i965/brw_gs.c |8
src/mesa/drivers/dri/i965/gen7_sol_state.c |8
src/mesa/main/enable.c |3 ++-
src/mes
_NEW_TRANSFORM_FEEDBACK is not used by core Mesa, so it can be removed.
Instead, an new private flag is added to i965 to serve the same purpose.
If you're new to this:
* When creating a context. you can set private dirty flags
in gl_context::DriverFlags, eg.:
ctx->DriverFlags.NewStateX = BR
already set by _mesa_readbuffer
---
src/mesa/main/buffers.c |1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 3f5cbcd..36b0312 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -645,7 +645,6 @@ _mesa_ReadBuffer(GLenum
A driver doesn't have to set _NEW_BUFFER_OBJECT if it doesn't reallocate
the buffer from core Mesa's point of view, which avoids unnecessary state
validation.
Gallium drivers can be asked to reallocate a buffer privately by setting
PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE.
st/mesa doesn't set _NEW_BU
The next patch makes sure _NEW_BUFFER_OBJECT is not needlessly set
for this code.
---
src/mesa/state_tracker/st_cb_bufferobjects.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c
b/src/mesa/state_tracker/st_cb_bufferobjects.c
inde
because the code looks at the visual if there is a depth or stencil buffer
before enabling depth or stencil, respectively.
NOTE: This is a candidate for the stable branches.
---
src/mesa/state_tracker/st_atom_depth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/
- Original Message -
> From: Roland Scheidegger
>
> Inserting the value for the second quad in the wrong place for the
> following shuffle. This meant the row or image stride was undefined which is
> quite catastrophic, can lead to bogus texels fetched or just segfault.
> This code is o
From: Christoph Bumiller
This is the only sane solution for nv50 and nvc0 (really, trust me),
but since on other hardware the border colour is tightly coupled with
texture state they'd have to undo the swizzle, so I've added a cap.
The dependency of update_sampler on the texture updates was
intr
On 04/15/2013 10:52 AM, Martin Andersson wrote:
On Mon, Apr 15, 2013 at 1:09 AM, Vadim Girlin wrote:
On 04/15/2013 01:05 AM, Martin Andersson wrote:
There is a bug where a BREAK/CONTINUE followed by LOOP_STARTxxx for nested
loops may put the branch stack into a state such that ALU_PUSH_BEFORE
- Original Message -
> On 14.04.2013 15:34, Jose Fonseca wrote:
> >
> > - Original Message -
> >> On 14.04.2013 13:44, Jose Fonseca wrote:
> >>> - Original Message -
> From: Christoph Bumiller
>
> This is the only sane solution for nv50 and nvc0 (really, trus
64 matches
Mail list logo
