Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
Tested on evergreen: fixes EXT_transform_feedback order tests, no regressions.
src/gallium/drivers/r600/r600_shader.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
Tested on evergreen: fixes fogcoord-dp* tests, no regressions
src/gallium/drivers/r600/r600_shader.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
Tested on evergreen: fixes 2 fragcoord tests, no regressions
src/gallium/drivers/r600/r600_shader.c | 31 +++
1 files changed, 27 insertions(+), 4 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=44928
Fabio Pedretti fabio@libero.it changed:
What|Removed |Added
CC|
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
Tested on evergreeen: fixes 5 interpolation tests, no regressions
src/gallium/drivers/r600/r600_shader.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
https://bugs.freedesktop.org/show_bug.cgi?id=44928
--- Comment #1 from José Fonseca jfons...@vmware.com 2012-01-23 03:59:10 PST
---
FWIW, our build bots are failing to build i965:
$ ./autogen.sh --prefix=/usr --enable-gles1 --enable-gles2 --enable-openvg
--enable-xorg --enable-xa --disable-glut
For ARB_color_buffer_float. Most hardware can't do it and st/mesa is
the perfect place for a fallback.
The exceptions are:
- r500 (vertex clamp only)
- nv50 (both)
- nvc0 (both)
- softpipe (both)
We also have to take into account that r300 can do CLAMPED vertex colors only,
while r600 can do
The TGSI code may vary depending on the clamp_color bit.
---
src/mesa/state_tracker/st_cb_program.c | 10 --
src/mesa/state_tracker/st_debug.c |2 +-
src/mesa/state_tracker/st_program.c|9 +
src/mesa/state_tracker/st_program.h|4 ++--
4 files changed, 8
---
src/mesa/state_tracker/st_program.c | 434 +--
1 files changed, 215 insertions(+), 219 deletions(-)
diff --git a/src/mesa/state_tracker/st_program.c
b/src/mesa/state_tracker/st_program.c
index 978de88..f0c6533 100644
--- a/src/mesa/state_tracker/st_program.c
https://bugs.freedesktop.org/show_bug.cgi?id=44561
Kai k...@dev.carbon-project.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=44726
Kai k...@dev.carbon-project.org changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, Jan 23, 2012 at 7:32 AM, Marek Olšák mar...@gmail.com wrote:
For ARB_color_buffer_float. Most hardware can't do it and st/mesa is
the perfect place for a fallback.
The exceptions are:
- r500 (vertex clamp only)
- nv50 (both)
- nvc0 (both)
- softpipe (both)
We also have to take
On Sun, Jan 22, 2012 at 6:36 PM, Marek Olšák mar...@gmail.com wrote:
- 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
On Sun, Jan 22, 2012 at 4:36 PM, Marek Olšák mar...@gmail.com wrote:
---
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
On Sun, Jan 22, 2012 at 4:36 PM, Marek Olšák mar...@gmail.com wrote:
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
On Sun, Jan 22, 2012 at 4:36 PM, Marek Olšák mar...@gmail.com wrote:
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.
---
On Mon, Jan 23, 2012 at 2:40 PM, Brian Paul brian.e.p...@gmail.com wrote:
Just curious: is this just for the sake of completeness or some other reason?
Reviewed-by: Brian Paul bri...@vmware.com
For the sake of completeness, but there are at least two valid reasons as well:
- We don't provide
Refine always build shared dricore so we don't build it if we don't need
it because we aren't actually building any dri drivers because of
--disable-driglx-direct
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
On Sat, Jan 21, 2012 at 8:47 PM, Matt Turner matts...@gmail.com wrote:
If you're building mesa, you know what drivers you want.
---
I mentioned this on IRC and a couple of people agreed, we'd rather
not have to specify an empty list of drivers to not build either
gallium or dri drivers.
I
On Sun, Jan 22, 2012 at 5:36 PM, Matt Turner matts...@gmail.com wrote:
libgbm.so.1.0.0 (instead of libgbm.so.1.0) is installed now
along with libgbm.so.1 (no change).
Looks good to me.
Kristian
---
configs/autoconf.in | 8
configs/default | 13 --
On Sun, Jan 22, 2012 at 7:03 AM, Kenneth Graunke kenn...@whitecape.org wrote:
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
On Sun, Jan 22, 2012 at 5:03 AM, Kenneth Graunke kenn...@whitecape.org wrote:
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
- Original Message -
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
- Original Message -
If you're building mesa, you know what drivers you want.
NACK, the default should be build as much as possible.
The proper fix here is to merge --with-dri-drivers and
--with-gallium-drivers, and have it figure with gallium/dri
drivers to turn based on that list, so:
2012/1/23 Christian König deathsim...@vodafone.de:
On 22.01.2012 17:24, Dave Airlie wrote:
2012/1/22 Christian Königdeathsim...@vodafone.de:
On 22.01.2012 16:46, Dave Airlie wrote:
2012/1/22 Christian Königdeathsim...@vodafone.de:
Sorry, but that looks really ugly and pretty much
On Mon, Jan 23, 2012 at 7:20 AM, Jakob Bornecrantz ja...@vmware.com wrote:
- Original Message -
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
Hi,
I will have to (at least partially) revert this commit, as well as the
forked code in glsl_to_tgsi:
commit 2c326e72664e65166c68b027b26aaf373f3be36d
Author: Roland Scheidegger srol...@vmware.com
Date: Thu Feb 4 19:23:09 2010 +0100
gallium: add point size clamp to implementation
On 01/20/2012 06:12 PM, Brian Paul wrote:
$ glxinfo
name of display: :0.0
glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1:
undefined symbol: u_tsd_set
My nightly builds of VTK and ParaView built with OSMesa or xlib OSMesa
are broken this way too.
Their mesa's are built
On Sat, Jan 21, 2012 at 10:42 AM, Matt Turner matts...@gmail.com wrote:
On Sat, Jan 21, 2012 at 9:56 AM, Brian Paul bri...@vmware.com wrote:
I'm going to hold off on merging until Matt fixes the build problem I
mentioned in my other message. It'll make bisecting easier for me in case
a
https://bugs.freedesktop.org/show_bug.cgi?id=44345
--- Comment #1 from Pavel Ondračka pavel.ondra...@email.cz 2012-01-23
08:39:16 PST ---
This regression can be also reproduced with llvmpipe, however you need to set
webgl.force-enabled to true in about:config (Firefox doesn't enable webgl for
https://bugs.freedesktop.org/show_bug.cgi?id=44345
--- Comment #2 from Pavel Ondračka pavel.ondra...@email.cz 2012-01-23
08:40:04 UTC ---
Ah, sorry wrong bug.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are
https://bugs.freedesktop.org/show_bug.cgi?id=44912
--- Comment #1 from Pavel Ondračka pavel.ondra...@email.cz 2012-01-23
08:40:47 PST ---
This regression can be also reproduced with llvmpipe, however you need to set
webgl.force-enabled to true in about:config (Firefox doesn't enable webgl for
Hi,
Recently I am not able to build mesa from git, I am attaching the link to
log file with error in linking after issuing commands
make realclean; git clean -fdx ; ./autogen.sh --prefix=/opt/gfx-test
--with-dri-drivers=i965 --disable-egl --with-gallium-drivers= ; make
V=1 -j6 build.txt
Build
https://bugs.freedesktop.org/show_bug.cgi?id=44912
--- Comment #2 from Benoit Jacob bja...@mozilla.com 2012-01-23 08:54:45 PST
---
I think this should get fixed by
https://bugzilla.mozilla.org/show_bug.cgi?id=696495 .
My understanding is that the OpenGL spec is loose there, so for WebGL we
Dear Mateusz,
mateusz.ka...@gmail.com schrieb am 23.01.2012 17:52:
make realclean; git clean -fdx ; ./autogen.sh --prefix=/opt/gfx-test
--with-dri-drivers=i965 --disable-egl --with-gallium-drivers= ; make
V=1 -j6 build.txt
Build log: http://www.kaduk.net/~mateusz/build.txt
When rowstride was negatie, unsigned promotion caused a segfault here:
299│if (rb-Format == MESA_FORMAT_S8) {
300│ const GLuint rowStride = rb-RowStride;
301│ for (i = 0; i count; i++) {
302│ if (x[i] = 0 y[i] = 0 x[i] w y[i] h) {
303├stencil[i] = *(map
On Mon, Jan 23, 2012 at 10:15 AM, Chad Versace
chad.vers...@linux.intel.com wrote:
When rowstride was negatie, unsigned promotion caused a segfault here:
299│ if (rb-Format == MESA_FORMAT_S8) {
300│ const GLuint rowStride = rb-RowStride;
301│ for (i = 0; i count; i++) {
302│
Am 23.01.2012 15:44, schrieb Marek Olšák:
Hi,
I will have to (at least partially) revert this commit, as well as the
forked code in glsl_to_tgsi:
commit 2c326e72664e65166c68b027b26aaf373f3be36d
Author: Roland Scheidegger srol...@vmware.com
Date: Thu Feb 4 19:23:09 2010 +0100
On Mon, Jan 23, 2012 at 9:01 AM, Brian Paul brian.e.p...@gmail.com wrote:
On Sat, Jan 21, 2012 at 8:47 PM, Matt Turner matts...@gmail.com wrote:
If you're building mesa, you know what drivers you want.
---
I mentioned this on IRC and a couple of people agreed, we'd rather
not have to specify
On Mon, Jan 23, 2012 at 9:00 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote:
Refine always build shared dricore so we don't build it if we don't need
it because we aren't actually building any dri drivers because of
--disable-driglx-direct
Signed-off-by: Jon TURNEY
On Mon, Jan 23, 2012 at 9:28 AM, Jakob Bornecrantz ja...@vmware.com wrote:
- Original Message -
If you're building mesa, you know what drivers you want.
NACK, the default should be build as much as possible.
We don't build OpenVG, OSMesa, i915g, GLESv1, GLESv2, and a number of
Gallium
https://bugs.freedesktop.org/show_bug.cgi?id=44928
Matt Turner matts...@gmail.com changed:
What|Removed |Added
CC||dan...@ffwll.ch,
On Mon, 2012-01-23 at 12:37 -0500, Matt Turner wrote:
On Mon, Jan 23, 2012 at 9:01 AM, Brian Paul brian.e.p...@gmail.com wrote:
On Sat, Jan 21, 2012 at 8:47 PM, Matt Turner matts...@gmail.com wrote:
If you're building mesa, you know what drivers you want.
---
I mentioned this on IRC and a
On Mon, Jan 23, 2012 at 6:34 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 23.01.2012 15:44, schrieb Marek Olšák:
Hi,
I will have to (at least partially) revert this commit, as well as the
forked code in glsl_to_tgsi:
commit 2c326e72664e65166c68b027b26aaf373f3be36d
Author: Roland
So I've been digging through the assertion error I am getting under Haiku
and have finally found the issue...
The Mesa tnl depends on the Mesa rtasm header (mesa/x86/rtasm/x86sse.h),
however scons never compiles mesa/x86/rtasm/x86sse.c into libmesa. As
x86/rtasm/x86sse.c is never compiled
On 23/01/2012 17:50, Matt Turner wrote:
Good idea.
Reviewed-by: Matt Turner matts...@gmail.com
Do you have commit access?
Yes.
d01e166..0fce6d3 master - master
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Am 23.01.2012 20:02, schrieb Roland Scheidegger:
Am 23.01.2012 19:55, schrieb Marek Olšák:
On Mon, Jan 23, 2012 at 7:29 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 23.01.2012 19:07, schrieb Marek Olšák:
On Mon, Jan 23, 2012 at 6:34 PM, Roland Scheidegger srol...@vmware.com
wrote:
On Fri, Jan 20, 2012 at 6:12 PM, Brian Paul bri...@vmware.com wrote:
Hi Matt,
I'm not sure if your recent changes are responsible for this. I did
./configure --enable-xlib-glx ; make
The build appears to complete cleanly but I can't run anything:
$ glxinfo
name of display: :0.0
glxinfo:
https://bugs.freedesktop.org/show_bug.cgi?id=40059
nobled nob...@dreamwidth.org changed:
What|Removed |Added
CC|
- Mesa tnl used the Mesa rtasm headers, however
it was using the gallium rtasm symbols causing
heap corruption. (seen especially on scons
builds as Mesa rtasm wasn't even compiled).
- Mesa tnl updated to use Gallium rtasm.
---
src/mesa/sources.mak|1 -
---
src/mesa/x86/rtasm/x86sse.c | 1203
---
src/mesa/x86/rtasm/x86sse.h | 256 -
2 files changed, 0 insertions(+), 1459 deletions(-)
delete mode 100644 src/mesa/x86/rtasm/x86sse.c
delete mode 100644 src/mesa/x86/rtasm/x86sse.h
diff --git
-fvisibility=hidden was preventing them from being exported, which
combined with shared-glapi was causing undefined symbol errors at
runtime.
---
Brian: there might be more functions that should be exported. Let
me know (or let me know what to test to find them) and I'll clean
them up too.
I don't think that one should introduce a dependency between Mesa and Gallium
as each should be built without the other.
The right way to do this is to move rtasm to side by side w/ MEsa gallium
(e.g., src/rtasm), and have Mesa and Gallium both depend on it as needed.
Another way is to rename
On 23.01.2012 14:44, Jose Fonseca wrote:
I don't think that one should introduce a dependency between Mesa and
Gallium as each should be built without the
other.
The right way to do this is to move rtasm to side by side w/ MEsa
gallium (e.g., src/rtasm), and have Mesa and
Gallium both
https://bugs.freedesktop.org/show_bug.cgi?id=40361
--- Comment #7 from Roland Scheidegger srol...@vmware.com 2012-01-23 13:05:51
PST ---
(In reply to comment #6)
I hope I am not spamming too much :D
Now looking at that code ...
if (end = ctx-Array.ArrayObj-_MaxElement) {
Maybe there
On Sun, 22 Jan 2012 23:39:44 -0800, Kenneth Graunke kenn...@whitecape.org
wrote:
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).
---
On 01/23/2012 05:54 AM, Brian Paul wrote:
On Sun, Jan 22, 2012 at 4:36 PM, Marek Olšákmar...@gmail.com wrote:
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.
On Mon, Jan 23, 2012 at 10:35 PM, Ian Romanick i...@freedesktop.org wrote:
On 01/23/2012 05:54 AM, Brian Paul wrote:
On Sun, Jan 22, 2012 at 4:36 PM, Marek Olšákmar...@gmail.com wrote:
I think the CAP-based approach is the way to expose GLSL 1.3 for st/mesa.
The later GLSL versions can be
On Mon, 2012-01-23 at 14:20 +0100, Christian König wrote:
On 22.01.2012 17:24, Dave Airlie wrote:
2012/1/22 Christian Königdeathsim...@vodafone.de:
On 22.01.2012 16:46, Dave Airlie wrote:
2012/1/22 Christian Königdeathsim...@vodafone.de:
Sorry, but that looks really ugly and pretty much
From: Ian Romanick ian.d.roman...@intel.com
This is a hack to work around drivers such as i965 that:
- Set _MaintainTexEnvProgram to generate GLSL IR for
fixed-function fragment processing.
- Don't call _mesa_ir_link_shader to generate Mesa IR from the
GLSL IR.
- May use
From: Ian Romanick ian.d.roman...@intel.com
When ARB VAOs are used, glPopClientAttrib does not resurrect a deleted
VAO or VBO. This difference between the two spec is, unfortunately,
not very well spelled out in the specs.
Fixes oglc vao(advanced.pushPop.deleteVAO) and
On Fri, 20 Jan 2012 17:26:20 -0700, Brian Paul bri...@vmware.com wrote:
On 01/20/2012 04:39 PM, Eric Anholt wrote:
This cut and paste is pretty awful. I'm tempted to do a lot of this
using preprocessor tricks for customizing the parameter type from a
template function, but that's just a
2012/1/24 Vadim Girlin vadimgir...@gmail.com:
On Mon, 2012-01-23 at 14:20 +0100, Christian König wrote:
On 22.01.2012 17:24, Dave Airlie wrote:
2012/1/22 Christian Königdeathsim...@vodafone.de:
On 22.01.2012 16:46, Dave Airlie wrote:
2012/1/22 Christian Königdeathsim...@vodafone.de:
On Tue, 2012-01-24 at 00:44 +0100, Marek Olšák wrote:
2012/1/24 Vadim Girlin vadimgir...@gmail.com:
On Mon, 2012-01-23 at 14:20 +0100, Christian König wrote:
On 22.01.2012 17:24, Dave Airlie wrote:
2012/1/22 Christian Königdeathsim...@vodafone.de:
On 22.01.2012 16:46, Dave Airlie wrote:
When storing data in a buffer of type DYNAMIC_DRAW, we don't create a
drm_intel_bo for it; instead we store the data in system memory and
defer allocation of the GPU buffer until it is needed. Therefore, in
brw_update_sol_surface(), we can't just consult the buffer field of
the
https://bugs.freedesktop.org/show_bug.cgi?id=40361
--- Comment #8 from Jaroslav Šmíd jardas...@gmail.com 2012-01-23 16:58:19 PST
---
Created attachment 56059
-- https://bugs.freedesktop.org/attachment.cgi?id=56059
Debug output with array and indices printing
I did actiavate array printing and
On Mon, Jan 23, 2012 at 12:48 PM, Matt Turner matts...@gmail.com wrote:
-fvisibility=hidden was preventing them from being exported, which
combined with shared-glapi was causing undefined symbol errors at
runtime.
---
Brian: there might be more functions that should be exported. Let
me know
On Mon, Jan 23, 2012 at 6:41 PM, Brian Paul brian.e.p...@gmail.com wrote:
On Mon, Jan 23, 2012 at 12:48 PM, Matt Turner matts...@gmail.com wrote:
-fvisibility=hidden was preventing them from being exported, which
combined with shared-glapi was causing undefined symbol errors at
runtime.
---
On Tue, Jan 24, 2012 at 2:41 AM, Brian Paul brian.e.p...@gmail.com wrote:
On Mon, Jan 23, 2012 at 12:48 PM, Matt Turner matts...@gmail.com wrote:
-fvisibility=hidden was preventing them from being exported, which
combined with shared-glapi was causing undefined symbol errors at
runtime.
---
https://bugs.freedesktop.org/show_bug.cgi?id=40361
--- Comment #9 from Roland Scheidegger srol...@vmware.com 2012-01-23 19:17:11
PST ---
Looks like an app issue then indeed, I think though the test mesa does is
actually incorrect wrt basevertex.
As far as i can tell it would be perfectly ok
https://bugs.freedesktop.org/show_bug.cgi?id=44928
--- Comment #5 from Matt Turner matts...@gmail.com 2012-01-23 19:25:22 UTC ---
I'm curious, do you get this build failure after
e326480e4ebe8687948041c2dc5f5b7595559a2e (the i965/automake patch) or after one
of the later patches which cause
https://bugs.freedesktop.org/show_bug.cgi?id=44928
--- Comment #6 from Caleb Callaway enlightened.des...@gmail.com 2012-01-23
22:11:08 PST ---
On my development system (Ubuntu 11.10 64-bit), this issue appears in commit
2b3a8cbc
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=44928
--- Comment #7 from Matt Turner matts...@gmail.com 2012-01-23 22:21:38 PST ---
(In reply to comment #6)
On my development system (Ubuntu 11.10 64-bit), this issue appears in commit
2b3a8cbc
Thanks. Does building commit e326480e with
https://bugs.freedesktop.org/show_bug.cgi?id=44928
--- Comment #8 from Caleb Callaway enlightened.des...@gmail.com 2012-01-23
23:03:26 UTC ---
(In reply to comment #7)
(In reply to comment #6)
On my development system (Ubuntu 11.10 64-bit), this issue appears in commit
2b3a8cbc
Thanks.
74 matches
Mail list logo
