Fixes these GCC warnings.
osmesa.c: In function ‘osmesa_renderbuffer_storage’:
osmesa.c:417: warning: comparison is always false due to limited range of data
type
osmesa.c:423: warning: comparison is always false due to limited range of data
type
osmesa.c:431: warning: comparison is always false
Dave. Ping.
On Mon, Jan 16, 2012 at 3:46 AM, Jose Fonseca wrote:
> Hi Vinson,
>
> These lines were added by Dave in
>
> commit 1865f341d8f45b389061fc08d2da90b7aa8a6099
> Author: Dave Airlie
> Date: Fri Jan 6 12:23:00 2012 +
>
> draw: clipdistance support (v2)
>
> Add support for usin
On Tue, Jan 24, 2012 at 11:40 AM, Kenneth Graunke wrote:
> On 01/24/2012 10:08 AM, Brian Paul wrote:
>>
>> I've been seeing this error from linker.cpp for a few days now:
>>
>> linker.cpp: In function ‘gl_shader* link_intrastage_shaders(void*,
>> gl_context*, gl_shader_program*, gl_shader**, unsig
It's not clear from the specs why this would be required, but it fixes
the regression in glean/fbo. My theory is that push constant uploads
incrementally fill up the allocated space (with wrapping), but don't
synchronize on previous constant buffers being dereferenced when
overwriting after a wrap
Mesa 8.0-rc2 has been released. This is a release candidate for the 8.0
development release.
The tag in the GIT repository for Mesa 8.0-rc2 is 'mesa-8.0-rc2'.
Mesa 8.0-rc2 is available for download at
ftp://freedesktop.org/pub/mesa/8.0/
md5sums:
c2afdd52e138692db536645fa57f0c87 MesaLib-8.0
in check_index_bounds the comparison needs to be "greater equal" since
contrary to the name _MaxElement is the count of the array.
In vbo_exec_DrawRangeElementsBaseVertex, take into account the basevertex.
As far as I can tell it is completely ok (though maybe stupid) to have
start/end of 100/199,
Core Mesa does this for us, see update_two_size in state.c.
---
src/mesa/state_tracker/st_atom_rasterizer.c | 24 +++-
1 files changed, 3 insertions(+), 21 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_rasterizer.c
b/src/mesa/state_tracker/st_atom_rasterizer.c
in
Am 28.01.2012 01:38, schrieb Marek Olšák:
> Hi everyone,
>
> the subject says it all. This series fixes gl_PointSize with transform
> feedback. There is a new piglit test to verify that a driver does clamping
> properly during rasterization: vs-point_size-zero
>
> I haven't changed Draw, becaus
On 01/27/2012 03:19 PM, Brian Paul wrote:
> Chad,
>
> I'm seeing a bunch of new warnings:
Brian, sorry about that. I forgot a #include, of course. I just pushed the fix.
Chad Versace
chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@
This fixes the gl_PointSize transform feedback test.
---
src/mesa/program/prog_statevars.c | 27 ---
src/mesa/program/prog_statevars.h |1 -
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 49
src/mesa/state_tracker/st_mesa_to_tgsi.c
---
src/gallium/drivers/r600/evergreen_state.c | 10 +-
src/gallium/drivers/r600/evergreend.h |6 ++
src/gallium/drivers/r600/r600_pipe.h |7 +++
src/gallium/drivers/r600/r600_state.c | 10 +-
4 files changed, 31 insertions(+), 2 deletions(-)
di
---
src/gallium/drivers/r300/r300_state.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r300/r300_state.c
b/src/gallium/drivers/r300/r300_state.c
index 33fdf3b..cf0c9d1 100644
--- a/src/gallium/drivers/r300/r300_state.c
+++ b/src/gallium/dri
---
src/gallium/drivers/svga/svga_state_rss.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_rss.c
b/src/gallium/drivers/svga/svga_state_rss.c
index af68d9c..43516fa 100644
--- a/src/gallium/drivers/svga/svga_state_rss.c
+++ b/sr
Hi everyone,
the subject says it all. This series fixes gl_PointSize with transform
feedback. There is a new piglit test to verify that a driver does clamping
properly during rasterization: vs-point_size-zero
I haven't changed Draw, because softpipe and llvmpipe do the clamping
internally some
According to Table 6.17 in the GL 2.1 specification, DEPTH_TEXTURE_MODE,
TEXTURE_COMPARE_MODE, and TEXTURE_COMPARE_FUNC need to be restored on
glPopAttrib(GL_TEXTURE_BIT).
Makes oglconform's shad-compiler advanced.TestShadow2D_VertShader test
a bit less grumbly.
NOTE: This is a candidate for rele
On Fri, 27 Jan 2012 13:29:18 -0800, Kenneth Graunke
wrote:
> On 01/27/2012 01:16 PM, Eric Anholt wrote:
> > We were allocating registers into the MRF hack region, resulting in
> > sparkly renering in a few of the scenes. We could do better
> > allocation by making an MRF class, having MRFs confl
width, height parameter of glTexImage2D() includes: texture image
width + 2 * border (if any). So when doing the texture size check
in _mesa_test_proxy_teximage() width and height should not exceed
maximum supported size for target texture type.
i.e. 1 << (ctx->Const.MaxTextureLevels - 1)
This pat
https://bugs.freedesktop.org/show_bug.cgi?id=45277
--- Comment #1 from Rene Peinthor 2012-01-27 15:37:42 PST
---
can confirm this problem with my 5770, thanks for bisecting
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: -
Chad,
I'm seeing a bunch of new warnings:
In file included from swrast/s_aaline.c:470:
swrast/s_aalinetemp.h: In function ‘aa_general_rgba_plot’:
swrast/s_aalinetemp.h:70: warning: implicit declaration of function
‘_swrast_use_fragment_program’
swrast/s_aatriangle.c: In function ‘_swrast_set_aa_t
https://bugs.freedesktop.org/show_bug.cgi?id=45070
Kenneth Graunke changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 01/27/2012 01:16 PM, Eric Anholt wrote:
We were allocating registers into the MRF hack region, resulting in
sparkly renering in a few of the scenes. We could do better
allocation by making an MRF class, having MRFs conflict with the
corresponding GRFs, and tracking the live intervals of the "
This is the corresponding fix to the previous one for the FS, but I
don't have a particular test for it.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/drivers/dri/i965/brw_vec4.h |1 +
.../drivers/dri/i965/brw_vec4_reg_allocate.cpp |6 +++---
src/mesa/driver
We were allocating registers into the MRF hack region, resulting in
sparkly renering in a few of the scenes. We could do better
allocation by making an MRF class, having MRFs conflict with the
corresponding GRFs, and tracking the live intervals of the "MRF"s and
setting up the conflicts. But this
On Fri, Jan 27, 2012 at 9:52 PM, Eric Anholt wrote:
> On Fri, 27 Jan 2012 00:58:45 +0100, Marek Olšák wrote:
>> On Fri, Jan 27, 2012 at 12:26 AM, Ian Romanick wrote:
>> > It also appears the Unigen may be resolving some of these issues. That may
>> > make the work-arounds irrelevant.
>> >
>> >
On 01/27/2012 12:52 PM, Eric Anholt wrote:
On Fri, 27 Jan 2012 00:58:45 +0100, Marek Olšák wrote:
On Fri, Jan 27, 2012 at 12:26 AM, Ian Romanick wrote:
It also appears the Unigen may be resolving some of these issues. That may
make the work-arounds irrelevant.
http://phoronix.com/forums/sho
On 01/27/2012 12:53 PM, Matt Turner wrote:
Looks OK to me. I've wondered whether we want to import the macro for
checking these things from xorg-util-macros, since we'll probably want to do
this for a few other ones too.
I think that might be good eventually, but there's so much stuff in
confi
> Looks OK to me. I've wondered whether we want to import the macro for
> checking these things from xorg-util-macros, since we'll probably want to do
> this for a few other ones too.
I think that might be good eventually, but there's so much stuff in
configure.ac to be cleaned, I think it should
On Fri, 27 Jan 2012 00:58:45 +0100, Marek Olšák wrote:
> On Fri, Jan 27, 2012 at 12:26 AM, Ian Romanick wrote:
> > It also appears the Unigen may be resolving some of these issues. That may
> > make the work-arounds irrelevant.
> >
> > http://phoronix.com/forums/showthread.php?68411-Unigine-OilR
On 01/27/2012 11:58 AM, Eric Anholt wrote:
After the removal of the dri driver link test, this should help avoid
the original problem that it was designed to catch: The warning about
a missing prototype due to typoing a function name scrolling by in the
Mesa build spew, and you not noticing until
So you want to get OSMesa from Mesa-7.11.2 working with VTK-5.8.0 on
Fedora 15?
You can do without the VTKData lines.
They don't add as many tests as I thought.
# Go somewhere to play around
cd /tmp
# get Mesa
wget ftp://ftp.freedesktop.org/pub/mesa/7.11.2/MesaLib-7.11.2.tar.bz2
# get VTK and
On Fri, Jan 27, 2012 at 8:11 PM, Jon TURNEY wrote:
> On 27/01/2012 08:03, Eric Anholt wrote:
>> On Thu, 26 Jan 2012 16:32:24 -0800 (PST), matts...@kemper.freedesktop.org
>> (Matt Turner) wrote:
>>> Module: Mesa
>>> Branch: master
>>> Commit: 80aa78142d12b21dd7d4f0edc786af98a159a80f
>>> URL:
>
On 27/01/2012 08:03, Eric Anholt wrote:
> On Thu, 26 Jan 2012 16:32:24 -0800 (PST), matts...@kemper.freedesktop.org
> (Matt Turner) wrote:
>> Module: Mesa
>> Branch: master
>> Commit: 80aa78142d12b21dd7d4f0edc786af98a159a80f
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=80aa78142
After the removal of the dri driver link test, this should help avoid
the original problem that it was designed to catch: The warning about
a missing prototype due to typoing a function name scrolling by in the
Mesa build spew, and you not noticing until you try to run an
application and it falls b
On Fri, Jan 27, 2012 at 10:42 AM, Ian Romanick wrote:
> On 01/27/2012 12:57 AM, Jose Fonseca wrote:
>
>> This doesn't make sense from a mathematical POV.
>>
>> If the allowable size is
>>
>> 2^floor(log2(MAX_XX_TEXTURE_**SIZE)) + 2*bt
>>
>> then it doesn't matter whether MAX_XX_TEXTURE_SIZE has
On Tue, 24 Jan 2012 17:55:49 -0800, Ian Romanick wrote:
> On 01/24/2012 03:59 PM, Eric Anholt wrote:
> > A pure swrast-allocated buffer gets an irb of NULL, so we segfaulted
> > in the clear-accum test. Just look at the swrast renderbuffer pointer
> > for handling swrast rbs.
> > ---
> > src/me
On 01/26/2012 12:46 PM, Chad Versace wrote:
On i965, _mesa_ir_link_shader is never called. As a consequence, the
current fragment program (ctx->FragmentProgram->_Current) exists but does
not differ from the fixed function fragment program
(ctx->FragmentProgram->_TexEnvProgram). This confuses swra
For the series,
Reviewed-by: Ian Romanick
On 01/26/2012 07:04 PM, Brian Paul wrote:
GL_UNPACK_LSB_FIRST only applies to bitmap data, not glReadPixels.
---
src/mesa/main/readpix.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/ma
On 01/27/2012 10:36 AM, Jose Fonseca wrote:
- Original Message -
On 01/27/2012 01:33 AM, Jose Fonseca wrote:
Brian,
This is probably right but a tad verbose, and error prone.
I'm not sure what's the best way to simplify this though. It's not
possible to canonize the comparisons beca
On Fri, Jan 27, 2012 at 10:13:54AM -0800, Jose Fonseca wrote:
>
>
> - Original Message -
> > On Fri, Jan 27, 2012 at 09:17:54AM -0800, Jose Fonseca wrote:
> > >
> > >
> > > - Original Message -
> > > > On Mon, Jan 16, 2012 at 2:27 PM, Jose Fonseca
> > > >
> > > > wrote:
> > > >
On 01/27/2012 12:57 AM, Jose Fonseca wrote:
This doesn't make sense from a mathematical POV.
If the allowable size is
2^floor(log2(MAX_XX_TEXTURE_SIZE)) + 2*bt
then it doesn't matter whether MAX_XX_TEXTURE_SIZE has or not the
border with, as the allowable size is still the same for all comm
- Original Message -
> On 01/27/2012 01:33 AM, Jose Fonseca wrote:
> > Brian,
> >
> > This is probably right but a tad verbose, and error prone.
> >
> > I'm not sure what's the best way to simplify this though. It's not
> > possible to canonize the comparisons because there are missing
>
On 01/27/2012 01:33 AM, Jose Fonseca wrote:
Brian,
This is probably right but a tad verbose, and error prone.
I'm not sure what's the best way to simplify this though. It's not
possible to canonize the comparisons because there are missing combinations.
But I think that at least using ternary
2012/1/27 Jose Fonseca :
>
>
> - Original Message -
>> On Fri, Jan 27, 2012 at 07:28, Jose Fonseca
>> wrote:
>> >
>> >
>> > - Original Message -
>> >> On Fri, Jan 27, 2012 at 8:18 AM, Brian Paul
>> >>
>> >> wrote:
>> >> > On Fri, Jan 27, 2012 at 7:40 AM, wrote:
>> >> >> From: Jo
- Original Message -
> On Fri, Jan 27, 2012 at 07:28, Jose Fonseca
> wrote:
> >
> >
> > - Original Message -
> >> On Fri, Jan 27, 2012 at 8:18 AM, Brian Paul
> >>
> >> wrote:
> >> > On Fri, Jan 27, 2012 at 7:40 AM, wrote:
> >> >> From: José Fonseca
> >> >>
> >> >> Should avoi
On 01/26/2012 03:58 PM, Marek Olšák wrote:
Well, we'll see if they fix the benchmarks too. Anyway, I don't see
how this series addresses the issue with gl_InstanceID.
Right. I submitted a spec bug for that, and it should get resolved at
the face-to-face meeting next week.
__
- Original Message -
> On Fri, Jan 27, 2012 at 09:17:54AM -0800, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> > > On Mon, Jan 16, 2012 at 2:27 PM, Jose Fonseca
> > >
> > > wrote:
> > > > Tom,
> > > >
> > > > Looks good in principle!
> > > >
> > > > But I need to test
On 01/27/2012 12:07 AM, Eric Anholt wrote:
> On Thu, 26 Jan 2012 18:29:30 -0800, "Ian Romanick"
> wrote:
>> From: Ian Romanick
>>
>> Eventually this path leads to _intel_batchbuffer_flush. The first
>> thing there is an assertion that nothing is mapped.
>>
>> Fixes the afore mentioned assertion
On Fri, Jan 27, 2012 at 09:17:54AM -0800, Jose Fonseca wrote:
>
>
> - Original Message -
> > On Mon, Jan 16, 2012 at 2:27 PM, Jose Fonseca
> > wrote:
> > > Tom,
> > >
> > > Looks good in principle!
> > >
> > > But I need to test this myself before I can be comfortable w/
> > > merging it
On Fri, Jan 27, 2012 at 07:28, Jose Fonseca wrote:
>
>
> - Original Message -
>> On Fri, Jan 27, 2012 at 8:18 AM, Brian Paul
>> wrote:
>> > On Fri, Jan 27, 2012 at 7:40 AM, wrote:
>> >> From: José Fonseca
>> >>
>> >> Should avoid dangling pointer derreference with
>> >>
>> >> glean --
- Original Message -
> On Mon, Jan 16, 2012 at 2:27 PM, Jose Fonseca
> wrote:
> > Tom,
> >
> > Looks good in principle!
> >
> > But I need to test this myself before I can be comfortable w/
> > merging it into master.
> >
>
> Hi Jose,
>
> Have you had a chance to test this out yet?
Hi
https://bugs.freedesktop.org/show_bug.cgi?id=44618
--- Comment #12 from Matt Turner 2012-01-27 08:10:00 PST
---
(In reply to comment #11)
> I've been seeing your automake related commits and I'm really glad to see
> someone working on this. Are there plans to actually get this done for 8.0
> or
https://bugs.freedesktop.org/show_bug.cgi?id=44618
--- Comment #11 from Thierry Reding
2012-01-27 07:55:01 PST ---
> Looks like I can do something similar!
I've been seeing your automake related commits and I'm really glad to see
someone working on this. Are there plans to actually get this don
2012/1/26 Sanjoy Saha - ERS, HCL Tech :
> Michel,
> As per the below instructions i tried to compile mesa as follows. But i
> get a compilation error in make process. Can you please help me out here ?
>
> ./configure --enable-gallium-egl --with-egl-platforms=drm
> --enable-shared-glapi --with-
On Thu, 26 Jan 2012 13:55:37 -0800, Ian Romanick wrote:
> On 01/26/2012 06:40 AM, Brian Paul wrote:
> > On Tue, Jan 24, 2012 at 10:58 PM, Anuj Phogat wrote:
> >> Color clamping should be enabled in glGetTexImage if texture dataType is
> >> GL_UNSIGNED_NORMALIZED and format is GL_LUMINANCE or GL_L
https://bugs.freedesktop.org/show_bug.cgi?id=44618
--- Comment #10 from Matt Turner 2012-01-27 07:44:46 PST
---
(In reply to comment #9)
>
Thanks!
Looks like I can do something similar!
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this
On Fri, Jan 27, 2012 at 7:57 AM, Jon TURNEY wrote:
> On 27/01/2012 05:06, Matt Turner wrote:
>> Please give this a try.
>>
>> OSMesa is broken with shared-glapi. I'll fix that (it'll be much
>> easier) when I automake glapi.
>
>> +libOSMesa_la_SOURCES = osmesa.c
>> +libOSMesa_la_LDFLAGS = -version
On Mon, Jan 16, 2012 at 2:27 PM, Jose Fonseca wrote:
> Tom,
>
> Looks good in principle!
>
> But I need to test this myself before I can be comfortable w/ merging it into
> master.
>
Hi Jose,
Have you had a chance to test this out yet?
-Tom
> Just a few quick comments inline.
>
> Jose
>
- Original Message -
> On Fri, Jan 27, 2012 at 8:18 AM, Brian Paul
> wrote:
> > On Fri, Jan 27, 2012 at 7:40 AM, wrote:
> >> From: José Fonseca
> >>
> >> Should avoid dangling pointer derreference with
> >>
> >> glean --run results --overwrite --quick --tests texSwizzle
> >> ---
> >>
- Original Message -
> On Fri, Jan 27, 2012 at 2:33 AM, Jose Fonseca
> wrote:
> > Brian,
> >
> > This is probably right but a tad verbose, and error prone.
> >
> > I'm not sure what's the best way to simplify this though. It's not
> > possible to canonize the comparisons because there ar
On Fri, Jan 27, 2012 at 8:18 AM, Brian Paul wrote:
> On Fri, Jan 27, 2012 at 7:40 AM, wrote:
>> From: José Fonseca
>>
>> Should avoid dangling pointer derreference with
>>
>> glean --run results --overwrite --quick --tests texSwizzle
>> ---
>> src/gallium/auxiliary/draw/draw_llvm.c | 5 +++
On Fri, Jan 27, 2012 at 7:40 AM, wrote:
> From: José Fonseca
>
> Should avoid dangling pointer derreference with
>
> glean --run results --overwrite --quick --tests texSwizzle
> ---
> src/gallium/auxiliary/draw/draw_llvm.c | 5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> di
On Fri, Jan 27, 2012 at 2:33 AM, Jose Fonseca wrote:
> Brian,
>
> This is probably right but a tad verbose, and error prone.
>
> I'm not sure what's the best way to simplify this though. It's not possible
> to canonize the comparisons because there are missing combinations.
>
> But I think that a
https://bugs.freedesktop.org/show_bug.cgi?id=45292
Alex Deucher changed:
What|Removed |Added
AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
From: José Fonseca
Should avoid dangling pointer derreference with
glean --run results --overwrite --quick --tests texSwizzle
---
src/gallium/auxiliary/draw/draw_llvm.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/g
On Don, 2012-01-26 at 20:45 +0100, Marek Olšák wrote:
> On Tue, Jan 10, 2012 at 6:20 PM, Jose Fonseca wrote:
> >> On Tue, Jan 10, 2012 at 5:15 PM, Jose Fonseca
> >> wrote:
> >> >
> >> > Also, please provide app name and performance figures w/ this
> >> > change.
> >>
> >> OK. Torcs, the Forza t
On 27/01/2012 05:06, Matt Turner wrote:
> Please give this a try.
>
> OSMesa is broken with shared-glapi. I'll fix that (it'll be much
> easier) when I automake glapi.
> +libOSMesa_la_SOURCES = osmesa.c
> +libOSMesa_la_LDFLAGS = -version-info 8:0:0 #FIXME
> +libOSMesa_la_LIBADD = $(LIBADD)
> +end
Apart of this simplification suggestion, the series looks good to me AFAICT.
Jose
- Original Message -
> Brian,
>
> This is probably right but a tad verbose, and error prone.
>
> I'm not sure what's the best way to simplify this though. It's not
> possible to canonize the comparisons be
Ah. Thanks for investigating this Stephane.
Garbagge collection happens infrequently, and it really needs to destroy
everything.
We should just make sure there are no dangling pointers when it does.
I'll take a closer look.
Jose
- Original Message -
> Ok so I'm thinking of adding a re
Brian,
This is probably right but a tad verbose, and error prone.
I'm not sure what's the best way to simplify this though. It's not possible to
canonize the comparisons because there are missing combinations.
But I think that at least using ternary operators would make the code more
compact
This doesn't make sense from a mathematical POV.
If the allowable size is
2^floor(log2(MAX_XX_TEXTURE_SIZE)) + 2*bt
then it doesn't matter whether MAX_XX_TEXTURE_SIZE has or not the border with,
as the allowable size is still the same for all common values of
MAX_XX_TEXTURE_SIZE.
It would
Michel,
As per the below instructions i tried to compile mesa as follows. But i get
a compilation error in make process. Can you please help me out here ?
./configure --enable-gallium-egl --with-egl-platforms=drm --enable-shared-glapi
--with-gallium-drivers=r600 --enable-gles1
prefi
On Thu, 26 Jan 2012 18:29:30 -0800, "Ian Romanick" wrote:
> From: Ian Romanick
>
> Eventually this path leads to _intel_batchbuffer_flush. The first
> thing there is an assertion that nothing is mapped.
>
> Fixes the afore mentioned assertion failure in piglit's
> fbo-mipmap-copypix, and is re
On Thu, 26 Jan 2012 13:58:43 -0800, Ian Romanick wrote:
> On 01/25/2012 05:51 PM, Eric Anholt wrote:
> > Fixes piglit ARB_copy_buffer-overlap, which previously assertion failed.
>
> Reviewed-by: Ian Romanick
>
> One other orthogonal question below...
>
> > ---
> > src/mesa/main/bufferobj.c |
On Thu, 26 Jan 2012 16:32:24 -0800 (PST), matts...@kemper.freedesktop.org (Matt
Turner) wrote:
> Module: Mesa
> Branch: master
> Commit: 80aa78142d12b21dd7d4f0edc786af98a159a80f
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=80aa78142d12b21dd7d4f0edc786af98a159a80f
>
> Author: Matt
74 matches
Mail list logo
