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 -
On Tue, Nov 1, 2011 at 11:17 PM, Eric Anholt e...@anholt.net wrote:
Reviewed-by: Brian Paul bri...@vmware.com
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
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.
This
On 9 November 2011 11:33, Eric Anholt 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 insertions(+), 1 deletions(-)
diff --git
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, as I
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 +--
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
---
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
+++
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
---
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
---
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
---
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 --
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
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.
---
On 9 November 2011 22:07, Kenneth Graunke kenn...@whitecape.org wrote:
Due to a cut and paste error, these were accidentally misnamed
textureProj() rather than textureProjOffset().
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/builtins/profiles/130.frag | 84
On 9 November 2011 22:07, Kenneth Graunke kenn...@whitecape.org 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
From: Chad Versace chad.vers...@linux.intel.com
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
On Wed, 9 Nov 2011 21:39:19 -0800, Kenneth Graunke kenn...@whitecape.org
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 kenn...@whitecape.org
On 11/10/2011 09:38 AM, Paul Berry wrote:
On 9 November 2011 11:33, Eric Anholt e...@anholt.net
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
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
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 +-
https://bugs.freedesktop.org/show_bug.cgi?id=42516
--- Comment #3 from Brian Paul bri...@vmware.com 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
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)
---
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 @@
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
On Thu, 10 Nov 2011 18:01:46 -0700, Brian Paul bri...@vmware.com 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
---
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 when
27 matches
Mail list logo
