- 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, 9
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 r
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
>
On Wed, Feb 29, 2012 at 10:34 PM, Brian Paul wrote:
> Hi Dave,
>
> This commit has caused a few regressions with the vmware svga driver:
>
> commit 72931ca4b9fb1002f5b62b74f7f7f32e94e80fde
> Author: Dave Airlie
> Date: Thu Feb 9 19:44:55 2012 +
>
> st/mesa: don't unreference user attribs
This reverts commit d5a6c172547d8964f4d4bb79637651decaf9deee.
llvm-3.1svn r151687 makes MemoryObject accessor members const again.
Signed-off-by: Vinson Lee
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/src/gal
On Wed, Feb 29, 2012 at 08:41:45AM -0800, Jose Fonseca wrote:
> 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
---
src/mesa/main/texgetimage.c | 77 ++
1 files changed, 4 insertions(+), 73 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index a02a491..44a828a 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetima
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 1006
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 a/
On Wed, Feb 29, 2012 at 6:44 PM, Anuj Phogat 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-
> stripped values for
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 in
On Wed, 29 Feb 2012 14:07:36 -0800, Anuj Phogat 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 also affected b
On Wed, Feb 29, 2012 at 3:07 PM, Anuj Phogat 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 also affected by bo
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 p
- 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
- 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?
2012/2/29 Christian König :
> 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
- Original Message -
> On Tue, 28 Feb 2012 09:08:39 -0800 (PST), Benoit Jacob
> 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 source
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
This is awesome news! Thank you very much!
Reviewed-by: Marek Olšák
On Wed, Feb 29, 2012 at 5:29 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Originally ARB_draw_instanced only specified that ARB decorated name.
> Since no vendor actually implemented that behavior and some apps use
> the u
https://bugs.freedesktop.org/show_bug.cgi?id=44466
--- Comment #6 from Henri Verbeet 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: https://bugs.freedesktop.org/
https://bugs.freedesktop.org/show_bug.cgi?id=41791
--- Comment #8 from Henri Verbeet 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 distribution. A co
Hi Dave,
This commit has caused a few regressions with the vmware svga driver:
commit 72931ca4b9fb1002f5b62b74f7f7f32e94e80fde
Author: Dave Airlie
Date: Thu Feb 9 19:44:55 2012 +
st/mesa: don't unreference user attribs up front.
postpone unreferences until end of function, as th
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 for
On 02/29/2012 08:29 AM, Ian Romanick wrote:
From: Ian Romanick
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-b
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 insertio
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 Anholt
Date: Sun Feb 5 10:46:13 2012 +0100
egl/main: Convert
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
---
A piglit test case to
On Wed, 29 Feb 2012 15:11:06 +0800, Yuanhan Liu
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 well, like pineview.
>
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 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 contexts
2012/2/29 Mathias Fröhlich :
>
> 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
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
---
src/mesa/drivers/dri/r200/r200_tcl.c |4 +-
src/mesa/drivers/dri/radeon/radeon_tcl.c |4 +-
src
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.
Signed-o
Now that _tnl_RasterPos no longer uses the shine tables, avoid
revalidating them.
Signed-off-by: Mathias Froehlich
---
src/mesa/tnl/t_rasterpos.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/mesa/tnl/t_rasterpos.c b/src/mesa/tnl/t_rasterpos.c
index 38f63b2..50b5f
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 va
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
---
src/mesa/main/light.c | 27 ---
1 files changed, 0 insertions(+),
This variable is only used locally in _mesa_update_lighting.
Signed-off-by: Mathias Froehlich
---
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 --git a/src/mesa/main/lig
It is only used as a temporary variable during computation of
_CosCutoff. So, don't store it.
Signed-off-by: Mathias Froehlich
---
src/mesa/main/light.c |7 ++-
src/mesa/main/mtypes.h |1 -
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/light.c b/src/me
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
mai
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
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 befo
---
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 a
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
b/src/gallium/drivers/r600/r600_blit.c
---
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 |
Otherwise streamout with rasterizer discard will make the kernel upset
if the state tracker doesn't set a depth-stencil-alpha state.
---
src/gallium/drivers/r600/evergreen_state.c |2 ++
src/gallium/drivers/r600/r600_state.c |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff
---
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/r600/evergreen_state.c |4
src/gallium/drivers/r600/evergreend.h |2 ++
src/gallium/drivers/r600/r600_state.c |3 +++
src/gallium/drivers/r600/r600d.h |2 ++
4 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/gallium
---
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 a/src/gallium/drivers/r600/r600_pip
---
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
b/src/gallium/drivers/r60
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 delet
Why this wasn't allowed is beyond me.
Eventually I'd like to make every format blittable, so that the function
can go away.
---
src/gallium/drivers/r600/r600_texture.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_texture.c
b/src/g
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 +
src/gallium/dr
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 -
src/gallium/drivers/
---
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 9e99c7e
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 a/src/gallium/drivers/r600/evergreen_hw_c
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 cre
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 ---
src/gallium/drivers/r6
Also use XXX in the other ones, because it's the most used word for that
purpose in Mesa.
---
src/gallium/drivers/r600/eg_sq.h |2 +-
src/gallium/drivers/r600/evergreen_state.c | 11 ---
src/gallium/drivers/r600/r600_asm.c |2 +-
src/gallium/drivers/r600/r6
---
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
--- a/src/gallium/drivers/r600/r600_query
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
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
--- a/src/gal
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 +--
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 do
On 02/29/2012 08:36 AM, Benjamin Franzke wrote:
That is when building with --disable-opengl.
Fix for commit c5f4024a793f1209b1693aed9a46be9374ba4741.
CC: Chad Versace
---
src/mesa/drivers/common/meta.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
For 1&2: Reviewed-by: Bri
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 quer
From: Ian Romanick
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
Cc: Marek Olšák
---
The cha
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 +41,7
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 "x$enab
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 when building with --disable-opengl.
Fix for commit cb045880b113b0042d8dfb7e4cdf76e6cc76c1d1.
CC: Paul Berry
---
src/mesa/drivers/common/meta.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
in
That is when building with --disable-opengl.
Fix for commit c5f4024a793f1209b1693aed9a46be9374ba4741.
CC: Chad Versace
---
src/mesa/drivers/common/meta.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
Looks good. Thanks Brian.
Jose
- Original Message -
> 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/gal
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 the
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 insertions(
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
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
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
- 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? A
79 matches
Mail list logo
