On 01/18/2012 03:06 PM, Eric Anholt wrote:
Shaves a few instructions off of the VS in Lightsmark, but no
statistically significant performance difference on gen7 (n=5).
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 22 --
1 files changed, 16 insertions(+), 6 deleti
On 01/18/2012 05:34 PM, Eric Anholt wrote:
AC_CHECK_LIB has this nasty behavior, like the cflags tests, of
automatically putting the tested value into the global LIBS on
success. This caused -lexpat to end up in LIBS, but without the
--with-expat dir, so my 32-bit build on a 64 system using expa
On 01/21/2012 09:34 AM, Carl Worth wrote:
The trick here is that flex always chooses the rule that matches the most
text. So with a input text of "two:" which we want to be lexed as an
IDENTIFIER token "two" followed by an OTHER token ":" the previous OTHER
rule would match longer as a single tok
On 01/19/2012 03:48 PM, Yuanhan Liu wrote:
When rendering to FBO, rendering is inverted. At the same time, we would
also make sure the point sprite origin is inverted. Or, we will get an
inverted result correspoinding to rendering to the default winsys FBO.
Bugzilla: https://bugs.freedesktop.org
Please can we not use magic numbers, ever?
Marek
On Sat, Jan 21, 2012 at 9:17 PM, Vadim Girlin wrote:
> Signed-off-by: Vadim Girlin
> ---
> src/gallium/drivers/r600/r600_asm.c | 84
> +--
> 1 files changed, 11 insertions(+), 73 deletions(-)
>
> diff --git a/s
https://bugs.freedesktop.org/show_bug.cgi?id=40361
--- Comment #6 from Jaroslav Šmíd 2012-01-22 17:01:45 PST
---
I hope I am not spamming too much :D
Now looking at that code ...
if (end >= ctx->Array.ArrayObj->_MaxElement) {
Maybe there shouldn't be greater or equal, but only greater? Just as
https://bugs.freedesktop.org/show_bug.cgi?id=40361
--- Comment #5 from Jaroslav Šmíd 2012-01-22 16:26:08 PST
---
Now, I am not sure if this is even bug in mesa since there is warning in that
function, saying "This should probably be fixed in the application".
But, if I comment out that conditio
https://bugs.freedesktop.org/show_bug.cgi?id=40361
Jaroslav Šmíd changed:
What|Removed |Added
AssignedTo|i...@freedesktop.org |mesa-dev@lists.freedesktop.
I think the CAP-based approach is the way to expose GLSL 1.3 for st/mesa.
The later GLSL versions can be easily derived from exposed extensions,
it's just GLSL 1.3 that is tricky. Comments welcome.
---
src/mesa/drivers/dri/intel/intel_extensions.c |9 +--
src/mesa/drivers/dri/intel/intel_scre
Strictly speaking, it's not legal to expose EXT_texture_integer without
EXT_gpu_shader4. It might be even dangerous (apps can assume EXT_gpu_shader4
is available without checking for it).
The check in compute_version is removed as well, because that's already
covered by GLSLVersion >= 130.
---
sr
---
src/mesa/main/fbobject.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 2b3ac2e..eaf2c46 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1280,6 +1280,15 @@ _mesa_base_fbo_format
---
src/mesa/state_tracker/st_extensions.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 12fce86..6c8a491 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/
- use OR to combine bind flags
- combine both conditionals into one
- move the ARB_fbo enable where it belongs
---
src/mesa/state_tracker/st_extensions.c | 21 +
1 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa
---
src/gallium/drivers/r600/r600_asm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index a888704..b981cf1 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600
libgbm.so.1.0.0 (instead of libgbm.so.1.0) is installed now
along with libgbm.so.1 (no change).
---
configs/autoconf.in |8
configs/default | 13 --
configure.ac | 16 ++-
src/gbm/Makefile | 14 --
src/gbm/Makefile.a
---
src/glsl/strtod.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/glsl/strtod.c b/src/glsl/strtod.c
index ff34591..a876e13 100644
--- a/src/glsl/strtod.c
+++ b/src/glsl/strtod.c
@@ -44,7 +44,8 @@
double
glsl_strtod(const char *s, char **end)
{
-#if defined(_G
---
src/mesa/main/imports.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index bbc6ac6..82713a1 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -764,7 +764,7 @@ float
_mesa_strtof( const char *s,
---
src/gallium/drivers/svga/include/svga_types.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/svga/include/svga_types.h
b/src/gallium/drivers/svga/include/svga_types.h
index 7fd9bab..7a99f34 100644
--- a/src/gallium/drivers/svga/include/svga_t
---
src/gallium/drivers/llvmpipe/lp_rast.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
b/src/gallium/drivers/llvmpipe/lp_rast.c
index 873c261..efa5024 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/dri
---
src/gallium/SConscript |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/gallium/SConscript b/src/gallium/SConscript
index 8efd04c..ae94637 100644
--- a/src/gallium/SConscript
+++ b/src/gallium/SConscript
@@ -14,18 +14,13 @@ SConscript('auxiliary/SConscript'
On Sun, Jan 22, 2012 at 9:09 AM, Jon TURNEY wrote:
> On 11/01/2012 23:37, Matt Turner wrote:
>> No one on IRC knows why an unshared glapi is useful.
>
> It looks like this change stops OSMesa from builing on cygwin (See [1])
>
> I think this is because we never tried building it with shared glapi
https://bugs.freedesktop.org/show_bug.cgi?id=45070
--- Comment #3 from Matt Turner 2012-01-22 08:32:50 PST ---
>From a clean git checkout of mesa:
./autogen.sh --with-dri-drivers=swrast --with-gallium-drivers=swrast
[--enable-egl --enable-osmesa --enable-openvg --prefix=...]
--
Configure bugma
2012/1/22 Christian König :
> On 22.01.2012 16:46, Dave Airlie wrote:
>>
>> 2012/1/22 Christian König:
>>>
>>> Sorry, but that looks really ugly and pretty much unmaintainable, cause
>>> you
>>> constantly need to lookup the meaning of the values.
>>>
>>> Also I haven't looked into the docs (but go
On 22.01.2012 16:46, Dave Airlie wrote:
2012/1/22 Christian König:
Sorry, but that looks really ugly and pretty much unmaintainable, cause you
constantly need to lookup the meaning of the values.
Also I haven't looked into the docs (but going to do so tomorrow), but I'm
pretty sure that those r
Hi all,
Just a quick heads up that the complete X.org/Mesa/Wayland FOSDEM
Schedule is now available at:
http://fosdem.org/2012/schedule/track/xorgopenicc_devroom
or alternatively:
http://wiki.x.org/wiki/fosdem2012
For the first time ever, we made the printed schedule deadline w
2012/1/22 Christian König :
> Sorry, but that looks really ugly and pretty much unmaintainable, cause you
> constantly need to lookup the meaning of the values.
>
> Also I haven't looked into the docs (but going to do so tomorrow), but I'm
> pretty sure that those ranges aren't 100% correct.
It wa
Sorry, but that looks really ugly and pretty much unmaintainable, cause
you constantly need to lookup the meaning of the values.
Also I haven't looked into the docs (but going to do so tomorrow), but
I'm pretty sure that those ranges aren't 100% correct.
Regards,
Christian.
On 21.01.2012 21:
On 11/01/2012 23:37, Matt Turner wrote:
> No one on IRC knows why an unshared glapi is useful.
It looks like this change stops OSMesa from builing on cygwin (See [1])
I think this is because we never tried building it with shared glapi on cygwin
before, and if we had, we would have noticed that l
A while back, we split off GLw into a separate repository. The
rationale was that GLw should be maintained and released independently
from Mesa/Gallium since it hardly ever changes and isn't closely tied to
the core GL and drivers.
I'd like to do the same for libGLU. I've split it out, creat
https://bugs.freedesktop.org/show_bug.cgi?id=45070
--- Comment #2 from Vinson Lee 2012-01-22 02:23:18 PST
---
(In reply to comment #1)
> Why are you using the old static Makefile targets instead of automake or
> SCons?
> We'd like to remove those.
What is now the right and correct way to buil
I'm getting GLX errors from Unigine Heaven, as well as OilRush:
X Error of failed request: BadRequest (invalid request code or no such
operation)
Major opcode of failed request: 153 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 46
Current serial number
https://bugs.freedesktop.org/show_bug.cgi?id=45070
--- Comment #1 from Kenneth Graunke 2012-01-22 02:05:40
PST ---
Why are you using the old static Makefile targets instead of automake or SCons?
We'd like to remove those.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=em
https://bugs.freedesktop.org/show_bug.cgi?id=45070
Bug #: 45070
Summary: 'make linux-x86-64-debug' fails to build
libGL.so.1.5.08000
Classification: Unclassified
Product: Mesa
Version: unspecified
Platform: x86-64 (AMD
33 matches
Mail list logo
