I haven't tested LLVM-3.1 myself but seems good to me. Thanks Vinson.
Jose
- Original Message -
Fix build with llvm-3.1svn.
llvm-3.1svn r149918 changed BufferMemoryObject::getExtent and
BufferMemoryObject::readByte from const member functions to non-const
member functions in
Hi!
I have a couple of quick EGL questions that I hope someone knows the
answer to:
1) I'm trying to test the vmwgfx_dri driver with EGL driver egl_dri2,
platform drm, but it doesn't seem like this
configuration supports EGL_MESA_screen_surface so basically all relevant
EGL demos fail. Is
On Thu, Feb 9, 2012 at 8:51 AM, Thomas Hellstrom thellst...@vmware.com wrote:
Hi!
I have a couple of quick EGL questions that I hope someone knows the answer
to:
1) I'm trying to test the vmwgfx_dri driver with EGL driver egl_dri2,
platform drm, but it doesn't seem like this
configuration
2012/2/9 Thomas Hellstrom thellst...@vmware.com:
Hi!
I have a couple of quick EGL questions that I hope someone knows the answer
to:
1) I'm trying to test the vmwgfx_dri driver with EGL driver egl_dri2,
platform drm, but it doesn't seem like this
configuration supports
On 02/08/2012 11:47 PM, Mathias Fröhlich wrote:
Hi Brian,
On Wednesday, February 08, 2012 20:13:44 Brian Paul wrote:
---
src/mesa/main/light.h| 32 +---
src/mesa/tnl/t_rasterpos.c |3 +--
src/mesa/tnl/t_vb_lighttmp.h | 27
Dave,
The series looks great.
Just this one patch seems off: LLVMTypeOf(scalar) should always match
bld-elem_type, and it would only match bld-int_elem_type if the type itself
is an integer. Therefore it seems that the caller is using an integer scalar
with a floating point build context when
I think that we could probably just remove TGSI_TYPE_UNTYPED and just say MOV
is TGSI_TYPE_FLOAT.
I'm OK either way.
Jose
- Original Message -
From: Dave Airlie airl...@redhat.com
Infer from the operand the type of value to store.
MOV is untyped but we use the float store path.
Good idea.
Jose
- Original Message -
---
src/mesa/drivers/common/meta.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c
b/src/mesa/drivers/common/meta.c
index aa5fef8..0cf1028 100644
--- a/src/mesa/drivers/common/meta.c
Anuj,
The patch you committed (15986d2), the first version you posted that
tests:
if (width 2 * border || width maxSize)
return GL_FALSE;
causes my copy of conform (mustpass.c / proxy texture test) to fail
with swrast/softpipe/llvmpipe. It passes w/ NVIDIA's driver.
I
The mapping from TEXTURE_x_INDEX to GL_TEXTURE_x was broken in
alloc_proxy_textures() because the elements in the targets[] array
were in the wrong order.
This didn't actually cause any failures since we never really use the
proxy texture's Target field. But let's get it right.
NOTE: This is a
On Wed, 8 Feb 2012 19:20:24 -0800, Kenneth Graunke kenn...@whitecape.org
wrote:
Ironlake appears to check our pointer against the General State Base
Address upper bound, rather than ignoring the zero bound as it ought.
Unfortunately, since we leave GSBA set to zero, there is no logical
On Wednesday 8 February 2012 18:28:05 Michel Dänzer wrote:
On Fre, 2012-02-03 at 17:32 +, Simon Farnsworth wrote:
r300g is able to sleep until a fence completes rather than busywait
because it creates a special buffer object and relocation that stays
busy until the CS containing the
On 02/09/2012 08:14 AM, Brian Paul wrote:
Anuj,
The patch you committed (15986d2), the first version you posted that tests:
if (width 2 * border || width maxSize)
return GL_FALSE;
causes my copy of conform (mustpass.c / proxy texture test) to fail with
swrast/softpipe/llvmpipe. It passes w/
On Thu, Feb 9, 2012 at 11:02 AM, Ian Romanick i...@freedesktop.org wrote:
On 02/09/2012 08:14 AM, Brian Paul wrote:
Anuj,
The patch you committed (15986d2), the first version you posted that
tests:
if (width 2 * border || width maxSize)
return GL_FALSE;
causes my copy of conform
https://bugs.freedesktop.org/show_bug.cgi?id=45578
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
CC||xunx.f...@intel.com
From: Dave Airlie airl...@redhat.com
Can't see any reason this wouldn't be better off as an inline.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/vbo/vbo.h| 18 --
src/mesa/vbo/vbo_exec_array.c | 16
2 files changed, 16
From: Dave Airlie airl...@redhat.com
postpone unreferences until end of function, as the ones in use will
get naturally dereferenced.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_draw.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git
Hi Eric,
On Tuesday, February 07, 2012 12:25:29 Eric Anholt wrote:
Does this also fix our piglit tests for the bug? If so, note it in the
commit message, and
Ok, included.
Reviewed-by: Eric Anholt e...@anholt.net
Thanks!
Mathias
___
mesa-dev
On 02/09/2012 12:15 PM, Anuj Phogat wrote:
On Thu, Feb 9, 2012 at 11:02 AM, Ian Romanick i...@freedesktop.org
mailto:i...@freedesktop.org wrote:
On 02/09/2012 08:14 AM, Brian Paul wrote:
Anuj,
The patch you committed (15986d2), the first version you
posted that
On 02/09/2012 01:57 PM, Brian Paul wrote:
On 02/09/2012 12:15 PM, Anuj Phogat wrote:
On Thu, Feb 9, 2012 at 11:02 AM, Ian Romanick i...@freedesktop.org
mailto:i...@freedesktop.org wrote:
On 02/09/2012 08:14 AM, Brian Paul wrote:
Anuj,
The patch you committed (15986d2), the first version you
On Thu, Feb 9, 2012 at 1:07 PM, Brian Paul bri...@vmware.com wrote:
On 02/09/2012 01:57 PM, Brian Paul wrote:
On 02/09/2012 12:15 PM, Anuj Phogat wrote:
On Thu, Feb 9, 2012 at 11:02 AM, Ian Romanick i...@freedesktop.org
mailto:i...@freedesktop.org wrote:
On 02/09/2012 08:14 AM, Brian Paul
On 02/08/2012 11:49 AM, Robert Bragg wrote:
This adds the GLX_ prefix to the string we pass to
__glXEnableDirectExtension() otherwise it doesn't match the name we have
in known_glx_extensions[] in glxextensions.c and doesn't get enabled.
This mistake wasn't noticed before since
Mesa 8.0 has been released. Mesa 8.0 is a new development release.
People who are concerned with stability and reliability should stick
with a previous release or wait for Mesa 8.0.1.
The tag in the GIT repository for Mesa 8.0 is 'mesa-8.0'.
Mesa 7.11.1 is available for download at
On 02/09/2012 03:43 PM, Ian Romanick wrote:
Mesa 8.0 has been released. Mesa 8.0 is a new development release.
People who are concerned with stability and reliability should stick
with a previous release or wait for Mesa 8.0.1.
The tag in the GIT repository for Mesa 8.0 is 'mesa-8.0'.
Mesa
On 02/06/2012 03:08 PM, Eric Anholt wrote:
On Fri, 03 Feb 2012 16:09:25 -0700, Ian Romanicki...@freedesktop.org wrote:
On 02/03/2012 02:11 AM, Eric Anholt wrote:
On Wed, 1 Feb 2012 12:29:39 -0700, Ian Romanicki...@freedesktop.org
wrote:
From: Ian Romanickian.d.roman...@intel.com
A
From: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/common/meta.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index aa5fef8..3647395 100644
--- a/src/mesa/drivers/common/meta.c
+++
Simple question: is there a reason why many options and features under
development or testing are only available by manually setting env
variables? The point is, why isn't there an experimental tab under
driconf where we could easily enable or disable the different features?
Modifying .drirc
https://bugs.freedesktop.org/show_bug.cgi?id=45420
--- Comment #9 from Benjamin Herrenschmidt b...@kernel.crashing.org
2012-02-09 19:00:37 PST ---
This is broken. This is not valid C :-)
#if (LLVM_NATIVE_ARCH == X86 || LLVM_NATIVE_ARCH == X86Target)
Doesn't work with the C preprocessor. The
https://bugs.freedesktop.org/show_bug.cgi?id=45420
Benjamin Herrenschmidt b...@kernel.crashing.org changed:
What|Removed |Added
Status|RESOLVED
X86Target is a variable, and therefore isn't defined at compile time. So
LLVM_NATIVE_ARCH == X86Target
is translated into
0 == 0
and since X86 is first, we always pick it.
Therefore we replace the logic with PIPE_ARCH_*.
https://bugs.freedesktop.org/show_bug.cgi?id=45420
---
---
src/mesa/main/pixeltransfer.c | 26 --
src/mesa/main/pixeltransfer.h |6 --
2 files changed, 0 insertions(+), 32 deletions(-)
diff --git a/src/mesa/main/pixeltransfer.c b/src/mesa/main/pixeltransfer.c
index 5c167e0..c6172b9 100644
---
Use the float tables instead. Pixel maps are seldom used so this
shouldn't be a big deal. Next, we can get rid of the gl_pixelmap::Map8
array.
---
src/mesa/state_tracker/st_atom_pixeltransfer.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git
---
src/mesa/main/mtypes.h |1 -
src/mesa/main/pixel.c |2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 521bb39..6066e6f 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1045,7 +1045,6 @@
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
We just abort later, but at least this should result in more
informative bug reports.
---
src/mesa/drivers/dri/i965/brw_fs.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index
https://bugs.freedesktop.org/show_bug.cgi?id=45292
--- Comment #1 from Jeremy Murphy jeremy.william.mur...@gmail.com 2012-02-09
22:43:22 PST ---
OK, I have found what is going wrong, it is pretty simple. d3d10.h contains
these three lines at the end of the file:
#include d3d10misc.h
#include
https://bugs.freedesktop.org/show_bug.cgi?id=45292
--- Comment #2 from Jeremy Murphy jeremy.william.mur...@gmail.com 2012-02-09
22:52:08 PST ---
However, I have another thought. The last time that I successfully compiled
Mesa against Wine was 16-Dec-2011, which is way after the 'ID3D10Include'
https://bugs.freedesktop.org/show_bug.cgi?id=45816
Bug #: 45816
Summary: [IVB]SPECviewperf 11 cause GPU hung
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status:
38 matches
Mail list logo
