In llvm-2.9 Target->createMCInstPrinter() takes different arguments
Signed-off-by: Tobias Droste
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
b/src/gallium/au
On 28.03.2011 02:51, Marek Olšák wrote:
> Some GPUs can't do it (I think most of DX9 ones).
>
> We should later decide how Gallium will expose this feature.
How about you just add a PIPE_CAP_FRAMEBUFFE_MIXED_FORMATS and
PIPE_CAP_FRAMEBUFFER_MIXED_DIMENSIONS ?
And if those aren't present you only ex
That's a shame. I use that feature and it works (Gallium says I have
an AMD RS780). As I read the GL_EXT_framebuffer_object it implies the
(internal) format is the same for each rendertarget, the
GL_ARB_framebuffer_object relaxes this. Both specs allow
implementation-dependent additional restrictio
Hi Tobias,
What revision of llvm are you using? I'm not seeing any build failures with
llvm-2.9rc2. However, I am seeing build failures with llvm-3.0svn related to
createMCInstPrinter.
Vinson
From: mesa-dev-bounces+vlee=vmware@lists.freedesktop.org
On 03/27/2011 04:11 PM, Tobias Droste wrote:
In llvm-2.9 Target->createMCInstPrinter() takes different arguments
Signed-off-by: Tobias Droste
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxi
2011/3/26 Alex Deucher :
>
> WebM would definitely be cool.
>
Ok I give this idea some thoughts and I think I am gonna go with a
hardware accelerated vp8 decoder into a vdpau state tracker.
On the plus side :
- VP8 has a way more simple design than h264, and that should cut the
development time,
Hi,
One short coming of macro has keep entertaining me until i figure out
what was wrong, here is
a simple scenario :
Macro can lead to hard to debug list bugs. For instance consider
the following :
LIST_ADD(item, list->prev)
3 instruction of the macro became :
(list->prev)->next->prev = item
whi
New patch here:
gallium: add a CAP for mixed colorbuffer format support
Some GPUs can't do it (I think most of DX9 ones), so they should have
the option not to allow it.
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 1c1a8f2..0f0ca39 10
On Mon, Mar 28, 2011 at 2:16 PM, ★ Emeric wrote:
> - I saw on this maillist talks about the S3TC patent situation. Why
> nobody express similar concerns about an h264 implementation living in
> mesa ? Because that would mean violate much more patents, without
> paying royalties and everything...
>From bc4ccf8d1c0474f432a3740a9c0bb5a67b3ebae8 Mon Sep 17 00:00:00 2001
From: haitao
Date: Tue, 29 Mar 2011 13:33:46 +0800
Subject: [PATCH] egl_dri2 x11: Fix a typo
Signed-off-by: Haitao Feng
---
src/egl/drivers/dri2/platform_x11.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d
---
src/mesa/program/prog_optimize.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/program/prog_optimize.c b/src/mesa/program/prog_optimize.c
index 96971f2..b5f0fb3 100644
--- a/src/mesa/program/prog_optimize.c
+++ b/src/mesa/program/prog_optimize.c
@@ -74,6 +74
This pass scans programs for instructions that read registers that have
not been written and replaces these reads with a read from a constant
register with the value of zero. This pass prevents phantom
dependencies from being introduced by the register allocator and
improves the efficiency of subs
So, can you please suggest me which is the exact API or place to do this change.
is there any such pointer for FAKE_FRONT_LEFT been maintained in kernel DRM
module? or some where in x server kernel module? if it is so i can get some
reference from there.
please suggest me.
Regards,
Srini.
_
13 matches
Mail list logo
