On Fri, May 31, 2013 at 1:09 AM, Chia-I Wu wrote:
> On Fri, May 31, 2013 at 3:48 PM, Vinson Lee wrote:
>> On Fri, May 31, 2013 at 12:35 AM, Chia-I Wu wrote:
>>> On Fri, May 31, 2013 at 2:59 PM, Vinson Lee wrote:
Fixes "Uninitialized pointer read" defect reported by Coverity.
>>> This looks
On Sat, Jun 1, 2013 at 2:42 AM, Roland Scheidegger 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
>>> wrote:
Am 31.05.2013 23:43, schrieb srol...@vmware.com:
> From: Roland Sch
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]
st_mesa_
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
interpolation-non
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
>> wrote:
>>> Am 31.05.2013 23:43, schrieb srol...@vmware.com:
From: Roland Scheidegger
Since pipe_surface already has all the necessa
From: Roland Scheidegger
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. Valgrind probably didn'
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
On 01.06.2013 01:02, Alex Deucher wrote:
> On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger
> wrote:
>> Am 31.05.2013 23:43, schrieb srol...@vmware.com:
>>> From: Roland Scheidegger
>>>
>>> Since pipe_surface already has all the necessary fields no interface
>>> changes are necessary except a
On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger wrote:
> Am 31.05.2013 23:43, schrieb srol...@vmware.com:
>> From: Roland Scheidegger
>>
>> Since pipe_surface already has all the necessary fields no interface
>> changes are necessary except adding a new shader semantic value
>> (TGSI_SEMANTIC
Am 31.05.2013 23:43, schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> 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
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
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
dri2_flush_front_buffe
From: Roland Scheidegger
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 d3d10 is naming
"RE
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 i
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
e
---
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 @@ link_assign_u
From: Roland Scheidegger
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 insertions(+), 2 dele
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 lan
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 in
From: Roland Scheidegger
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 function, skip exec
https://bugs.freedesktop.org/show_bug.cgi?id=65173
--- Comment #13 from José Fonseca ---
(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!
--
You are rece
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 elsewhe
On Fri, May 31, 2013 at 10:18 AM, José Fonseca 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 be
> necessary to pass
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.
_
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 verte
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
On 29 May 2013 14:19, Ville Syrjälä 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 color cle
https://bugs.freedesktop.org/show_bug.cgi?id=65173
--- Comment #12 from Brian Paul ---
Created attachment 80099
--> https://bugs.freedesktop.org/attachment.cgi?id=80099&action=edit
patch which generates GL_INVALID_ENUM
How about this patch? It generates GL_INVALID_OPERATION if there's no colo
https://bugs.freedesktop.org/show_bug.cgi?id=60518
--- Comment #9 from Brian Paul ---
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 patch:
diff --git a/sr
The change looks OK to me.
Reviewed-by: Brian Paul
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=mesa&arch=powerpc&ver=9.1.3-1&stamp=1369778584
Andreas.
2013/5/30 Andreas Boll mailto:andreas.b
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 prec
FYI here is the full build log of the failing build.
https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=powerpc&ver=9.1.3-1&stamp=1369778584
Andreas.
2013/5/30 Andreas Boll
> This fixes the following build errors on powerpc:
>
> CC glapi_dispatch.lo
> In file included from glapi
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");
>_mesa_BindAttribLocation(mipmap->Sha
On Fri, May 31, 2013 at 3:48 PM, Vinson Lee wrote:
> On Fri, May 31, 2013 at 12:35 AM, Chia-I Wu wrote:
>> On Fri, May 31, 2013 at 2:59 PM, Vinson Lee wrote:
>>> Fixes "Uninitialized pointer read" defect reported by Coverity.
>> This looks like a false alarm, as shaders are not read when
>> num_
On Fri, May 31, 2013 at 12:35 AM, Chia-I Wu wrote:
> On Fri, May 31, 2013 at 2:59 PM, Vinson Lee 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?
>
On Fri, May 31, 2013 at 2:59 PM, Vinson Lee 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
> ---
> src/gallium/drivers/ilo/i
Fixes "Uninitialized pointer read" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
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
index 33da429..f071292
37 matches
Mail list logo
