Jakob:
That you for your very invaluable advice, which worked flawlessly for me
until xorg-vmwgfx recently [29-30 September 2011] vanished from git:
*xorg/vmwgfx: Kill this target. It's not used anymore: *This fixes a
build error introduced with commit winsys/svga: Update to vmwgfx kernel
https://bugs.freedesktop.org/show_bug.cgi?id=30353
--- Comment #8 from Kevin DeKorte kdeko...@yahoo.com 2011-10-03 05:09:17 PDT
---
Might want to read this mailing list thread I posted about using llvm on 32bit
and 64bit builds. I seemed like it might be going somewhere and then it just
died.
https://bugs.freedesktop.org/show_bug.cgi?id=30353
Kevin DeKorte kdeko...@yahoo.com changed:
What|Removed |Added
CC||kdeko...@yahoo.com
--
On 10/02/2011 04:44 PM, Ian Romanick wrote:
From: Ian Romanickian.d.roman...@intel.com
Signed-off-by: Ian Romanickian.d.roman...@intel.com
---
src/mesa/main/APIspec.xml | 27 ---
src/mesa/main/fbobject.c |7 ++-
2 files changed, 6 insertions(+), 28
With Matthieu proposing to talk about DRM/KMS for non-linux system, the
deadline was met, and i have just filed a DevRoom request with the
FOSDEM organizers. I should have an answer this month still.
One thing does seem to have changed though, DevRooms are for one day
only unless properly
On 09/29/2011 04:40 PM, Eric Anholt wrote:
---
src/mesa/main/texstore.c | 68 +++---
1 files changed, 52 insertions(+), 16 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index cbed26c..2aaff0d 100644
---
On Mon, 3 Oct 2011 16:26:20 +0200, Luc Verhaegen l...@skynet.be wrote:
Keith, at XDC you mentioned filling half a day with wayland stuff. Do
solidify this ASAP so i can make sure that we get saturday as well.
I'm working on this -- as you might imagine, getting funding for an
event this far
On 09/30/2011 09:14 PM, Brian Paul wrote:
From: Brian Paulbri...@vmware.com
These were used to find the start of a 3D image slice (or 2D array texture
slice) given a base address. Instead, use a simple array of address of
image slices instead.
This is a step toward getting rid of the
On 10/03/2011 07:20 AM, Brian Paul wrote:
On 10/02/2011 04:44 PM, Ian Romanick wrote:
From: Ian Romanickian.d.roman...@intel.com
Signed-off-by: Ian Romanickian.d.roman...@intel.com
---
src/mesa/main/APIspec.xml | 27 ---
src/mesa/main/fbobject.c | 7 ++-
2 files
On Mon, 03 Oct 2011 08:51:09 -0600, Brian Paul bri...@vmware.com wrote:
On 09/29/2011 04:40 PM, Eric Anholt wrote:
Just a minor stylistic comment on the above code. I'd prefer it to be:
if (target == GL_TEXTURE_1D_ARRAY) {
/* 1D array code here */
}
else {
/* other target
This is a minor rework of a patch series I submitted on 9/27 to
implement gl_ClipVertex on i965 Gen6 and above. They key subtlety
here is that due to differences in coordinate system conventions used
by GLSL vs fixed function shaders, we need to use the eye coordinate
clip planes when compiling a
Before this patch, clip planes didn't work properly in Mesa when using
vertex shaders, because Mesa assigned both gl_ClipVertex and
gl_Position to the same gl_vert_result (VERT_RESULT_HPOS). As a
result, backends couldn't distinguish between the two variables, so
any shader that wrote different
This patch implements proper support for gl_ClipVertex by causing the
new VS backend to populate the clip distance VUE slots using
VERT_RESULT_CLIP_VERTEX when appropriate, and by using the
untransformed clip planes in ctx-Transform.EyeUserPlane rather than
the transformed clip planes in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/03/2011 03:20 PM, Stéphane Marchesin wrote:
Us poor souls who cross compile mesa want to be able to specify which
pkg-config to pick, or at least just change one place.
Would setting PKG_CONFIG_PATH at configuration time solve your problem?
Previous to this patch, setup_uniform_clipplane_values() was setting
up clip plane uniforms based on ctx-Transform.ClipPlanesEnabled, a
piece of state not stored in the vertex shader cache key. As a
result, a change to this piece of state might not trigger a necessary
vertex shader recompile.
From: Stephen White senorbla...@chromium.org
Otherwise we'll be unable to use our pbuffers.
---
src/gallium/state_trackers/glx/xlib/xm_api.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c
Us poor souls who cross compile mesa want to be able to specify which
pkg-config to pick, or at least just change one place.
---
configs/default |1 +
configs/freebsd-dri |4 ++--
configs/linux-dri | 16
Previously, if the user enabled a non-consecutive set of clip planes
(e.g. 0, 1, and 3), the driver would compact them down to a
consecutive set starting at 0. This optimization was of dubious
value, and complicated the implementation of gl_ClipDistance.
This patch changes the driver so that
They're both implemented the same in GLSL IR (since round() has
undefined behavior for n + 0.5). The specification of the C function
in use here is a bit unclear: rint(3) says that nearbyint() is like
rint() in that it uses the current rounding direction from
fesetround(3). fesetround(3) says
The condmod instruction ends up generating garbage condition codes,
because apparently the comparison happens on the accumulator value (33
bits for UD), not the truncated value that would be written.
Fixes fs-op-neg-*
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
The condmod instruction ends up generating garbage condition codes,
because apparently the comparison happens on the accumulator value (33
bits for UD), not the truncated value that would be written.
Fixes vs-op-neg-*
---
src/mesa/drivers/dri/i965/brw_vec4.h |1 +
The only remaining uses of brw_vs_prog_key::nr_userclip only occurred
when using clip planes (as opposed to gl_ClipDistance). This patch
renames the value to nr_userclip_planes and sets it to zero when
gl_ClipDistance is in use. This avoids unnecessary VS recompiles.
---
On 10/03/2011 03:41 PM, Eric Anholt wrote:
The condmod instruction ends up generating garbage condition codes,
because apparently the comparison happens on the accumulator value (33
bits for UD), not the truncated value that would be written.
Fixes fs-op-neg-*
---
On 10/03/2011 03:59 PM, Stéphane Marchesin wrote:
2011/10/3 Chad Versacec...@chad-versace.us:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/03/2011 03:20 PM, Stéphane Marchesin wrote:
Us poor souls who cross compile mesa want to be able to specify which
pkg-config to pick, or at least
---
src/glsl/ast_to_hir.cpp |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 91a2231..99ca321 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2803,6 +2803,12 @@
On 10/03/2011 04:51 PM, Eric Anholt wrote:
---
src/glsl/ast_to_hir.cpp |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 91a2231..99ca321 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
From page 22 (28 of PDF) of GLSL 1.30 spec:
It is an error to provide a literal integer whose magnitude is too
large to store in a variable of matching signed or unsigned type.
Unsigned integers have exactly 32 bits of precision. Signed integers
use 32 bits, including a sign bit,
2011/10/3 Ian Romanick i...@freedesktop.org:
On 10/03/2011 03:59 PM, Stéphane Marchesin wrote:
2011/10/3 Chad Versacec...@chad-versace.us:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/03/2011 03:20 PM, Stéphane Marchesin wrote:
Us poor souls who cross compile mesa want to be able
2011/10/3 Matt Turner matts...@gmail.com:
2011/10/3 Stéphane Marchesin stephane.marche...@gmail.com:
2011/10/3 Ian Romanick i...@freedesktop.org:
On 10/03/2011 03:59 PM, Stéphane Marchesin wrote:
2011/10/3 Chad Versacec...@chad-versace.us:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On
On 09/30/2011 01:09 AM, Paul Berry wrote:
My intention was never to give up support for fixed function clipping.
I just don't know how to tell, from within the vertex shader backend,
whether the shader we're compiling is an application-defined GLSL shader
or Mesa's built-in fixed function
On 10/03/2011 05:03 PM, Eric Anholt wrote:
From page 22 (28 of PDF) of GLSL 1.30 spec:
It is an error to provide a literal integer whose magnitude is too
large to store in a variable of matching signed or unsigned type.
Unsigned integers have exactly 32 bits of precision.
On 3 October 2011 17:46, Ian Romanick i...@freedesktop.org wrote:
On 09/30/2011 01:09 AM, Paul Berry wrote:
My intention was never to give up support for fixed function clipping.
I just don't know how to tell, from within the vertex shader backend,
whether the shader we're compiling is an
32 matches
Mail list logo
