- Original Message -
On Die, 2012-02-28 at 09:08 -0800, Benoit Jacob wrote:
At Mozilla we've been wondering if we could get a good software
fallback for users who can't get hardware-accelerated WebGL. Mesa
llvmpipe seems like the best open source OpenGL renderer, right? At
https://bugs.freedesktop.org/show_bug.cgi?id=45277
--- Comment #5 from maxi...@free.fr 2012-02-29 03:06:13 PST ---
Fixed for me on master.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the
Christian König wrote:
xvmc is much better now its' buffers don't get mixed up, I saw it tear
once but couldn't repeat.
I spoke too soon about xvmc - I was concentrating on SD which is fixed
by the patches.
HD with or without these is still quite broken.
It doesn't look like out of order
On 02/28/2012 06:49 PM, Yuanhan Liu wrote:
Hi Brian,
comments?
Looks OK to me. I don't think there would be any harm in emitting the
point size attribute if neither a vertex shader nor vertex program was
enabled but GL_VERTEX_PROGRAM_POINT_SIZE_ARB was enabled.
Reviewed-by: Brian Paul
After biasing we need to clamp to be sure we don't exceed the number of
levels in the mipmap. This fixes an assertion at svga_sampler_view.c:70
v2: simplify the biasing, clamping code per Jose's suggestion.
---
src/gallium/drivers/svga/svga_state_tss.c |4 ++--
1 files changed, 2
On 02/28/2012 12:59 PM, Jose Fonseca wrote:
- Original Message -
Hi guys,
So I've gotten llvmpipe GLSL 1.20 support with native integers
enabled
to be 0 regressions from non-integers enabled.
The one big problem I've hit is non-native integer llvmpipe uses
system_values, it takes
That is when building with --disable-opengl.
Fix for commit c5f4024a793f1209b1693aed9a46be9374ba4741.
CC: Chad Versace c...@chad-versace.us
---
src/mesa/drivers/common/meta.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c
That is when building with --disable-opengl.
Fix for commit cb045880b113b0042d8dfb7e4cdf76e6cc76c1d1.
CC: Paul Berry stereotype...@gmail.com
---
src/mesa/drivers/common/meta.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c
We dont want eglplatform.h to typedef egl native types
to x11 types, when x11 headers are not available.
---
configure.ac |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0caa1b1..92a0e52 100644
--- a/configure.ac
+++ b/configure.ac
@@
That is only when the egl x11 platform is not choosen to be build.
---
configure.ac |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 92a0e52..345d865 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1418,12 +1418,13 @@ if test
On 02/28/2012 01:33 PM, Eric Anholt wrote:
---
src/mesa/main/vtxfmt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/vtxfmt.c b/src/mesa/main/vtxfmt.c
index f3cca93..6fb016b 100644
--- a/src/mesa/main/vtxfmt.c
+++ b/src/mesa/main/vtxfmt.c
@@ -41,7
From: Ian Romanick ian.d.roman...@intel.com
Originally ARB_draw_instanced only specified that ARB decorated name.
Since no vendor actually implemented that behavior and some apps use
the undecorated name, the extension now specifies that both names are
available.
Signed-off-by: Ian Romanick
Yuanhan,
Let's commit this. I think that was the consensus.
Without it it will be extremely hard to get apitrace to accurately track
recursive buffer mappings w/ 2.x, as described in
https://github.com/apitrace/apitrace/issues/66 .
I'll try to keep apitrace working correctly without these
On 02/29/2012 08:36 AM, Benjamin Franzke wrote:
That is when building with --disable-opengl.
Fix for commit c5f4024a793f1209b1693aed9a46be9374ba4741.
CC: Chad Versacec...@chad-versace.us
---
src/mesa/drivers/common/meta.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
For
Hi everyone,
here's another series of patches for r600g.
These 5 patches are mostly about improving queries:
r600g: move all query code into r600_query.c
r600g: release query buffers in destroy_query
r600g: don't suspend timer queries for u_blitter
r600g: correctly handle queries which
And rename or inline functions where appropriate.
There is no reason to keep this stuff in r600_hw_context.c.
---
src/gallium/drivers/r600/r600.h| 12 -
src/gallium/drivers/r600/r600_blit.c |4 +-
src/gallium/drivers/r600/r600_hw_context.c | 417
This fixes a memory leak introduced with the rework.
---
src/gallium/drivers/r600/r600_query.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_query.c
b/src/gallium/drivers/r600/r600_query.c
index a896f03..25731c2 100644
---
Timer queries should be able to measure the time spent in u_blitter as well.
Queries are split into two groups: the timer ones and the others (streamout,
occlusion), because we should only suspend non-timer queries for u_blitter,
and later if the non-timer queries are suspended, the context flush
---
src/gallium/drivers/r600/r600_query.c | 33 +++--
1 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_query.c
b/src/gallium/drivers/r600/r600_query.c
index 53440ae..def0a97 100644
---
VPORT_SCISSOR is the OpenGL scissor. How do I know? Because there are
16 of them just like GL4.1 has multiple scissor rectangles.
---
src/gallium/drivers/r600/evergreen_hw_context.c | 18 -
src/gallium/drivers/r600/evergreen_state.c | 82 ---
We must use VPORT_SCISSOR, because that's the only one we can use for multiple
scissor rectangles in ARB_viewport_array.
R700 can use the VPORT_SCISSOR_ENABLE bit, but R600 doesn't have that and must
emit a 8192x8192 rectangle if scissor is disabled.
This commit also cleanups magic numbers in
We only need one scissor for the framebuffer.
---
src/gallium/drivers/r600/evergreen_hw_context.c | 10
src/gallium/drivers/r600/evergreen_state.c | 28 +-
2 files changed, 16 insertions(+), 22 deletions(-)
diff --git
---
src/gallium/drivers/r600/r600_hw_context.c |4
src/gallium/drivers/r600/r600_state.c | 20
2 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index
Implement it right using STRMOUT_CONFIG.RAST_STREAM. This fixes rasterizer
discard with points and lines.
This also adds another derived state. It's a combination of rasterizer discard
and streamout enable.
---
src/gallium/drivers/r600/evergreen_hw_context.c | 14 -
For polygons, we have been using face culling with success, but that doesn't
work for points and lines.
Setting the point size and line width to 0 fixes it.
Also improve it even more by setting SCREEN_SCISSOR to a zero area.
---
src/gallium/drivers/r600/r600_hw_context.c |1 +
Unused by the current stack and APIs, therefore untestable.
It was used to facilitate the transition to integers.
---
src/gallium/drivers/r600/evergreen_state.c | 17 -
src/gallium/drivers/r600/r600_state.c | 17 -
2 files changed, 0 insertions(+), 34
---
src/gallium/drivers/r600/evergreen_state.c | 80 +++-
src/gallium/drivers/r600/r600_state.c | 80 +++-
2 files changed, 158 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
---
src/gallium/drivers/r600/r600_pipe.c | 10 ++
src/gallium/drivers/r600/r600_pipe.h |4
src/gallium/drivers/r600/r600_state_common.c | 21 ++---
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git
---
src/gallium/drivers/r600/evergreen_hw_context.c |2 +
src/gallium/drivers/r600/evergreend.h |5
src/gallium/drivers/r600/r600_hw_context.c |1 +
src/gallium/drivers/r600/r600_state_common.c| 25 +++
src/gallium/drivers/r600/r600d.h
---
src/gallium/drivers/r300/r300_transfer.c |2 +-
src/gallium/drivers/r600/r600_query.c |2 +-
src/gallium/drivers/r600/r600_texture.c |2 +-
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 18 --
src/gallium/winsys/radeon/drm/radeon_winsys.h |
This will be useful for efficient handling of the DISCARD transfer flags.
---
src/gallium/drivers/r600/r600_blit.c | 78 +++--
1 files changed, 54 insertions(+), 24 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_blit.c
---
src/gallium/drivers/r600/r600_blit.c |8 +--
src/gallium/drivers/r600/r600_buffer.c | 65 +++-
src/gallium/drivers/r600/r600_pipe.c |2 +-
src/gallium/drivers/r600/r600_pipe.h |3 +
4 files changed, 62 insertions(+), 16 deletions(-)
diff --git
On 29.02.2012 17:53, Marek Olšák wrote:
Why this wasn't allowed is beyond me.
Because that resulted in allot better performance.
It doesn't make much sense to let the driver blit the content of a
texture into a tilled version and make a single draw and then throw away
that tilled version
On 29.02.2012 12:33, Andy Furniss wrote:
Christian König wrote:
xvmc is much better now its' buffers don't get mixed up, I saw it tear
once but couldn't repeat.
I spoke too soon about xvmc - I was concentrating on SD which is
fixed by the patches.
HD with or without these is still quite
Hi,
The main change of this series it to push the shininess lookup tables
currently stored in the mesa context down into the swtnl context.
With this change thesse shininess values are no longer needlessly recomputed
and allocated for all contexts. Instead these tables are only present and
It is only used as a temporary variable during computation of
_CosCutoff. So, don't store it.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/main/light.c |7 ++-
src/mesa/main/mtypes.h |1 -
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git
This variable is only used locally in _mesa_update_lighting.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/main/light.c |8
src/mesa/main/mtypes.h |1 -
src/mesa/x86/gen_matypes.c |1 -
3 files changed, 4 insertions(+), 6 deletions(-)
diff
Since the shine tables are implicitly invalidated by having
a different shininess value than the current one, we can
omit the explicit invalidation of the shine table.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/main/light.c | 27 ---
1 files
Use direct computation of pow for computing the shininess
in _tnl_RasterPos. Since the _tnl_RasterPos function is still
used by plenty drivers that do only need the shine table for
_tnl_RasterPos but do not make use of swtnl computations, this
enables pushing down the shine table computation and
Now that _tnl_RasterPos no longer uses the shine tables, avoid
revalidating them.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/tnl/t_rasterpos.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/mesa/tnl/t_rasterpos.c
Since the shine tables are now only used in the tnl lighting stage, where
they are validated through the tnl driver function NotifyMaterialChange
called in tnl/t_vb_light.c, we can not omit calling
_mesa_validate_all_lighting_tables (which only validates the shine tables)
in main/light.c.
All users of the shine table outside of the tnl module
are gone. Move the implementation into the tnl module and
prefix the public functions with _tnl.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/drivers/dri/r200/r200_tcl.c |4 +-
2012/2/29 Mathias Fröhlich mathias.froehl...@gmx.net:
Hi,
The main change of this series it to push the shininess lookup tables
currently stored in the mesa context down into the swtnl context.
With this change thesse shininess values are no longer needlessly recomputed
and allocated for
On 02/29/2012 11:45 AM, Mathias Fröhlich wrote:
Hi,
The main change of this series it to push the shininess lookup tables
currently stored in the mesa context down into the swtnl context.
With this change thesse shininess values are no longer needlessly recomputed
and allocated for all
Alex, Brian,
That was fast!
Thanks for the review!
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, 29 Feb 2012 15:11:06 +0800, Yuanhan Liu yuanhan@linux.intel.com
wrote:
According to 3DSTATE_MAP_STATE at page of 104 in Bspec
vol3d 3D Instructions:
[DevGDG and DevAlv]: Must be a power of 2 for cube maps
Well, it turned out to be that we need do this for other
platforms as
Border only applies to the width for a 1D texture array and for a 2D
texture array it applies to the width and height but not to the
depth. This was not handled correctly in strip_texture_border().
Note: This is a candidate for stable branches
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
On 02/29/2012 12:56 PM, Eric Anholt wrote:
Module: Mesa
Branch: master
Commit: 88612029f6ce9d2717220a0ef31bfe71a8c85529
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=88612029f6ce9d2717220a0ef31bfe71a8c85529
Author: Eric Anholte...@anholt.net
Date: Sun Feb 5 10:46:13 2012 +0100
This fixes the egl_gallium.so driver build when no system libEGL.so is
present, since it's relying on the lib/ to build against until it gets
converted to automake.
Tested with EGL_DRIVER=egl_gallium EGL_LOG_LEVEL=debug ./es2gears
---
src/egl/main/Makefile.am |1 +
1 files changed, 1
On 02/29/2012 08:29 AM, Ian Romanick wrote:
From: Ian Romanickian.d.roman...@intel.com
Originally ARB_draw_instanced only specified that ARB decorated name.
Since no vendor actually implemented that behavior and some apps use
the undecorated name, the extension now specifies that both names are
Border only applies to the width for a 1D texture array and for a 2D
texture array the it applies to the width and height but not to the
depth. This was not handled correctly in strip_texture_border().
v2: height is also affected by border if target is GL_TEXTURE_3D
Note: This is a candidate
Hi Dave,
This commit has caused a few regressions with the vmware svga driver:
commit 72931ca4b9fb1002f5b62b74f7f7f32e94e80fde
Author: Dave Airlie airl...@redhat.com
Date: Thu Feb 9 19:44:55 2012 +
st/mesa: don't unreference user attribs up front.
postpone unreferences until end
https://bugs.freedesktop.org/show_bug.cgi?id=41791
--- Comment #8 from Henri Verbeet hverb...@gmail.com 2012-02-29 14:35:03 PST
---
Note that https://bugs.freedesktop.org/show_bug.cgi?id=44466 /
https://bugs.archlinux.org/task/27645 looks somewhat similar, although with a
different backtrace and
https://bugs.freedesktop.org/show_bug.cgi?id=44466
--- Comment #6 from Henri Verbeet hverb...@gmail.com 2012-02-29 14:43:48 PST
---
Although the backtrace is different, I think there are some similarities with
https://bugs.freedesktop.org/show_bug.cgi?id=41791.
--
Configure bugmail:
Many thanks for the answers, that is what I needed to know.
I filed this mentored bug, hopefully someone bites:
https://bugzilla.mozilla.org/show_bug.cgi?id=731836
llvmpipe can also be built as drop-in replacement for
libGL.so/opengl32, which could be shipped/bundled separately
Yes, that is
- Original Message -
On Tue, 28 Feb 2012 09:08:39 -0800 (PST), Benoit Jacob
bja...@mozilla.com wrote:
Hi List,
At Mozilla we've been wondering if we could get a good software
fallback for users who can't get hardware-accelerated WebGL. Mesa
llvmpipe seems like the best open
2012/2/29 Christian König deathsim...@vodafone.de:
On 29.02.2012 17:53, Marek Olšák wrote:
Why this wasn't allowed is beyond me.
Because that resulted in allot better performance.
It doesn't make much sense to let the driver blit the content of a texture
into a tilled version and make a
- Original Message -
On Die, 2012-02-28 at 09:08 -0800, Benoit Jacob wrote:
At Mozilla we've been wondering if we could get a good software
fallback for users who can't get hardware-accelerated WebGL. Mesa
llvmpipe seems like the best open source OpenGL renderer, right? At
- Original Message -
I think the old Mesa software renderer
is faster for some fixed function cases, as it has special hand
written paths for that.
Not a concern for us: WebGL doesn't expose, or rely on, the fixed function API.
It stays close to OpenGL ES 2.
Cheers,
Benoit
Intel and Gallium drivers don't support texture borders. Border is stripped
before texture is used inside the driver. So, glGetTexLevelParameteriv()
returns the stripped values of texture dimensions. But it returns un-
stripped values for proxy textures. This patch adds strip_texture_border()
for
On Wed, Feb 29, 2012 at 3:07 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
Border only applies to the width for a 1D texture array and for a 2D
texture array the it applies to the width and height but not to the
depth. This was not handled correctly in strip_texture_border().
v2: height is
On Wed, 29 Feb 2012 14:07:36 -0800, Anuj Phogat anuj.pho...@gmail.com wrote:
Border only applies to the width for a 1D texture array and for a 2D
texture array the it applies to the width and height but not to the
depth. This was not handled correctly in strip_texture_border().
v2: height
If the texture is a 1D array, don't remove the border pixel from the
height. Similarly for 2D array textures and the depth direction.
Simplify the function by assuming the border is always one pixel.
---
src/mesa/main/teximage.c | 37 -
1 files changed, 20
On Wed, Feb 29, 2012 at 6:44 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
Intel and Gallium drivers don't support texture borders. Border is stripped
before texture is used inside the driver. So, glGetTexLevelParameteriv()
returns the stripped values of texture dimensions. But it returns un-
These will be used by glReadPixels() and glGetTexImage() to fix issues
with reading GL_LUMINANCE and other formats.
---
src/mesa/main/pack.c | 91 ++
src/mesa/main/pack.h |7
2 files changed, 98 insertions(+), 0 deletions(-)
diff --git
See the comments for _mesa_rebase_rgba_float() for details.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=46679
---
src/mesa/main/readpix.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 3384d8a..4918549
This reverts commit d5a6c172547d8964f4d4bb79637651decaf9deee.
llvm-3.1svn r151687 makes MemoryObject accessor members const again.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp |8
1 files changed, 0 insertions(+), 8 deletions(-)
On Wed, Feb 29, 2012 at 10:34 PM, Brian Paul bri...@vmware.com wrote:
Hi Dave,
This commit has caused a few regressions with the vmware svga driver:
commit 72931ca4b9fb1002f5b62b74f7f7f32e94e80fde
Author: Dave Airlie airl...@redhat.com
Date: Thu Feb 9 19:44:55 2012 +
st/mesa:
On Mit, 2012-02-29 at 16:06 -0800, Benoit Jacob wrote:
- Original Message -
On Die, 2012-02-28 at 09:08 -0800, Benoit Jacob wrote:
At Mozilla we've been wondering if we could get a good software
fallback for users who can't get hardware-accelerated WebGL. Mesa
llvmpipe
I am a first time mailing list joiner, long time user of exclusively
free video drivers. I was very upset to see the DRI1 drivers removed
from the codebase in August and I waited until now to complain because I
wanted to see if the good changes like OpenGL3 would at least make it
into the 8.0
- Original Message -
These will be used by glReadPixels() and glGetTexImage() to fix
issues
with reading GL_LUMINANCE and other formats.
---
src/mesa/main/pack.c | 91
++
src/mesa/main/pack.h |7
2 files changed, 98
71 matches
Mail list logo
