Michael,
On Thursday, November 10, 2011 18:42:13 Michel Dänzer wrote:
> On Don, 2011-11-10 at 11:01 +0100, Theiss, Ingo wrote:
> > The function calls of mesa/state_tracker/st_cb_readpixels.c:382 ->
> > st_readpixels and mesa/main/pack.c:552 -> _mesa_pack_rgba_span_float
> > clearly stands out whe
On Thu, 10 Nov 2011 18:01:46 -0700, Brian Paul wrote:
> ---
> src/mesa/swrast/s_readpix.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpix.c
> index 54f42db..3cef730 100644
> --- a/src/mesa/swrast/s_readpix
Fixes a bunch of conform regressions.
---
src/mesa/drivers/x11/xm_buffer.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/x11/xm_buffer.c b/src/mesa/drivers/x11/xm_buffer.c
index 6cf9f06..ea87b6d 100644
--- a/src/mesa/drivers/x11/xm_buffer.c
++
---
src/mesa/swrast/s_readpix.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpix.c
index 54f42db..3cef730 100644
--- a/src/mesa/swrast/s_readpix.c
+++ b/src/mesa/swrast/s_readpix.c
@@ -236,6 +236,7 @@ slow_read_rg
https://bugs.freedesktop.org/show_bug.cgi?id=42803
Bug #: 42803
Summary: bitmap2 demo in mesa_demos/src/sample hangs the GPU
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=42516
--- Comment #3 from Brian Paul 2011-11-10 13:45:36 PST ---
I tried your traces with llvmpipe (as of today) and didn't see any failed
assertions. I also tried the Mesa 7.11 branch it no assertions there either.
Could you try current Mesa/llvmpip
On 11/10/2011 02:17 PM, Morgan Armand wrote:
Because the type of the facing attribute is unsigned, the whole computation was
done in the unsigned range.
Fixes fbo-fragcoord2, glsl1-gl_FrontFacing var (2) and glsl-fs-frontfacing
tests.
---
src/gallium/drivers/softpipe/sp_fs_exec.c |2 +-
Because the type of the facing attribute is unsigned, the whole computation was
done in the unsigned range.
Fixes fbo-fragcoord2, glsl1-gl_FrontFacing var (2) and glsl-fs-frontfacing
tests.
---
src/gallium/drivers/softpipe/sp_fs_exec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
On 11/10/2011 09:38 AM, Paul Berry wrote:
On 9 November 2011 11:33, Eric Anholt mailto:e...@anholt.net>> wrote:
With the gl_VertexID support, everything required should now be
supported.
---
src/mesa/drivers/dri/intel/intel_extensions.c |5 -
1 files changed, 4 ins
On Wed, 9 Nov 2011 21:39:19 -0800, Kenneth Graunke
wrote:
> NEW_COLOR is only needed on Gen4-5 as brw_update_renderbuffer_surfaces
> only uses ctx->Color when intel->gen < 6.
>
> This should reduce unnecessary state updates.
>
> Signed-off-by: Kenneth Graunke
Reviewed-by: Eric Anholt
pgp0
From: Chad Versace
This patch solves three bugs.
1. When a texture was attached to the GL_DEPTH_STENCIL_ATTACHMENT point,
Mesa attached the texture only to the depth attachment point
gl_framebuffer::Attachment[BUFFER_DEPTH]
and failed to attach it to the stencil attachment point
gl_frame
On 9 November 2011 22:07, Kenneth Graunke wrote:
> These simply don't exist in the 1.30 specification---none of the Offset
> variants allow samplerCube. This must have been a cut and paste error
> from textureGrad, which /does/ allow cubemaps.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/gls
On 9 November 2011 22:07, Kenneth Graunke wrote:
> Due to a cut and paste error, these were accidentally misnamed
> textureProj() rather than textureProjOffset().
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/builtins/profiles/130.frag | 84
> +-
> src/gl
Looks good Brian. The rest of the series looks good too AFAICT, although some
of the modules are a bit outside my familiarity zone.
Jose
- Original Message -
> v2: check if pipe_buffer_map() returns NULL, and return NULL from
> svga_vbuf_render_map_vertices(). Per Jose's suggestion.
> -
v2: check if pipe_buffer_map() returns NULL, and return NULL from
svga_vbuf_render_map_vertices(). Per Jose's suggestion.
---
src/gallium/drivers/svga/svga_swtnl_backend.c | 29 +---
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/svga/svg
None of the code in api_noop.c was used anymore. The new vbo_noop.c
functions are true no-ops. They'll be used to no-op glBegin/End functions
when we run out of VBO memory.
---
src/mesa/SConscript |2 +-
src/mesa/main/api_noop.c | 1089 --
src
---
src/gallium/drivers/svga/svga_swtnl_backend.c | 26
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_swtnl_backend.c
b/src/gallium/drivers/svga/svga_swtnl_backend.c
index 15b1bb5..e583ad0 100644
--- a/src/gallium/drivers/
If the vbuf backend fails to allocate a vertex buffer, don't crash
or assert.
---
src/gallium/auxiliary/draw/draw_pipe_vbuf.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_vbuf.c
b/src/gallium/auxiliary/draw/draw_pipe_vbuf.c
i
Don't crash if we fail to allocate a vertex buffer.
---
src/gallium/auxiliary/util/u_blit.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blit.c
b/src/gallium/auxiliary/util/u_blit.c
index 6a4324b..3a0d7d4 100644
--- a/src/ga
---
src/mesa/state_tracker/st_cb_bitmap.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c
b/src/mesa/state_tracker/st_cb_bitmap.c
index 1a8854b..fa37be0 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/
Previously, if we failed to allocate a VBO (either for display list
compilation or immediate mode rendering) we'd eventually segfault
when trying to map the non-existant buffer or in a glVertex/Color/etc
call when we hit a null pointer.
Now we don't try to map non-existant buffers and if we do fai
Only a handful of functions from api_noop.c are actually used by
the VBO module. Move them to the VBO module. With this change,
none of the code in api_noop.c is actually used anymore.
---
src/mesa/vbo/vbo_exec_api.c | 142 +--
src/mesa/vbo/vbo_save_api.c
On Don, 2011-11-10 at 11:01 +0100, Theiss, Ingo wrote:
>
> The function calls of mesa/state_tracker/st_cb_readpixels.c:382 ->
> st_readpixels and mesa/main/pack.c:552 -> _mesa_pack_rgba_span_float
> clearly stands out when comparing the 32 bit and 64 bit profile.
I'm afraid that's a red herring,
On 9 November 2011 11:33, Eric Anholt wrote:
> With the gl_VertexID support, everything required should now be
> supported.
> ---
> src/mesa/drivers/dri/intel/intel_extensions.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_ext
> This may be a bit slower than before because we're switching from
> per-format compiled loops in GetRow to
> _mesa_unpack_rgba_block_unpack's loop around a callback to unpack a
> pixel. The solution there would be to make _mesa_unpack_rgba_block
> fold the span loop into the format handlers.
Th
On Tue, Nov 1, 2011 at 11:17 PM, Eric Anholt wrote:
> Reviewed-by: Brian Paul
Just as an aside and maybe some way to help me figure out why
this break piglit windowoverlap test on r100, specifically the sub
window drawing stops working.
I bisected to this and its definitely it, I suspect its m
Hi Michel,
thanks for the reply and your suggestions.
It took me a while to figure out how to use and run oprofile but finally I was
able to produce some hopefully useable output.
The function calls of mesa/state_tracker/st_cb_readpixels.c:382 ->
st_readpixels and mesa/main/pack.c:552 -> _mesa
27 matches
Mail list logo
