Signed-off-by: Guillem Jover
---
.gitignore |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index a9bc5d4..a6243bf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,6 +10,7 @@
*.pyc
*.pyo
*.so
+*.so.*
*.sw[a-z]
*.tar
*.tar.bz2
--
1.7.6.3
Signed-off-by: Guillem Jover
---
docs/envvars.html |2 --
docs/install.html |1 -
src/mesa/drivers/x11/fakeglx.c | 17 -
src/mesa/drivers/x11/xm_api.c | 20
src/mesa/drivers/x11/xmesaP.h |7 ---
5 files changed,
Hi!
Here's some patches that clean up the tree from legacy stuff, update
the documentation and the .gitignore file.
regards,
guillem
Guillem Jover (3):
Ignore all shared objects
Remove remnants of legacy glide support
Update references to README files
.gitignore |
Signed-off-by: Guillem Jover
---
docs/install.html | 12 ++--
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/docs/install.html b/docs/install.html
index 92622b1..07e38bf 100644
--- a/docs/install.html
+++ b/docs/install.html
@@ -304,16 +304,8 @@ Documentation for other
On 3 October 2011 17:46, Ian Romanick 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 application-de
On 4 October 2011 00:41, Eric Anholt wrote:
> 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
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. Signed
The i965 driver already had a function to do this (brw_count_bits()),
but it was buggy (it only counted the bottom 32 bits) and it was
clumsy (it had a strange and broken fallback for non-GCC-like
compilers, which fortunately was never used). Since Mesa already has
a _mesa_bitcount() function, it
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 vert
To the best of my knowledge, this patch series completes my work on
clipping for i965 Gen6 and beyond. Most of this is clean-up work,
though there is one minor bug fix (patch 3/6).
The only patch which might be controversial is patch 6/6, which
"de-compacts" the clip planes for Gen6 and beyond.
No functional change. This patch rearranges the struct
brw_vs_prog_key so that the two fields related to clipping are
together, and documents those fields. This should make the patches
that follow easier to comprehend, since they add additional
clipping-related fields to this structure.
---
src/
Previously, brw_compute_vue_map required an argument indicating the
number of clip planes in use, but all it did with it was check if it
was nonzero.
This patch changes brw_compute_vue_map to take a boolean instead.
This allows us to avoid some unnecessary recompilation of the Gen4/5
GS and SF thr
2011/10/3 Matt Turner :
> 2011/10/3 Stéphane Marchesin :
>> 2011/10/3 Ian Romanick :
>>> On 10/03/2011 03:59 PM, Stéphane Marchesin wrote:
2011/10/3 Chad Versace:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/03/2011 03:20 PM, Stéphane Marchesin wrote:
2011/10/3 Stéphane Marchesin :
> 2011/10/3 Ian Romanick :
>> On 10/03/2011 03:59 PM, Stéphane Marchesin wrote:
>>>
>>> 2011/10/3 Chad Versace:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/03/2011 03:20 PM, Stéphane Marchesin wrote:
>
> Us poor souls who cross
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. Si
2011/10/3 Ian Romanick :
> On 10/03/2011 03:59 PM, Stéphane Marchesin wrote:
>>
>> 2011/10/3 Chad Versace:
>>>
>>> -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 wh
>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,
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_h
---
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 @@ ast_declarator_list::hir(exec
On 10/03/2011 03:59 PM, Stéphane Marchesin wrote:
2011/10/3 Chad Versace:
-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
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-*
---
src/mesa/drivers/dri/i965/brw
On 10/03/2011 02:17 PM, Paul Berry wrote:
> so if anyone feels the urge to bike-shed about it, now is your chance.
I'll let others handle the bike-shedding :)
For the series:
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@lists.freedes
2011/10/3 Chad Versace :
> -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 c
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.
---
src/mesa/drivers/dri/i96
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 +
.../drivers/dr
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 beh
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 +
src/mesa
Oops please ignore the resend. Unintended :)
Stéphane
2011/10/3 Stéphane Marchesin :
> 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/freebs
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 with
From: Stephen White
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
b/src/gallium/state_trackers/glx/xlib/xm_api.c
index 8f6406d
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.
Th
-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?
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 ctx->Tran
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 va
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
On Mon, 03 Oct 2011 08:51:09 -0600, Brian Paul 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 code here
On 10/03/2011 07:20 AM, Brian Paul wrote:
On 10/02/2011 04:44 PM, Ian Romanick wrote:
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/mesa/main/APIspec.xml | 27 ---
src/mesa/main/fbobject.c | 7 ++-
2 files changed, 6 insertions(+), 28 deletions(-)
diff --git
On 09/30/2011 09:14 PM, Brian Paul wrote:
From: Brian Paul
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 gl_texture_image::ImageOff
On Mon, 3 Oct 2011 16:26:20 +0200, Luc Verhaegen 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 in advance is
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
--- a/src/mesa/main/
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 motiv
On 10/02/2011 04:44 PM, Ian Romanick wrote:
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/mesa/main/APIspec.xml | 27 ---
src/mesa/main/fbobject.c |7 ++-
2 files changed, 6 insertions(+), 28 deletions(-)
diff --git a/src/mesa/main/APIspec.xml b/s
- Original Message -
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=30353
Kevin DeKorte changed:
What|Removed |Added
CC||kdeko...@yahoo.com
--
Configure bugmail
https://bugs.freedesktop.org/show_bug.cgi?id=30353
--- Comment #8 from Kevin DeKorte 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.
http://lists.freedes
46 matches
Mail list logo
