On 04/10/2013 02:51 PM, Michel Dänzer wrote:
On Mit, 2013-04-10 at 12:59 +0200, Christian König wrote:
Am 10.04.2013 12:21, schrieb Michel Dänzer:
On Mit, 2013-04-10 at 12:07 +0200, Christian König wrote:
Am 10.04.2013 11:46, schrieb Michel Dänzer:
But why the heck is multiplying with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I am not using GLES, but normal OpenGL through EGL. And I am
pretty sure it's double-buffered - as far as I understood it,
that's the default, and I did not attempt to override it in any
way (like calling glDrawBuffer).
Oh, our EGL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
OK, the presence of glDrawBuffer(GL_FRONT) in the linked code plus
the glFinish()/glFlush()es made it look like you were.
I did some experimenting with manual copying... also, the code will
clearly show that I am very inexperienced at GL ;-)
On Apr 10, 2013, at 6:48 AM, Tobias Grosser tob...@grosser.es wrote:
On 04/10/2013 02:51 PM, Michel Dänzer wrote:
On Mit, 2013-04-10 at 12:59 +0200, Christian König wrote:
Am 10.04.2013 12:21, schrieb Michel Dänzer:
On Mit, 2013-04-10 at 12:07 +0200, Christian König wrote:
Am 10.04.2013
From: Eric Anholt e...@anholt.net
We are intentionally not allocating a slot for gl_ClipVertex. But by
leaving the bit set in the slots_valid, the fragment shader's computation
of where varyings are in urb entry coming out of the SF would be off by
one. Fixes rendering in Freespace 2 SCP, and
https://bugs.freedesktop.org/show_bug.cgi?id=44618
--- Comment #22 from Ilyes Gouta ilyes.go...@gmail.com ---
Hi,
(In reply to comment #20)
Created attachment 77156 [details] [review]
MesaLib-9.1.1-cross.patch
Suggested fix.
Has this fix landed?
Ilyes
--
You are receiving this mail
Hi guys,
this hopefully addresses the issues pointed out in previous reviews,
the main difference is the st/mesa max samples chooser is correct,
which Ian pointed out.
Also r600g sample positions are now valid, my last attempt missed
some unsigned/signed issues.
Dave.
From: Dave Airlie airl...@redhat.com
This allows us to reuse this for choosing formats for MSAA limits.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_format.c | 24 +++-
src/mesa/state_tracker/st_format.h | 5 +
2 files changed, 24
From: Dave Airlie airl...@redhat.com
This is to be used to implement glGet GL_SAMPLE_POSITION.
Reviewed-by: Marek Olšák mar...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/include/pipe/p_context.h | 13 +
1 file changed, 13 insertions(+)
diff --git
From: Dave Airlie airl...@redhat.com
This just calls into the gallium interface.
Reviewed-by: Marek Olšák mar...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/sources.mak| 1 +
src/mesa/state_tracker/st_cb_msaa.c | 54 +
From: Dave Airlie airl...@redhat.com
This adds support to the mesa state tracker for ARB_texture_multisample.
hardware doesn't seem to use a different texture instructions, so
I don't think we need to create one for TGSI at this time.
Thanks to Marek for fixes to sample number picking.
v2: idr
From: Dave Airlie airl...@redhat.com
v2: I rewrote this to use the sample positions properly.
v3: rewrite properly to use bitfield to cast back to signed ints
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/r600/evergreen_state.c | 287 ++---
https://bugs.freedesktop.org/show_bug.cgi?id=44618
--- Comment #23 from Matt Turner matts...@gmail.com ---
(In reply to comment #22)
Has this fix landed?
No. See comment 21.
--
You are receiving this mail because:
You are the assignee for the bug.
On Sat, 06 Apr 2013 08:52:35 -0600
Brian Paul bri...@vmware.com wrote:
One more comment for now below. I may not get to review the rest for
a few days.
-Brian
Thanks very much for the review. I redid properly my patch and rebase
my work on a more recent mesa version. I want to do a piglit
Am 10.04.2013 18:50, schrieb Tom Stellard:
On Wed, Apr 10, 2013 at 05:59:48PM +0200, Michel Dänzer wrote:
[SNIP]
We should start using the updated pattern syntax for all new patterns.
This means replacing register classes with types for the input patterns
and omitting the type in the output
This allows us to reuse this for choosing formats for MSAA limits.
Self-review, this one has a bug, I've changed in the branch
gallium-texture-multisample in my tree to take a problem boolean and
only report the problem in that case, as PIPE_FORMAT_NONE wasn't
always indicative of a problem.
---
src/gallium/drivers/r600/r600_pipe.c |1 +
src/gallium/drivers/r600/r600_pipe.h |1 +
src/gallium/drivers/r600/r600_query.c |9 +
src/gallium/winsys/radeon/drm/radeon_drm_bo.c |5 +
---
src/gallium/drivers/r600/r600_buffer.c |7 +++
src/gallium/drivers/r600/r600_pipe.c|1 +
src/gallium/drivers/r600/r600_pipe.h|1 +
src/gallium/drivers/r600/r600_texture.c |8
4 files changed, 17 insertions(+)
diff --git
---
src/gallium/drivers/r600/r600_pipe.c |2 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 27 -
src/gallium/winsys/radeon/drm/radeon_winsys.h | 10 ++--
3 files changed, 13 insertions(+), 26 deletions(-)
diff --git
---
src/gallium/drivers/r600/r600_pipe.c |2 +-
src/gallium/drivers/r600/r600_pipe.h |1 +
src/gallium/drivers/r600/r600_query.c | 95 +
src/gallium/drivers/r600/r600d.h |3 ++
4 files changed, 100 insertions(+), 1 deletion(-)
diff --git
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(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index
---
src/gallium/auxiliary/hud/hud_context.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 20115a5..4912b2a 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++
---
src/gallium/auxiliary/hud/hud_context.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 4912b2a..eb7a67a 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++
for the env var string not to be awfully long
v2: fix bug in indexing of name
---
src/gallium/auxiliary/hud/hud_context.c | 43 ---
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
---
src/gallium/auxiliary/hud/hud_fps.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/hud/hud_fps.c
b/src/gallium/auxiliary/hud/hud_fps.c
index 71cdfd0..80381f5 100644
--- a/src/gallium/auxiliary/hud/hud_fps.c
+++
Series looks good to me.
Jose
- Original Message -
which means that our execution mask in GS is equal to 1 not 0xf.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 30 +-
1 file changed, 17 insertions(+), 13
From: Christian König christian.koe...@amd.com
Separated from UVD patch for clarity.
v2: sync with next tree for 3.10
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c
Hopefully the last round for this patchset.
Since we now have a stable kernel interface I'm going to commit it this evening
if nobody objects.
Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On Thu, Apr 11, 2013 at 9:39 AM, Christian König
deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
Separated from UVD patch for clarity.
v2: sync with next tree for 3.10
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip
Signed-off-by: Christian
2013/4/11 Christian König deathsim...@vodafone.de
From: Christian König christian.koe...@amd.com
Separated from UVD patch for clarity.
v2: sync with next tree for 3.10
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip
Signed-off-by: Christian König
Am 11.04.2013 15:54, schrieb Andreas Boll:
2013/4/11 Christian König deathsim...@vodafone.de
From: Christian König christian.koe...@amd.com
Separated from UVD patch for clarity.
v2: sync with next tree for 3.10
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip
On Wed, Apr 10, 2013 at 11:04:21PM +0200, Vincent Lejeune wrote:
---
lib/Target/R600/MCTargetDesc/R600MCCodeEmitter.cpp | 15 +--
lib/Target/R600/R600Instructions.td| 8
2 files changed, 9 insertions(+), 14 deletions(-)
diff --git
On Wed, Apr 10, 2013 at 11:04:20PM +0200, Vincent Lejeune wrote:
---
Reviewed-by: Tom Stellard thomas.stell...@amd.com
lib/Target/R600/AMDGPUAsmPrinter.cpp | 35 +--
lib/Target/R600/AMDGPUAsmPrinter.h | 3 ++-
2 files changed, 35 insertions(+), 3
On Wed, Apr 10, 2013 at 11:04:22PM +0200, Vincent Lejeune wrote:
---
Could you add a comment explaining why export instructions are not
duplicable. With that change:
Reviewed-by: Tom Stellard thomas.stell...@amd.com
lib/Target/R600/R600Instructions.td | 2 +-
1 file changed, 1
On 04/11/2013 02:08 AM, Marek Olšák wrote:
Here's the output:
creating vs ...
shader compilation status: OK
creating fs ...
shader compilation status: OK
thread #0 (0;0) : ref = 16608
thread #1 (1;0) : ref = 27873
thread #2 (0;1) : ref = 16608
thread #3 (1;1) : ref = 27877
results:
thread 0
https://bugs.freedesktop.org/show_bug.cgi?id=63435
Priority: medium
Bug ID: 63435
Assignee: mesa-dev@lists.freedesktop.org
Summary: [Regression since 9.0] Flickering in EGL OpenGL
full-screen window with swap interval 1
As implemented in tgsi_exec they both test src operands on the bit
level and don't do floating point comperisons as some thought.
This documents them as such to avoid future confusion and fixes
their implementation in llvmpipe.
Could gallium driver developers make sure that they're handling
those
Am 11.04.2013 05:20, schrieb Zack Rusin:
As implemented in tgsi_exec they both test src operands on the bit
level and don't do floating point comperisons as some thought.
This documents them as such to avoid future confusion and fixes
their implementation in llvmpipe.
Could gallium driver
Am 11.04.2013 05:20, schrieb Zack Rusin:
As implemented in tgsi_exec they both test src operands on the bit
level and don't do floating point comperisons as some thought.
This documents them as such to avoid future confusion and fixes
their implementation in llvmpipe.
Could gallium driver
On 10 April 2013 14:33, Ian Romanick i...@freedesktop.org wrote:
On 04/10/2013 01:32 PM, Kenneth Graunke wrote:
On 04/09/2013 09:01 PM, Paul Berry wrote:
The comment above glsl_type::name claimed that it could sometimes be
NULL. This was wrong--it is never NULL. Many error handling paths
Am 11.04.2013 19:09, schrieb Zack Rusin:
- Original Message -
Am 11.04.2013 05:20, schrieb Zack Rusin:
As implemented in tgsi_exec they both test src operands on the bit
level and don't do floating point comperisons as some thought.
This documents them as such to avoid future
Also change if (shader) to if (prog) for consistency.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 12 +++-
src/mesa/drivers/dri/i965/brw_vec4.cpp |8 +---
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
---
src/mesa/drivers/dri/i965/brw_vec4.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 4f7b8c0..6a2ce35 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++
I got tired of freaking out a little every time I built my release tree
because of compile warnings. All but the last 2 seemed like pretty clean
fixes to me.
And then there's the first patch, which is unrelated but I found while
trying to figure out why register_coalesce() does something that
The call has no side effects, and moving it into the assert cleans up a
compile warning in the release build.
---
src/mesa/drivers/dri/i915/i830_vtbl.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c
We have this support for firsthalf/sechalf instructions, which would be
called in the !has_compr4 (aka original gen4) 16-wide case. We currently
only support 16-wide for gen5+, so we weren't tripping over this, but it
would have been a problem if we ever try to enable it.
---
This fixes unused variable warnings in the release build, and should be
more useful if it ever triggers.
---
src/mesa/drivers/dri/intel/intel_blit.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_blit.c
Asserts don't stop execution in release builds, so we would continue on to
use an uninitialized format value. Just take the failure path, which
appears to continue up the call stack for a while.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |2 +-
1 file changed, 1 insertion(+), 1
We assert that failure doesn't happen, but it fixes a warning in the
release build and it would at least give working behavior for a user by
falling back to the normal texsubimage path.
---
src/mesa/drivers/dri/intel/intel_tex_subimage.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
I don't see a sensible value to use in this path, but we shouldn't ever
hit this outside of developer new-texture-target enabling.
---
src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp |1 +
1 file changed, 1 insertion(+)
diff --git
I think this actually clarifies what's going on in the asserts a bit,
given how many regions we've got floating around.
---
src/mesa/drivers/dri/i965/brw_misc_state.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
It's used in an assert, but we have this as a member of the class anyway.
---
src/mesa/drivers/dri/i965/brw_fs.cpp |1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 88aa695..c945617 100644
---
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 772c393..f9768df 100644
---
This was copy and pasted from can_reswizzle_dst(), and we can just fold it
in instead to avoid the warning.
---
src/mesa/drivers/dri/i965/brw_vec4.cpp |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
We don't want to store this thing in the class, and we do need the
definition to be at the top of the function and held onto until the end
here, so there's not much to do besides (void) reference it.
---
src/mesa/drivers/dri/i965/brw_fs.cpp |1 +
1 file changed, 1 insertion(+)
diff --git
On Thu, Apr 11, 2013 at 11:06 AM, Eric Anholt e...@anholt.net wrote:
I got tired of freaking out a little every time I built my release tree
because of compile warnings. All but the last 2 seemed like pretty clean
fixes to me.
And then there's the first patch, which is unrelated but I found
What about drivers without integer support? The IF instruction should have
2 definitions: one for the drivers which support PIPE_SHADER_CAP_INTEGERS,
and the other one for those which don't. Obviously, there is no way to
change the behavior of the IF opcode if you only have floats.
Marek
On
Everything emitting those opcodes always assumed this is some sort of
boolean until now, so treating them as floats always was sketchy. Note
that the differences to treating them as uints or floats for comparisons
to zero isn't large, it's the same for everything except -0.0 and NaNs,
and I
What about drivers without integer support? The IF instruction should have 2
definitions: one for the drivers which support PIPE_SHADER_CAP_INTEGERS, and
the other one for those which don't. Obviously, there is no way to change
the behavior of the IF opcode if you only have floats.
I think in
Ah.. This indeed rings a bell. I don't recall the details but I'm pretty sure I
was against dual semantics. And the fact that this problem is again showing its
ugly head is the proof of it.
We really should have two IF opcodes. And the state tracker should choose which
one it wants.
Jose
SM3 hardware does have NaNs. Anyway, I'd like to have this SM3-specific
behavior of TGSI_OPCODE_IF properly documented. We already generate
different TGSI code for SM3 and SM4+ and there'll be much more differences
in how things are done in the future (e.g. temporaries could be used in
place of
- Original Message -
Ah.. This indeed rings a bell. I don't recall the details but I'm pretty sure
I was against dual semantics. And the fact that this problem is again
showing its ugly head is the proof of it.
We really should have two IF opcodes. And the state tracker should choose
- Original Message -
- Original Message -
Ah.. This indeed rings a bell. I don't recall the details but I'm pretty
sure
I was against dual semantics. And the fact that this problem is again
showing its ugly head is the proof of it.
We really should have two IF
- Original Message -
- Original Message -
Ah.. This indeed rings a bell. I don't recall the details but I'm pretty
sure
I was against dual semantics. And the fact that this problem is again
showing its ugly head is the proof of it.
We really should have two IF
Actually our svga driver seems to think that the IF opcode works like
that. Since it will translate it into a SVGA3DOP_IFC (which corresponds
to shader model 2 if_comp which compares to sources and specifies a
comparison function - my guess is this is what the unused
TGSI_OPCODE_IFC was meant for,
Matt Turner matts...@gmail.com writes:
Also change if (shader) to if (prog) for consistency.
If the _mesa_problem is pulled out of the if (prog) in both patches
(since it doesn't rely on the program, and you'd want to know), then:
Reviewed-by: Eric Anholt e...@anholt.net
pgpDwZqCAcTWE.pgp
This provides an interface for applications (and OpenGL-based tools) to
access GPU performance counters. Since the exact performance counters
available vary between vendors and hardware generations, the extension
provides an API the application can use to get the names, types, and
minimum/maximum
Ironlake's counters are always enabled; userspace can simply send a
MI_REPROT_PERF_COUNT packet to take a snapshot of them. This makes it
easy to implement.
The counters are documented in the source code for the intel-gpu-tools
intel_perf_counters utility.
Signed-off-by: Kenneth Graunke
- Original Message -
- Original Message -
- Original Message -
Ah.. This indeed rings a bell. I don't recall the details but I'm
pretty
sure
I was against dual semantics. And the fact that this problem is again
showing its ugly head is the proof
https://bugs.freedesktop.org/show_bug.cgi?id=63435
--- Comment #1 from post+...@ralfj.de ---
I totally forgot my software and hardware specs:
I am using Debian testing with a self-compiled vanilla 3.8.5 kernel. Other than
that, I use the distribution packages. My GPU is the one built-in my Core
Am 11.04.2013 22:52, schrieb Zack Rusin:
- Original Message -
- Original Message -
Ah.. This indeed rings a bell. I don't recall the details but I'm pretty
sure
I was against dual semantics. And the fact that this problem is again
showing its ugly head is the proof of it.
On Thu, Apr 11, 2013 at 2:00 PM, Kenneth Graunke kenn...@whitecape.org wrote:
This provides an interface for applications (and OpenGL-based tools) to
access GPU performance counters. Since the exact performance counters
available vary between vendors and hardware generations, the extension
As suggested by Jose, here is a short patchset that handles the
initial stage of beating some structure into the docs directory
* All the release notes (both text and html) have been moved to
relnotes/, with filenames indicating the version only
* Mesa/WL extensions have been moved to specs/,
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
docs/relnotes.html | 3 +++
1 file changed, 3 insertions(+)
diff --git a/docs/relnotes.html b/docs/relnotes.html
index 049a979..819d2ce 100644
--- a/docs/relnotes.html
+++ b/docs/relnotes.html
@@ -22,6 +22,7 @@ The release notes summarize
Add a note to update PACKAGE_VERSION for Android and scons builds
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
docs/devinfo.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/docs/devinfo.html b/docs/devinfo.html
index 5c03344..7176824 100644
--- a/docs/devinfo.html
+++
Here is a short patchset that handles most of the compile warnings for my
gallium/nouveau 'release' build.
The commit messages may be rather silly but I was running out of ideas
what to put :)
Anyway the first five patches are nv50,nvc0 related, whereas the last one
changes a egl/wayland
As otherwise it is unused - pointed out by gcc
nve4_compute.c:586:20: warning: 'nve4_cache_split_name' defined but not used
[-Wunused-function]
static const char *nve4_cache_split_name(unsigned value)
^
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Exit gracefully rather than trying to create a random object, whenever the
chipset is unknown
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/drivers/nvc0/nve4_compute.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Pointed out by gcc
nve4_compute.c: In function 'nve4_launch_grid':
nve4_compute.c:511:7: warning: 'ret' may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (ret)
^
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/drivers/nvc0/nve4_compute.c | 2
Remove extra chipset check during nvc0_screen_create
Set the class_3d after the object is created
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/drivers/nv50/nv50_screen.c | 2 +-
src/gallium/drivers/nvc0/nvc0_screen.c | 12 +---
2 files changed, 2 insertions(+),
Change egl_g3d_wl_drm_common_query_buffer() to use boolean/int rather than
EGLBoolean/EGLint, based on the interface in native_wayland_bufmgr.h,
Resolves type conversion warnings spotted by gcc
x11/native_dri2.c:892:1: warning: initialization from incompatible pointer
type[enabled by default]
For the sake of consistency.
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com
---
src/glx/apple/Makefile | 2 +-
src/mapi/glapi/Makefile.am | 4 +-
src/mapi/glapi/Makefile.sources | 19 ++
A step toward working make dist/distcheck.
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com
---
configure.ac | 37 -
src/Makefile.am | 30 +++---
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com
---
Since last time:
- Stop building src/glx for xlib-glx, as noticed out by Eric and Andreas.
(Relies on the fact that $enable_dri and $enable_xlib_glx are mutually
It's always constant anyway.
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com
---
configure.ac| 4
src/Makefile.am | 4 +++-
src/gallium/Makefile.am | 22 --
3 files changed, 3
Neither are used in Makefile.ams.
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com
---
configure.ac | 2 --
1 file changed, 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 299007d..9eec334 100644
--- a/configure.ac
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com
---
configure.ac | 9 ++---
src/mesa/Makefile.am | 14 +-
src/mesa/drivers/Makefile.am | 22 --
3 files changed, 15
configure still uses it to print the enabled state trackers.
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com
---
configure.ac | 45 +++
src/gallium/state_trackers/Makefile.am | 65
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com
---
Since last time:
- Rebase and add freedreno.
configure.ac| 31 +++
src/gallium/drivers/Makefile.am | 84
And don't build it from other Makefiles. That's awful, and breaks
distclean.
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com
---
configure.ac | 8
src/gallium/targets/opencl/Makefile.am | 3 ---
configure still uses it to print the enabled targets.
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com
---
Since last time:
- Rebase and add freedreno.
configure.ac| 2 +-
src/gallium/targets/Makefile.am |
configure still uses it to print the enabled winsys.
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-and-Tested-by: Andreas Boll andreas.boll@gmail.com
---
Since last time:
- Rebase and add freedreno.
configure.ac | 38 +-
This is a basic implementation of the pipeline statistics in the
draw module. The interface is similar to the stream output statistics
and also requires that the callers explicitly enable it.
Included is the implementation of the interface in llvmpipe and
softpipe. Only softpipe enables the
The issue with SOA execution and end_primitive opcode is that it
can be executed both when we haven't emitted any vertices, in
which case we don't want to emit an empty primitive, and when
the execution mask is zero and the execution should be skipped. We
handled only the latter of those
94 matches
Mail list logo
