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
---
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 o...@saftware.de
---
m4/ax_prog_flex.m4 |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/m4/ax_prog_flex.m4
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
On 04/15/2013 11:05 PM, Kenneth Graunke wrote:
On 04/15/2013 05:53 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
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
On one of my builds I have libdrm/mesa/xorg living under my home,
normally I can build mesa by setting LDFLAGS and --prefix= but since the
uvd commit I get -
Making all in radeon
make[3]: Entering directory
`/mnt/sdb1/Src/Mesa-git/mesa/src/gallium/drivers/radeon'
CC radeon_uvd.lo
In
The set introduces new target for 'eglCreateImageKHR()' allowing one
to create EGL images out of externally allocated buffers. Especially
one can combine up to three separate buffers into one single logical
entity. Low level native buffers may not support planar formats and
hence EGL layer will
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/intel/intel_fbo.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index c79b56a..1b72ac6 100644
---
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index
No functional change in preparation for supporting multiple planes
per image each having its own region.
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/intel/intel_fbo.c | 6 +--
src/mesa/drivers/dri/intel/intel_regions.h | 7 ++-
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 101 +-
1 file changed, 71 insertions(+), 30 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
include/GL/internal/dri_interface.h| 23 +++
src/egl/drivers/dri2/egl_dri2.c| 1 +
src/mesa/drivers/dri/intel/intel_regions.h | 7 +++
src/mesa/drivers/dri/intel/intel_screen.c | 9
As specified in:
http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
Checking for the valid fourcc values is left for drivers avoiding
dependency to drm header files here.
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
include/EGL/eglext.h
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/egl/drivers/dri2/egl_dri2.c | 238
1 file changed, 238 insertions(+)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 5302c0a..1ab6a82 100644
---
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/intel/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel_extensions.c
index 1ad728a..c8d6891 100755
---
On Tue, Apr 16, 2013 at 2:46 AM, Vadim Girlin vadimgir...@gmail.com wrote:
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
We don't want to set the flag for Gallium.
I think only swrast needs the flag to be set for occlusion queries.
Reviewed-by: Brian Paul bri...@vmware.com
v2: fix stats_wm updates in i965
---
Something like this, Eric?
src/mesa/drivers/dri/i965/brw_cc.c |2 +-
On Mon, Apr 15, 2013 at 07:14:28PM -0500, Aaron Watry wrote:
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
On Sat, Apr 13, 2013 at 11:22:51AM -0500, Aaron Watry wrote:
Implements the min() OpenCL built-in in 2 stages.
1) Implement min() where the two argument types match
2) Make changes to support min(vec,scalar)
For the series:
Reviewed-by: Tom Stellard thomas.stell...@amd.com
On Mon, Apr 15, 2013 at 07:20:31PM -0500, Aaron Watry wrote:
Reviewed-by: Tom Stellard thomas.stell...@amd.com
Squashed commit of the following:
commit a0df0a0e86c55c1bdc0b9c0f5a739e5adef4b056
Author: Aaron Watry awa...@gmail.com
Date: Mon Apr 15 18:42:04 2013 -0500
libclc: Rename
From: Ian Romanick ian.d.roman...@intel.com
The caller of NewTextureObject does the right thing if NULL is returned,
so this function should do the right thing too.
NOTE: This is a candidate for stable branches.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
On Tue, Apr 16, 2013 at 2:54 AM, Andy Furniss andy...@ukfsn.org wrote:
On one of my builds I have libdrm/mesa/xorg living under my home, normally I
can build mesa by setting LDFLAGS and --prefix= but since the uvd commit I
get -
Making all in radeon
make[3]: Entering directory
On Sat, Apr 13, 2013 at 11:32:18AM -0500, Aaron Watry wrote:
For any GENTYPE that isn't scalar, we need to implement a mixed
vector/scalar version of clamp/max.
This depends on the min() patches I sent to the list a few minutes ago.
Reviewed-by: Tom Stellard thomas.stell...@amd.com
---
Hi list,
On Thu, Dec 13, 2012 at 6:41 AM, Chia-I Wu olva...@gmail.com wrote:
Hi list,
I've been working on i965g, a new pipe driver for Intel GEN6 (and
later), for a while now. I would like to know if there is any
interest in it and if it can be merged upstream. The code is
currently
On Tue, Apr 16, 2013 at 9:45 AM, Chia-I Wu olva...@gmail.com wrote:
If there is no objection, I'd like to merge it in a day or two.
My only objection is over adding a driver that is explicitly a toy,
the confusion it will cause users, and the developer time it will
waste. It wasn't uncommon for
On 04/16/2013 09:58 AM, Matt Turner wrote:
On Tue, Apr 16, 2013 at 9:45 AM, Chia-I Wu olva...@gmail.com wrote:
If there is no objection, I'd like to merge it in a day or two.
My only objection is over adding a driver that is explicitly a toy,
the confusion it will cause users, and the
On 04/16/2013 09:58 AM, Matt Turner wrote:
On Tue, Apr 16, 2013 at 9:45 AM, Chia-I Wu olva...@gmail.com wrote:
If there is no objection, I'd like to merge it in a day or two.
My only objection is over adding a driver that is explicitly a toy,
the confusion it will cause users, and the
On 04/16/2013 09:32 AM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
The caller of NewTextureObject does the right thing if NULL is returned,
so this function should do the right thing too.
NOTE: This is a candidate for stable branches.
Signed-off-by: Ian Romanick
On Tue, Apr 16, 2013 at 10:18 AM, Kenneth Graunke kenn...@whitecape.org wrote:
On 04/16/2013 09:58 AM, Matt Turner wrote:
On Tue, Apr 16, 2013 at 9:45 AM, Chia-I Wu olva...@gmail.com wrote:
If there is no objection, I'd like to merge it in a day or two.
My only objection is over adding a
On 04/06/2013 11:36 AM, Stefan Brüns wrote:
Am Freitag, 22. März 2013, 11:46:52 schrieben Sie:
To call glFoo, the xserver (or libGL) does
(dispatch_table[offset_of_glFoo])(...);
To set the pointer for the glFoo function, the driver does
Am Dienstag, den 16.04.2013, 10:23 -0700 schrieb Matt Turner:
waste. It wasn't uncommon for a user to waste a nontrivial amount of
someone's time in #intel-gfx only to discover that they were trying to
use the (old) i965g driver that no one maintained.
I wonder, should i965g be built by
On Tue, Apr 16, 2013 at 10:35 AM, Michael Karcher
michael.karc...@fu-berlin.de wrote:
I suspect there might be a comparable need for a i965g driver, as that
chip has no vertex shader hardware.
This isn't true.
___
mesa-dev mailing list
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 16750f2..27b992c 100644
---
From: Roland Scheidegger srol...@vmware.com
This will calculate rho correctly as
sqrt(max((ds/dx)^2 + (dt/dx)^2 + (dr/dx)^2), (ds/dx)^2 + (dt/dx)^2 + (dr/dx)^2))
instead of max(|ds/dx|,|dt/dx|,|dr/dx|,|ds/dy|,|dt/dy,|dr/dy|)
(for 3 coords - 2 coords work analogous, for 1 coord there's no point
From: Roland Scheidegger srol...@vmware.com
Turns out the previous fix for handling per-pixel face selection and
derivatives didn't work out that well - the derivatives were wrong by
quite a bit, in theory transformation of the derivatives into cube space
should work, but would be _a lot_ more
On 04/16/2013 01:07 PM, srol...@vmware.com wrote:
From: Roland Scheideggersrol...@vmware.com
This will calculate rho correctly as
sqrt(max((ds/dx)^2 + (dt/dx)^2 + (dr/dx)^2), (ds/dx)^2 + (dt/dx)^2 + (dr/dx)^2))
instead of max(|ds/dx|,|dt/dx|,|dr/dx|,|ds/dy|,|dt/dy,|dr/dy|)
(for 3 coords - 2
On 04/16/2013 01:07 PM, srol...@vmware.com wrote:
From: Roland Scheideggersrol...@vmware.com
Turns out the previous fix for handling per-pixel face selection and
derivatives didn't work out that well - the derivatives were wrong by
quite a bit, in theory transformation of the derivatives into
Hi Matt,
On Wed, Apr 17, 2013 at 12:58 AM, Matt Turner matts...@gmail.com wrote:
On Tue, Apr 16, 2013 at 9:45 AM, Chia-I Wu olva...@gmail.com wrote:
If there is no objection, I'd like to merge it in a day or two.
My only objection is over adding a driver that is explicitly a toy,
the
On 04/16/2013 10:35 AM, Michael Karcher wrote:
Am Dienstag, den 16.04.2013, 10:23 -0700 schrieb Matt Turner:
waste. It wasn't uncommon for a user to waste a nontrivial amount of
someone's time in #intel-gfx only to discover that they were trying to
use the (old) i965g driver that no one
Am 16.04.2013 21:41, schrieb Brian Paul:
On 04/16/2013 01:07 PM, srol...@vmware.com wrote:
From: Roland Scheideggersrol...@vmware.com
This will calculate rho correctly as
sqrt(max((ds/dx)^2 + (dt/dx)^2 + (dr/dx)^2), (ds/dx)^2 + (dt/dx)^2 +
(dr/dx)^2))
instead of
Hi Ken,
On Wed, Apr 17, 2013 at 1:18 AM, Kenneth Graunke kenn...@whitecape.orgwrote:
On 04/16/2013 09:58 AM, Matt Turner wrote:
On Tue, Apr 16, 2013 at 9:45 AM, Chia-I Wu olva...@gmail.com wrote:
If there is no objection, I'd like to merge it in a day or two.
My only objection is over
- Original Message -
The R600 code looks good.
Marek
When I rebased on top of master, I had a conflict on r600. Below is how I
resolved. Please confirm you're OK with it.
Jose
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index
Topi Pohjolainen topi.pohjolai...@intel.com writes:
The set introduces new target for 'eglCreateImageKHR()' allowing one
to create EGL images out of externally allocated buffers. Especially
one can combine up to three separate buffers into one single logical
entity. Low level native buffers
i965 is fully programmable. It can do vertex, geometry, hull, domain, and
fragment shading in hardware. The only thing the i965 classic driver uses
software rendering for is some deprecated and rarely used GL 1.x features.
I think the original 965G and 965GM chip suffered from a balance
Fixes issue identified by Klocwork analysis:
'attribute_map' array elements might be used uninitialized in this
function (vec4_visitor::lower_attributes_to_hw_regs).
The attribute_map array contains the mapping from shader input
attributes to the hardware registers they are stored in.
Thanks for the update.
Looks good to me FWIW.
Jose
- Original Message -
From: Christoph Bumiller christoph.bumil...@speed.at
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
Hi Jose,
This looks good to me.
Marek
On Tue, Apr 16, 2013 at 10:11 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
The R600 code looks good.
Marek
When I rebased on top of master, I had a conflict on r600. Below is how I
resolved. Please confirm you're
Those are just ideas. I'm open to discussion.
The driver is disabled by default and needs to be enabled via
--with-gallium-drivers=i965.
I think a warning + maybe something like
--with-gallium-drivers=i965g-unofficial might work,
the thing is distros should probably be using i915g at this
https://bugs.freedesktop.org/show_bug.cgi?id=63615
Priority: medium
Bug ID: 63615
Assignee: mesa-dev@lists.freedesktop.org
Summary: build fails after configure
Severity: critical
Classification: Unclassified
OS: Linux (All)
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On Tue, Apr 16, 2013 at 11:11 AM, Anuj Phogat anuj.pho...@gmail.com wrote:
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
On Tue, Apr 16, 2013 at 11:11 AM, Anuj Phogat anuj.pho...@gmail.com wrote:
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
https://bugs.freedesktop.org/show_bug.cgi?id=63615
burlen burlen.lor...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Tue, Apr 16, 2013 at 3:06 PM, Matt Turner matts...@gmail.com wrote:
On Tue, Apr 16, 2013 at 11:11 AM, Anuj Phogat anuj.pho...@gmail.com wrote:
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 3 +++
1 file changed, 3 insertions(+)
diff
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On Tue, Apr 16, 2013 at 1:37 PM, Paul Berry stereotype...@gmail.com wrote:
Fixes issue identified by Klocwork analysis:
'attribute_map' array elements might be used uninitialized in this
function
- Original Message -
Those are just ideas. I'm open to discussion.
The driver is disabled by default and needs to be enabled via
--with-gallium-drivers=i965.
I think a warning + maybe something like
--with-gallium-drivers=i965g-unofficial might work,
If not, then I'd
From: Tom Stellard thomas.stell...@amd.com
The LLVM C API is considered stable and should never change, so it
is much more desirable to use than the LLVM C++ API, which is constantly in
flux.
---
src/gallium/drivers/radeon/Makefile.am | 2 -
src/gallium/drivers/radeon/Makefile.sources
Improves GLB2.7 performance 0.13% +/- 0.09% (n=104/105, outliers removed).
More importantly, once color glClear()s are done through blorp in the next
commit, this reduces regression in GLES3 conformance tests that rely on
queueing up many glClear()s and having the GPU report being still busy in
an
The upside is less CPU overhead in fiddling with GL error handling, the
ability to use the constant color write message in most cases, and no GLSL
clear shaders appearing in MESA_GLSL=dump output. The downside is more
batch flushing and a total recompute of GL state at the end of blorp.
However,
On Tue, Apr 16, 2013 at 4:13 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
Topi Pohjolainen topi.pohjolai...@intel.com writes:
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
Topi Pohjolainen topi.pohjolai...@intel.com writes:
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 101
+-
1 file changed, 71 insertions(+), 30 deletions(-)
diff --git
On Tue, Apr 16, 2013 at 9:58 PM, Chia-I Wu olva...@gmail.com wrote:
On Wed, Apr 17, 2013 at 12:58 AM, Matt Turner matts...@gmail.com wrote:
I think everything Marek said was correct. If you could extend Gallium
to consume GLSL IR it might actually be an interesting project.
Yes, it is. I
---
src/mesa/main/texformat.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
index 6f22a4f..ecf8fec 100644
--- a/src/mesa/main/texformat.c
+++ b/src/mesa/main/texformat.c
@@ -142,6 +142,7 @@ _mesa_choose_tex_format(struct
Two Mesa patches that might be generally interesting, then I proceed to
slowly update the texture formats mappings in i965.
One of the original goals was to remove the alpha-channel forcing code in
our sampler state, but I couldn't quite find enough supported formats to
do so.
The code can be
This should already be handled by _mesa_base_tex_format() calls in
TexImage*.
---
NOTE!
I've replaced the actual patch full of unindentation of code described by:
src/mesa/main/texformat.c | 1184 -
1 file changed, 533 insertions(+), 651 deletions(-)
---
src/mesa/drivers/dri/i965/brw_defines.h | 45 +++
1 file changed, 45 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 38f0356..7b01c75e 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++
It was all over the formats section I wanted to edit.
---
src/mesa/drivers/dri/i965/brw_defines.h | 288 +++
1 file changed, 144 insertions(+), 144 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 94e712e..c1e3b14 100644
---
This is a step on the way to removing some of our code for forcing alpha
to 1, but I want easy bisecting so I'll add groups of formats separately.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
Unfortunately the surface formats table is now splattered across multiple
chapters. All surface format enums from brw_defines.h are present, but
only support for them that is mentioned in the public specs is included
here.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 65
I'm not filling them all in, to prevent any breakage in this commit.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 32 +-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
The next commit introduces what is apparently our first one, which tripped
over this in glReadPixels.
---
src/mesa/drivers/dri/intel/intel_blit.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_blit.c
Previously we would expand it to RGBA_FLOAT16. This format now comes out
as framebuffer incomplete, but it seems worth the memory savings if that's
what people are asking for (and GL3 does list it under texture-only
color formats)
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |2 +-
1
This should have no change on driver operation, but it means that when you
wonder why some format isn't supported natively, you can just look at the
table above, instead of wondering if maybe there's an appropriate entry in
the surface formats table that is already supported.
---
From: Dave Airlie airl...@redhat.com
the max version check was using the default cache, not reading
from drirc, which kinda made it hard to force enable it in drirc land.
So temporarily parse the dri config files and throw away the results.
Signed-off-by: Dave Airlie airl...@redhat.com
---
From: Dave Airlie airl...@redhat.com
For some reason I made this happen under indirect rendering,
I think we might have a leak, valgrind gave out, so I said I'd
fix the basic problem.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/glsl/ralloc.c |2 ++
1 files changed, 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 --
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
---
---
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 |
For the i915 driver, make it a local macro.
v2: use conditional operator instead of bit shifting
---
src/mesa/drivers/dri/i915/intel_tris.c |4 +++-
src/mesa/main/debug.c |3 +--
src/mesa/main/enable.c |1 -
src/mesa/main/mtypes.h |
For the i915 driver, make it a local macro.
v2: use conditional operator instead of bit shifting
---
src/mesa/drivers/dri/i915/intel_tris.c |4 +++-
src/mesa/main/debug.c |5 ++---
src/mesa/main/mtypes.h |1 -
src/mesa/main/points.c |
---
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 |
Make it a local macro for the i915 driver.
v2: use conditional operator instead of bit shifting
---
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 -
Make it a local macro for the i915 driver.
v2: use conditional operator instead of bit shifting
---
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
---
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
---
Use alternate code in intel, r200, radeon drivers.
v2: use conditional operator instead of bit shifting
---
src/mesa/drivers/dri/i915/intel_tris.c |4 +++-
src/mesa/drivers/dri/r200/r200_state.c |5 +++--
src/mesa/drivers/dri/r200/r200_swtcl.c | 14 +++---
v2: use conditional operator instead of bit shifting
---
src/mesa/drivers/dri/i915/intel_tris.c |3 +++
src/mesa/drivers/dri/r200/r200_swtcl.c | 12 +++-
src/mesa/drivers/dri/radeon/radeon_swtcl.c | 11 +++
src/mesa/main/debug.c | 12
No longer used 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
On 04/16/2013 06:08 PM, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
For some reason I made this happen under indirect rendering,
I think we might have a leak, valgrind gave out, so I said I'd
fix the basic problem.
Signed-off-by: Dave Airlie airl...@redhat.com
---
Can happen if we were using stream output without geometry
shader, by returning early we avoid a crash.
---
src/gallium/auxiliary/draw/draw_gs.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/auxiliary/draw/draw_gs.c
b/src/gallium/auxiliary/draw/draw_gs.c
index
The specification says that the geometry shader should exit if the
number of emitted vertices is bigger or equal to max_output_vertices and
we can't do that because we're running in the SoA mode, which means that
our storing routines will keep getting called on channels that have
overflown (even
89 matches
Mail list logo
