https://bugs.freedesktop.org/show_bug.cgi?id=65173
--- Comment #11 from José Fonseca jfons...@vmware.com ---
(In reply to comment #10)
What does nVidia proprietary driver return for
IMPLEMENTATION_COLOR_READ_{FORMAT,TYPE} on that call? That is, what is the
output of
glretrace -D 137078
Fixes Uninitialized pointer read defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/drivers/ilo/ilo_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/ilo/ilo_state.c
b/src/gallium/drivers/ilo/ilo_state.c
On Fri, May 31, 2013 at 2:59 PM, Vinson Lee v...@freedesktop.org wrote:
Fixes Uninitialized pointer read defect reported by Coverity.
This looks like a false alarm, as shaders are not read when
num_shaders is zero. Does the report give more details?
Signed-off-by: Vinson Lee
On Fri, May 31, 2013 at 12:35 AM, Chia-I Wu olva...@gmail.com wrote:
On Fri, May 31, 2013 at 2:59 PM, Vinson Lee v...@freedesktop.org wrote:
Fixes Uninitialized pointer read defect reported by Coverity.
This looks like a false alarm, as shaders are not read when
num_shaders is zero. Does the
On Fri, May 31, 2013 at 3:48 PM, Vinson Lee v...@freedesktop.org wrote:
On Fri, May 31, 2013 at 12:35 AM, Chia-I Wu olva...@gmail.com wrote:
On Fri, May 31, 2013 at 2:59 PM, Vinson Lee v...@freedesktop.org wrote:
Fixes Uninitialized pointer read defect reported by Coverity.
This looks like a
https://bugs.freedesktop.org/show_bug.cgi?id=60518
--- Comment #8 from cor...@gmx.net ---
(In reply to comment #7)
I suspect the problem are these lines in setup_glsl_generate_mipmap():
_mesa_BindAttribLocation(mipmap-ShaderProg, 0, position);
FYI here is the full build log of the failing build.
https://buildd.debian.org/status/fetch.php?pkg=mesaarch=powerpcver=9.1.3-1stamp=1369778584
Andreas.
2013/5/30 Andreas Boll andreas.boll@gmail.com
This fixes the following build errors on powerpc:
CC glapi_dispatch.lo
In file
This patch adds support for some math optimizations that are generally
considered unsafe, that's why they are currently disabled for compute
shaders.
GL requirements are less strict, so they are enabled for
for GL shaders by default. In case of any issues with
applications that rely on higher
The change looks OK to me.
Reviewed-by: Brian Paul bri...@vmware.com
On 05/31/2013 04:29 AM, Andreas Boll wrote:
FYI here is the full build log of the failing build.
https://buildd.debian.org/status/fetch.php?pkg=mesaarch=powerpcver=9.1.3-1stamp=1369778584
Andreas.
2013/5/30 Andreas Boll
https://bugs.freedesktop.org/show_bug.cgi?id=60518
--- Comment #9 from Brian Paul bri...@vmware.com ---
Jose, I think it would be more symmetric with the peer
setup_ff_generate_mipmap() function if we just enabled the vertex arrays when
we create the vertex array object. So, how about this
https://bugs.freedesktop.org/show_bug.cgi?id=65173
--- Comment #12 from Brian Paul bri...@vmware.com ---
Created attachment 80099
-- https://bugs.freedesktop.org/attachment.cgi?id=80099action=edit
patch which generates GL_INVALID_ENUM
How about this patch? It generates GL_INVALID_OPERATION if
On 29 May 2013 14:19, Ville Syrjälä syrj...@sci.fi wrote:
On Wed, May 29, 2013 at 01:39:00PM -0700, Paul Berry wrote:
I started this discussion with just some of the Intel folks, and Eric
suggested I bring it to the mesa-dev list.
The short version is: in my efforts to implement fast
https://bugs.freedesktop.org/show_bug.cgi?id=60518
--- Comment #10 from cor...@gmx.net ---
(In reply to comment #9)
Jose, I think it would be more symmetric with the peer
setup_ff_generate_mipmap() function if we just enabled the vertex arrays
when we create the vertex array object. So, how
Before, on the second call to GenerateMipmap were enabling two
vertex arrays for the current vertex array object, rather than
the private generate-mipmap vertex array object. This caused
things to blow up elsewhere.
This patch moves the array enables into the block where the
generate-mipmap
Two security fixes were applied recently (CVE-2013-1993), it would be nice to
see a new mesa stable release with these fixes applied.
Thanks.
--
Laurent Carlier
ArchLinux Trusted User
http://www.archlinux.org
signature.asc
Description: This is a digitally signed message part.
On Fri, May 31, 2013 at 10:18 AM, José Fonseca jose.r.fons...@gmail.com wrote:
I'd support such change. Be it through GL_GREMEDY_string_marker, or
ARB_debug_output's glDebugMessageInsertARB(DEBUG_SOURCE_THIRD_PARTY_ARB,
...), or KHR_debug's glPushDebugGroup(). A Gallium interface change would
Yeah, that looks even better than my fix.
Jose
- Original Message -
Before, on the second call to GenerateMipmap were enabling two
vertex arrays for the current vertex array object, rather than
the private generate-mipmap vertex array object. This caused
things to blow up elsewhere.
https://bugs.freedesktop.org/show_bug.cgi?id=65173
--- Comment #13 from José Fonseca jfons...@vmware.com ---
(In reply to comment #12)
How about this patch? It generates GL_INVALID_OPERATION if there's no color
read buffer. It also cleans up both functions in general.
Patch looks good to me!
From: Roland Scheidegger srol...@vmware.com
For rendering to buffers, we cannot have any y alignment.
So make sure that tile clear commands only clear up to the fb width/height,
not more (do this for all resources actually as clearing more seems
pointless for other resources too). For the jit fs
On 05/31/2013 08:18 AM, Brian Paul wrote:
Before, on the second call to GenerateMipmap were enabling two
vertex arrays for the current vertex array object, rather than
the private generate-mipmap vertex array object. This caused
things to blow up elsewhere.
This patch moves the array enables
On 05/31/2013 08:46 AM, Laurent Carlier wrote:
Two security fixes were applied recently (CVE-2013-1993), it would be nice to
see a new mesa stable release with these fixes applied.
There's another about to land. I'm expecting there will be 9.1.4 next
week. I'll pick the commits that have
From: Roland Scheidegger srol...@vmware.com
One of the assertion made no sense for buffer rendertargets
(due to the union), so drop it. (The same assertion is present already in
the path for texture surfaces later.).
---
src/gallium/drivers/llvmpipe/lp_texture.c |4 ++--
1 file changed, 2
---
src/glsl/link_uniforms.cpp | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index ad63668..54d54cf 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -640,7 +640,9 @@
We were counting uniforms located in UBOs against the default uniform
block limit, while not doing any counting against the specific combined
limit.
Note that I couldn't quite find justification for the way I did this, but
I think it's the only sensible thing: The spec talks about components, so
Fixes piglit test spec/!OpenGL 1.0/gl-1.0-front-invalidate-back
---
This patch depends on [PATCH 2/2] intel: flush fake front buffer more
robustly., which was sent to mesa-dev yesterday and is still awaiting
review.
src/mesa/drivers/dri/intel/intel_context.c | 9 +
1 file changed, 9
From: Roland Scheidegger srol...@vmware.com
Since pipe_surface already has all the necessary fields no interface
changes are necessary except adding a new shader semantic value
(TGSI_SEMANTIC_LAYER), though add a pipe capability bit for it as well.
(Note that what GL knows as gl_Layer variable
After my recent work on front buffer rendering I decided to try a piglit
run with PIGLIT_PLATFORM=x11_egl to see whether front buffer rendering
works with EGL. It doesn't, and I tracked the problem down to this
function, from src/egl/drivers/dri2/platform_x11.c:
static void
When a gl_client_array is created with glColorPointer,
gl_client_array::Normalized is true. This caused the translation from the
gl_client_array's type to a BRW_SURFACEFORMAT to assertion fail.
Fixes the spinning cube's color in Android 4.2's ApiDemos.apk,
Graphics OpenGL ES.
Fixes assertion
Am 31.05.2013 23:43, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Since pipe_surface already has all the necessary fields no interface
changes are necessary except adding a new shader semantic value
(TGSI_SEMANTIC_LAYER), though add a pipe capability bit for it as
On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 31.05.2013 23:43, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Since pipe_surface already has all the necessary fields no interface
changes are necessary except adding a new shader
On 01.06.2013 01:02, Alex Deucher wrote:
On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 31.05.2013 23:43, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Since pipe_surface already has all the necessary fields no interface
changes
https://bugs.freedesktop.org/show_bug.cgi?id=65224
Priority: medium
Bug ID: 65224
Keywords: regression
CC: mar...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: piglit arb_uniform_buffer_object-maxuniformblocksize
From: Roland Scheidegger srol...@vmware.com
Surprising this bug survived so long, we were missing a clamp (in the
linear filtering version).
(Valgrind complained a lot about invalid reads with piglit texwrap,
I've also seen spurios failures in this test which might have
happened due to this.
Am 01.06.2013 01:22, schrieb Christoph Bumiller:
On 01.06.2013 01:02, Alex Deucher wrote:
On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 31.05.2013 23:43, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Since pipe_surface already
https://bugs.freedesktop.org/show_bug.cgi?id=65225
Priority: medium
Bug ID: 65225
Keywords: regression
CC: za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] piglit
https://bugs.freedesktop.org/show_bug.cgi?id=65226
Priority: medium
Bug ID: 65226
Keywords: have-backtrace, regression
CC: mar...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe]
On Sat, Jun 1, 2013 at 2:42 AM, Roland Scheidegger srol...@vmware.com wrote:
Am 01.06.2013 01:22, schrieb Christoph Bumiller:
On 01.06.2013 01:02, Alex Deucher wrote:
On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 31.05.2013 23:43, schrieb
37 matches
Mail list logo
