[Mesa-dev] [Bug 45913] [r300g] piglit vs-clip-vertex-const-reject fails
https://bugs.freedesktop.org/show_bug.cgi?id=45913 Pavel Ondračka pavel.ondra...@email.cz changed: What|Removed |Added Priority|medium |low AssignedTo|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Summary|[bisected] piglit |[r300g] piglit |vs-clip-vertex-const-reject |vs-clip-vertex-const-reject |fails |fails Component|Mesa core |Drivers/Gallium/r300 --- Comment #2 from Pavel Ondračka pavel.ondra...@email.cz 2012-02-11 00:24:49 PST --- OK, reassigning to r300g per commment 1. Also lowering importance. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Emit Ivybridge VS workaround flushes.
On 02/10/2012 09:25 PM, Kenneth Graunke wrote:
I recently discovered this text in the BSpec. It seems wise to comply,
though I haven't observed it to fix anything yet.
Fixes a regression in glean/fbo since 28cfa1fa213fe.
Eh... how do you know it fixes the regression if you haven't observed it
yet? :p
NOTE: This is a candidate for stable release branches.
Cc: Eric Anholte...@anholt.net
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45221
Signed-off-by: Kenneth Graunkekenn...@whitecape.org
---
src/mesa/drivers/dri/i965/gen7_urb.c |2 +
src/mesa/drivers/dri/i965/gen7_vs_state.c |2 +
src/mesa/drivers/dri/intel/intel_batchbuffer.c | 26 ++-
src/mesa/drivers/dri/intel/intel_batchbuffer.h |1 +
4 files changed, 29 insertions(+), 2 deletions(-)
This also obsoletes Eric's uncommitted patch
i965/gen7: Always allocate push constant space before uploading.
as it fixes the same problem without such a large performance hit.
My theory is that since 3DSTATE_PUSH_CONSTANT_ALLOC_VS is a non-pipelined
command, emitting it at the top of upload_vs_state effectively served the
same purpose (only a much harsher flush).
diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c
b/src/mesa/drivers/dri/i965/gen7_urb.c
index e6cf1eb..920c9fc 100644
--- a/src/mesa/drivers/dri/i965/gen7_urb.c
+++ b/src/mesa/drivers/dri/i965/gen7_urb.c
@@ -99,6 +99,8 @@ gen7_upload_urb(struct brw_context *brw)
/* GS requirement */
assert(!brw-gs.prog_active);
+ gen7_emit_vs_workaround_flush(intel);
+
BEGIN_BATCH(2);
OUT_BATCH(_3DSTATE_URB_VS 16 | (2 - 2));
OUT_BATCH(brw-urb.nr_vs_entries |
diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c
b/src/mesa/drivers/dri/i965/gen7_vs_state.c
index 0746e6c..a3d652c 100644
--- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
@@ -35,6 +35,8 @@ upload_vs_state(struct brw_context *brw)
struct intel_context *intel =brw-intel;
uint32_t floating_point_mode = 0;
+ gen7_emit_vs_workaround_flush(intel);
+
BEGIN_BATCH(2);
OUT_BATCH(_3DSTATE_BINDING_TABLE_POINTERS_VS 16 | (2 - 2));
OUT_BATCH(brw-bind.bo_offset);
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index c58dee8..d10e008 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -56,13 +56,13 @@ intel_batchbuffer_init(struct intel_context *intel)
{
intel_batchbuffer_reset(intel);
- if (intel-gen == 6) {
+ if (intel-gen= 6) {
/* We can't just use brw_state_batch to get a chunk of space for
* the gen6 workaround because it involves actually writing to
* the buffer, and the kernel doesn't let us write to the batch.
*/
intel-batch.workaround_bo = drm_intel_bo_alloc(intel-bufmgr,
- gen6 workaround,
+ pipe_control workaround,
4096, 4096);
}
}
@@ -394,6 +394,28 @@ intel_emit_depth_stall_flushes(struct intel_context *intel)
}
/**
+ * From the BSpec, volume 2a.03: VS Stage Input / State:
+ * [DevIVB] A PIPE_CONTROL with Post-Sync Operation set to 1h and a depth
+ * stall needs to be sent just prior to any 3DSTATE_VS, 3DSTATE_URB_VS,
+ * 3DSTATE_CONSTANT_VS, 3DSTATE_BINDING_TABLE_POINTER_VS,
+ * 3DSTATE_SAMPLER_STATE_POINTER_VS command. Only one PIPE_CONTROL needs
+ * to be sent before any combination of VS associated 3DSTATE.
+ */
+void
+gen7_emit_vs_workaround_flush(struct intel_context *intel)
+{
+ assert(intel-gen == 7);
+
+ BEGIN_BATCH(4);
+ OUT_BATCH(_3DSTATE_PIPE_CONTROL);
+ OUT_BATCH(PIPE_CONTROL_DEPTH_STALL | PIPE_CONTROL_WRITE_IMMEDIATE);
+ OUT_RELOC(intel-batch.workaround_bo,
+I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION, 0);
+ OUT_BATCH(0); /* write data */
+ ADVANCE_BATCH();
+}
+
+/**
* Emits a PIPE_CONTROL with a non-zero post-sync operation, for
* implementing two workarounds on gen6. From section 1.4.7.1
* PIPE_CONTROL of the Sandy Bridge PRM volume 2 part 1:
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.h
b/src/mesa/drivers/dri/intel/intel_batchbuffer.h
index e5e5bd4..751ec99 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.h
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.h
@@ -43,6 +43,7 @@ bool intel_batchbuffer_emit_reloc_fenced(struct intel_context
*intel,
void intel_batchbuffer_emit_mi_flush(struct intel_context *intel);
void intel_emit_post_sync_nonzero_flush(struct intel_context *intel);
void intel_emit_depth_stall_flushes(struct intel_context *intel);
+void gen7_emit_vs_workaround_flush(struct intel_context *intel);
static INLINE uint32_t float_as_int(float f)
{
___
mesa-dev mailing list
Re: [Mesa-dev] [PATCH] i965: Emit Ivybridge VS workaround flushes.
On 02/11/2012 12:31 AM, Ian Romanick wrote: On 02/10/2012 09:25 PM, Kenneth Graunke wrote: I recently discovered this text in the BSpec. It seems wise to comply, though I haven't observed it to fix anything yet. Fixes a regression in glean/fbo since 28cfa1fa213fe. Eh... how do you know it fixes the regression if you haven't observed it yet? :p lol. I had the patch lying around for a while, and apparently forgot to take out the this doesn't fix anything comment when I added the it fixes stuff! comment. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45920] New: Exception: Attempt to use unavailable module DRM:
https://bugs.freedesktop.org/show_bug.cgi?id=45920
Bug #: 45920
Summary: Exception: Attempt to use unavailable module DRM:
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: blocker
Priority: medium
Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: v...@freedesktop.org
CC: jfons...@vmware.com
mesa: d5a6c172547d8964f4d4bb79637651decaf9deee (master)
$ lsb_release -a
No LSB modules are available.
Distributor ID:Ubuntu
Description:Ubuntu 10.04.3 LTS
Release:10.04
Codename:lucid
$ scons -h
scons: Reading SConscript files ...
scons: Found LLVM version 2.7
Checking for X11 (x11 xext xdamage xfixes)... yes
Checking for XCB (x11-xcb xcb-glx)... yes
Checking for XF86VIDMODE (xxf86vm)... yes
Checking for DRM (libdrm = 2.4.24)... no
Checking for DRM_INTEL (libdrm_intel = 2.4.30)... no
Checking for DRM_RADEON (libdrm_radeon = 2.4.31)... no
Checking for XORG (xorg-server = 1.6.0)... yes
Checking for KMS (libkms = 2.4.24)... no
Checking for UDEV (libudev 150)... yes
Exception: Attempt to use unavailable module DRM:
File /home/vlee/mesa/SConstruct, line 144:
duplicate = 0 # http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
File /usr/lib/scons/SCons/Script/SConscript.py, line 616:
return apply(method, args, kw)
File /usr/lib/scons/SCons/Script/SConscript.py, line 553:
return apply(_SConscript, [self.fs,] + files, subst_kw)
File /usr/lib/scons/SCons/Script/SConscript.py, line 262:
exec _file_ in call_stack[-1].globals
File /home/vlee/mesa/src/SConscript, line 26:
SConscript('glx/SConscript')
File /usr/lib/scons/SCons/Script/SConscript.py, line 616:
return apply(method, args, kw)
File /usr/lib/scons/SCons/Script/SConscript.py, line 553:
return apply(_SConscript, [self.fs,] + files, subst_kw)
File /usr/lib/scons/SCons/Script/SConscript.py, line 262:
exec _file_ in call_stack[-1].globals
File /home/vlee/mesa/src/glx/SConscript, line 28:
env.PkgUseModules('DRM')
File /usr/lib/scons/SCons/Environment.py, line 221:
return apply(self.method, nargs, kwargs)
File /home/vlee/mesa/scons/custom.py, line 217:
raise Exception('Attempt to use unavailable module %s' % name)
2470e918cc29e5d057a28551ce9c15e7d83fab7e is the first bad commit
commit 2470e918cc29e5d057a28551ce9c15e7d83fab7e
Author: José Fonseca jfons...@vmware.com
Date: Tue Feb 7 11:17:35 2012 +
scons: Require same pkg-config versions as configure.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] 8.0 Release of GLw?
Hi, There are a few scientific software packages that require Mesa's GLw, and with 8.0 we've split GLw out into a separate repository. Can we do an 8.0 release of GLw? It passes distcheck for me. (I guess when Kenneth splits GLU out we should have the same discussion) Thanks, Matt [1] https://bugs.gentoo.org/show_bug.cgi?id=403147 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Enable GLX_USE_TLS if possible.
On Wed, Feb 8, 2012 at 5:11 PM, Zhigang Gong
zhigang.g...@linux.intel.com wrote:
On Wed, Feb 08, 2012 at 02:46:42PM -0800, Eric Anholt wrote:
On Wed, 8 Feb 2012 16:19:38 +0800, zhigang.g...@linux.intel.com wrote:
From: Zhigang Gong zhigang.g...@linux.intel.com
If the system support tls, we prefer to enable it by default
just as xserver does. Actually, the checking code is copied
from xserver/configure.ac.
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
configure.ac | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index b2b1ab8..7c2756b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1103,8 +1103,14 @@ dnl
AC_ARG_ENABLE([glx-tls],
[AS_HELP_STRING([--enable-glx-tls],
[enable TLS support in GLX @:@default=disabled@:@])],
-[GLX_USE_TLS=$enableval],
-[GLX_USE_TLS=no])
+[GLX_USE_TLS=$enableval
+ if test x$GLX_USE_TLS = xyes test ${ac_cv_tls} = none ;
then
+AC_MSG_ERROR([GLX with TLS support requested, but the compiler
does not support it.])
+ fi],
+[GLX_USE_TLS=no
+ if test ${ac_cv_tls} != none ; then
+GLX_USE_TLS=yes
+ fi])
AC_SUBST(GLX_TLS, ${GLX_USE_TLS})
I don't think you have anything setting ac_cv_tls.
You are right, I forgot to add the checking code which is also from xserver.
Sorry for that, here is the v2 patch:
From: Zhigang Gong zhigang.g...@linux.intel.com
Date: Wed, 8 Feb 2012 16:12:42 +0800
Subject: [PATCH v2] configure.ac: Enable GLX_USE_TLS if possible.
If the system support tls, we prefer to enable it by default
just as xserver does. Actually, the checking code is copied
from xserver/configure.ac.
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
configure.ac | 39 +--
1 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index b2b1ab8..3dfafba 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1099,12 +1099,47 @@ esac
dnl
dnl TLS detection
dnl
+AC_MSG_CHECKING(for thread local storage (TLS) support)
+AC_CACHE_VAL(ac_cv_tls, [
+ac_cv_tls=none
+keywords=__thread __declspec(thread)
+for kw in $keywords ; do
+AC_TRY_COMPILE([int $kw test;], [], ac_cv_tls=$kw)
+done
+])
+AC_MSG_RESULT($ac_cv_tls)
+
+if test $ac_cv_tls != none; then
+AC_MSG_CHECKING(for tls_model attribute support)
+AC_CACHE_VAL(ac_cv_tls_model, [
+save_CFLAGS=$CFLAGS
+CFLAGS=$CFLAGS $STRICT_CFLAGS
+AC_TRY_COMPILE([int $ac_cv_tls
__attribute__((tls_model(initial-exec))) test;], [],
+ ac_cv_tls_model=yes, ac_cv_tls_model=no)
+CFLAGS=$save_CFLAGS
+])
+AC_MSG_RESULT($ac_cv_tls_model)
+
+if test x$ac_cv_tls_model = xyes ; then
+mesa_tls=$ac_cv_tls' __attribute__((tls_model(initial-exec)))'
+else
+mesa_tls=$ac_cv_tls
+fi
+
+AC_DEFINE_UNQUOTED([TLS], $mesa_tls, [The compiler supported TLS storage
class, prefering initial-exec if tls_model is supported])
+fi
Can you put this code in acinclude.m4 and call it MESA_TLS or
something? There's a couple minor issues with copying this straight
from the xserver.
1. STRICT_FLAGS isn't set anywhere. This would come from
XORG_STRICT_OPTION, but I don't think we should pull that in here. I
think you can just drop the save_CFLAGS dance and just call
AC_TRY_COMPILE straight off. The main thing we're losing is possibly
having -Werror set during the run, but then you have to figure out if
that's OK to set or not. Seems easier to just see if the compiler will
bomb with whatever flags are set at the time.
2. Also, the AC_DEFINE_UNQUOTED is not needed since mesa doesn't use
config.h. If you want -DTLS in the code, I think you should add that
to DEFINES. Or make a new variable TLS_FLAGS and add it to CFLAGS in
configs/autoconf.in. Look at how PIC_FLAGS is used if you want this.
Probably this line should just be removed, though, since configure.ac
is already setting -DGLX_USE_TLS and that's used in the code.
AC_ARG_ENABLE([glx-tls],
[AS_HELP_STRING([--enable-glx-tls],
[enable TLS support in GLX @:@default=disabled@:@])],
You should change this to default:auto since the default case is
turning on TLS when the compiler says we have it.
-[GLX_USE_TLS=$enableval],
-[GLX_USE_TLS=no])
+[GLX_USE_TLS=$enableval
+ if test x$GLX_USE_TLS = xyes test ${ac_cv_tls} = none ; then
+AC_MSG_ERROR([GLX with TLS support requested, but the compiler does
not support it.])
+ fi],
+[GLX_USE_TLS=no
+ if test ${ac_cv_tls} != none ; then
+GLX_USE_TLS=yes
+ fi])
AC_SUBST(GLX_TLS, ${GLX_USE_TLS})
AS_IF([test x$GLX_USE_TLS = xyes],
The rest looks good. With those couple fixes,
Reviewed-by: Dan Nicholson dbn.li...@gmail.com
___
mesa-dev
Re: [Mesa-dev] [PATCH 4/4] configure.ac: remove shared/static options
On Fri, Jan 20, 2012 at 12:57 PM, Matt Turner matts...@gmail.com wrote: On Sat, Jan 14, 2012 at 11:16 AM, Matt Turner matts...@gmail.com wrote: now that libtool provides them. Signed-off-by: Matt Turner matts...@gmail.com --- Ping. This is sensible, right? Sorry, I missed this. I _think_ so. I'm kind of wary of relying on a bolted on libtool rather than a fully integrated libtool, but I think for the purpose of these variables it should be fine. Did you actually check that LT_INIT sets enable_shared and enable_static like we're using here? I'm pretty sure it does, but I'd appreciate if you could take a look. If that's the case, Reviewed-by: Dan Nicholson dbn.li...@gmail.com -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45932] New: Fails to compile with OpenGL ES support
https://bugs.freedesktop.org/show_bug.cgi?id=45932 Bug #: 45932 Summary: Fails to compile with OpenGL ES support Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: kyledeva...@gmail.com Created attachment 56898 -- https://bugs.freedesktop.org/attachment.cgi?id=56898 Output of make I'm trying to test Wayland/Weston, however Mesa is not being compiled with OpenGL ES support. Sometimes I am able to change various build flags around and Mesa will compile, however a similar error will then happen when starting Weston. I've followed the build instructions at http://wayland.freedesktop.org/building.html . Note that I am using an Intel GMA3150. Even though the attached log indicates the problem in the r300 drivers, the same will happen with Intel only sometimes it will compile and then fail to resolve the same symbols at runtime. I've tried disabling gallium altogether and only building drm for intel with similar results. Also affects Mesa 8.0. Ubuntu 11.10. Kernel 3.0.0-15-generic. DRM: git 2cfac57d364d0166ed9472b086c16aea376f495a drm config: ./autogen.sh --prefix=$WLD --enable-nouveau-experimental-api mesa config: ./autogen.sh --prefix=/home/test/install --enable-gles2 --with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi --disable-gallium-egl --with-dri-drivers=i915 The recurring theme here seems to be this: undefined reference to `_mesa_create_exec_table_es2' -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] configure.ac: remove shared/static options
On Sat, Feb 11, 2012 at 4:56 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Fri, Jan 20, 2012 at 12:57 PM, Matt Turner matts...@gmail.com wrote: On Sat, Jan 14, 2012 at 11:16 AM, Matt Turner matts...@gmail.com wrote: now that libtool provides them. Signed-off-by: Matt Turner matts...@gmail.com --- Ping. This is sensible, right? Sorry, I missed this. I _think_ so. I'm kind of wary of relying on a bolted on libtool rather than a fully integrated libtool, but I think for the purpose of these variables it should be fine. Did you actually check that LT_INIT sets enable_shared and enable_static like we're using here? I'm pretty sure it does, but I'd appreciate if you could take a look. If that's the case, Reviewed-by: Dan Nicholson dbn.li...@gmail.com -- Dan Yes, it does. --enable-static/--enable-shared (provided by libtool now) still works. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 8.0 Release of GLw?
On 02/11/2012 07:58 AM, Matt Turner wrote: Hi, There are a few scientific software packages that require Mesa's GLw, and with 8.0 we've split GLw out into a separate repository. Can we do an 8.0 release of GLw? It passes distcheck for me. (I guess when Kenneth splits GLU out we should have the same discussion) Thanks, Matt [1] https://bugs.gentoo.org/show_bug.cgi?id=403147 Sounds good to me, I just don't know what the procedure is. Also, right now the GLw version is set to 1.0.0. I don't know if that'll cause problems. Feel free to bump it... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/gen6: In HiZ op, emit valid pointers in 3DSTATE_CC_STATE_POINTERS
On 02/10/2012 10:54 AM, Chad Versace wrote:
Before this patch, the HiZ op was setting the pointers to COLOR_CALC_STATE
and to BLEND_STATE to 0. This was probably safe, since the HiZ op doesn't
use the cc or the blending. And it caused no problems with Piglit and
Citybench.
But, we don't know exactly what the GPU does with those pointers. So, to
be really safe, this patches replaces the 0's with valid pointers.
There is no need to do the analogous change for gen7 because a separate
packet is emitted for each of DEPTH_STENCIL_STATE, COLOR_CALC_STATE, and
BLEND_STATE. In gen7_hiz_exec, we emit only
3DSTATE_DEPTH_STENCIL_STATE_POINTERS.
Actually, this is inconsistent. If you don't send
3DSTATE_CC_STATE_POINTERS and 3DSTATE_BLEND_STATE_POINTERS, you're just
leaving them programmed in their existing state. You can do the same
thing on Gen6 too: just don't set the BLEND_STATE Change and
DEPTH_STENCIL_STATE Change bits.
If the GPU does use those pointers, it doesn't seem safe to leave them
at their own value: you flush the batch when starting a HiZ op, so the
old pointers will still be offsets from the start of the old batch...but
misinterpreted, added to the start of the new base address.
If the GPU doesn't use those pointers, all this is moot. The fact that
this hasn't died in a fire on either platform suggests that it doesn't.
But it'd be nice to know for sure.
Signed-off-by: Chad Versacechad.vers...@linux.intel.com
---
src/mesa/drivers/dri/i965/gen6_hiz.c | 24 +---
1 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_hiz.c
b/src/mesa/drivers/dri/i965/gen6_hiz.c
index a86c147..5c1844e 100644
--- a/src/mesa/drivers/dri/i965/gen6_hiz.c
+++ b/src/mesa/drivers/dri/i965/gen6_hiz.c
@@ -327,14 +327,32 @@ gen6_hiz_exec(struct intel_context *intel,
* The HiZ op doesn't use BLEND_STATE or COLOR_CALC_STATE.
*/
{
+ uint32_t blend_offset;
uint32_t depthstencil_offset;
+ uint32_t cc_offset;
+
+ struct gen6_blend_state *blend_state;
+ struct gen6_color_calc_state *cc_state;
+
+ /* Disable everything: color blending, alpha blending, and dithering. */
+ blend_state = brw_state_batch(brw, AUB_TRACE_BLEND_STATE,
+sizeof(*blend_state), 64,
+blend_offset);
+ memset(blend_state, 0, sizeof(*blend_state));
Technically, a Source Alpha Blend Factor of 0 is marked as Reserved.
That seems like slightly more evidence that it doesn't use these
buffers. Slightly.
+ /* The HiZ op doesn't use the CC, so just zero-fill the state. */
+ cc_state = brw_state_batch(brw, AUB_TRACE_CC_STATE,
+ sizeof(*cc_state), 64,
+cc_offset);
+ memset(cc_state, 0, sizeof(*cc_state));
+
gen6_hiz_emit_depth_stencil_state(brw, op,depthstencil_offset);
BEGIN_BATCH(4);
OUT_BATCH(_3DSTATE_CC_STATE_POINTERS 16 | (4 - 2));
- OUT_BATCH(1); /* BLEND_STATE offset */
- OUT_BATCH(depthstencil_offset | 1); /* DEPTH_STENCIL_STATE offset */
- OUT_BATCH(1); /* COLOR_CALC_STATE offset */
+ OUT_BATCH(blend_offset | 1);
+ OUT_BATCH(depthstencil_offset | 1);
+ OUT_BATCH(cc_offset | 1);
ADVANCE_BATCH();
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45578] main/image.c:1659: _mesa_convert_colors: Assertion `dstType == 0x1403' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=45578 --- Comment #7 from Alexander von Gluck kallis...@unixzen.com 2012-02-11 12:59:25 PST --- Created attachment 56902 -- https://bugs.freedesktop.org/attachment.cgi?id=56902 assertion error on Haiku Same assertion seen on Haiku while writing new swrast driver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: enable remap table when --enable-shared-glapi
On Sat, Feb 11, 2012 at 8:56 PM, Kenneth Graunke kenn...@whitecape.org wrote: Now the question is: can we reapply Matt's patch, removing the --enable-shared-glapi option and making it always on? That would be great. Jakob said on IRC that he didn't think this fix was correct, but I don't know what he had in mind. I asked a few weeks ago if anyone knew why an unshared-glapi would be a good thing to have but I didn't see any reasons. If shared-glapi works everywhere, then I think it's a good option to remove. It'll make converting glapi to automake easier too. I'd like to reapply the patch removing the shared-glapi option. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965/fs: Enable register spilling on gen7 too.
On Sat, 11 Feb 2012 12:48:03 -0800, Kenneth Graunke kenn...@whitecape.org
wrote:
On 02/09/2012 09:42 PM, Eric Anholt wrote:
It turns out the same messages work on gen7, we were just being paranoid.
Fixes the penumbra shadows mode of Lightsmark since the register
allocation fix.
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index 0d1712e..7da1418 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -236,8 +236,6 @@ fs_visitor::assign_regs()
if (reg == -1) {
fail(no register to spill\n);
- } else if (intel-gen= 7) {
-fail(no spilling support on gen7 yet\n);
} else if (c-dispatch_width == 16) {
fail(no spilling support on 16-wide yet\n);
} else {
Hmm. You're right...that should work fine.
There were a number of reasons I hadn't implemented spilling:
- Wrong data port caches
- g112-127 weren't reserved for use as MRFS, so we already lost
- I thought we had to use the new scratch read/write messages.
I fixed the first one, you fixed the second, and the third is just a
nicety. So this sounds good.
Incidentally, I did play around with the scratch read message, but
didn't quite get it working.
pgplibP5lUbay.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Don't set the sampler count in 3DSTATE_VS.
On Fri, 10 Feb 2012 22:24:08 -0800, Kenneth Graunke kenn...@whitecape.org
wrote:
We don't want to use brw-sampler.count here, as it includes samplers
used only by the FS...which is most of them.
This also lets us drop the CACHE_NEW_SAMPLER dirty bit on Gen6.
My plan for samplers was that we can just look at what our program uses
at compile time and save that in prog_data, so it would be
CACHE_NEW_{VS,WM}_PROG instead.
pgpKK1ZfizLlD.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
