On 09/20/2011 03:34 PM, Eric Anholt wrote:
> Only one failure in piglit on gen6, which is texwrap with bordercolor
> (as usual).
> ---
> docs/relnotes-7.12.html |1 +
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c |1 +
> src/mesa/drivers/dri/intel/intel_contex
https://bugs.freedesktop.org/show_bug.cgi?id=41065
ojab changed:
What|Removed |Added
Attachment #51441|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41065
Summary: Fix build with LLVM-3.0svn
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Mes
https://bugs.freedesktop.org/show_bug.cgi?id=40920
--- Comment #1 from Chia-I Wu 2011-09-20 21:11:06 PDT ---
Does it happen with all drivers (llvmpipe v.s. softpipe)? Do you have a test
case for this bug?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You ar
https://bugs.freedesktop.org/show_bug.cgi?id=40919
Chia-I Wu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Tue, Sep 20, 2011 at 08:30:07PM -0600, Brian Paul wrote:
> On Tue, Sep 20, 2011 at 7:54 PM, Yuanhan Liu
> wrote:
> > On Tue, Sep 20, 2011 at 08:51:45AM -0600, Brian Paul wrote:
> >> From: Brian Paul
> >>
> >> We now raise an GL_INVALID_ENUM in glBegin() if mode is illegal, as was
> >> done in
On Tue, Sep 20, 2011 at 7:54 PM, Yuanhan Liu
wrote:
> On Tue, Sep 20, 2011 at 08:51:45AM -0600, Brian Paul wrote:
>> From: Brian Paul
>>
>> We now raise an GL_INVALID_ENUM in glBegin() if mode is illegal, as was
>> done in Yuanhan Liu's original patch.
>>
>> Take geometry shaders support into acc
On Tue, Sep 20, 2011 at 08:51:45AM -0600, Brian Paul wrote:
> From: Brian Paul
>
> We now raise an GL_INVALID_ENUM in glBegin() if mode is illegal, as was
> done in Yuanhan Liu's original patch.
>
> Take geometry shaders support into account too.
> ---
> src/mesa/main/api_validate.c | 31
On Tue, Sep 20, 2011 at 08:51:26AM -0600, Brian Paul wrote:
> On 09/20/2011 08:36 AM, Brian Paul wrote:
> >On 09/19/2011 08:39 PM, Yuanhan Liu wrote:
> >>On Mon, Sep 19, 2011 at 08:09:09AM -0600, Brian Paul wrote:
> >>>On 09/19/2011 01:02 AM, Yuanhan Liu wrote:
> According to opengl spec, trigg
Variables have types, expression trees have types, but statements don't.
Rather than have a nonsensical field that stays NULL in the base class,
just move it to where it makes sense.
Fix up a few places that lazily used ir_instruction even though they
actually knew the particular subclass.
Signed
Previously, set_callee() performed some assertions about the type of the
ir_call; protecting the bare pointer ensured these checks would be run.
However, ir_call no longer has a type, so the getter and setter methods
don't actually do anything useful. Remove them in favor of accessing
callee dire
This begins the process of cleaning up and un-muddling our IR.
Aside from ir_call, our IR is cleanly split into two classes:
- Statements (typeless; used for side effects, control flow)
- Values (deeply nestable, pure, typed expression trees)
Unfortunately, ir_call confused all this:
- For void f
When translating a call from AST to HIR, we need to decide whether it
can be evaluated to a constant before emitting any code (namely, the
temporary declaration, assignment, and call.)
Soon, ir_call will become a statement taking a dereference of where to
store the return value, rather than an rva
All this does is generate a bogus value with error type; the fact that
it was in ir_call was rather arbitrary to begin with. ir_constant is an
equally arbitrary place. The rationale is that a future commit will
change ir_calls from rvalues to statements, and all uses of this
function expect an rval
Here's a few cleanups to our compiler's IR that I've been wanting to do
for a very long time. With this series, expression trees are finally
guaranteed to be pure; you can no longer put calls with side effects in
them. ir_call is now a statement, rather than a confused hybrid.
I apologize for th
On 20 September 2011 17:09, Eric Anholt wrote:
> On Tue, 20 Sep 2011 15:42:30 -0700, Paul Berry
> wrote:
> > This patch series enables support for gl_ClipDistance in the Intel
> > i965 driver. The first three patches are in mesa core (and hence
> > potentially affect all drivers); the rest are
Hi,
On Tuesday, 20 September 2011, Chris Wilson
wrote:
> Daniel, think you might pop over for the weekend and teach us a thing or
> two about the DRM infrastructure and what it might look like in a year
> or two as more SoC gradually become mainline?
Perhaps. FOSDEM is a great conference and I r
On Tue, 20 Sep 2011 15:42:30 -0700, Paul Berry wrote:
> This patch series enables support for gl_ClipDistance in the Intel
> i965 driver. The first three patches are in mesa core (and hence
> potentially affect all drivers); the rest are i965-specific.
>
> For those of you who aren't concerned w
On 09/20/2011 05:24 PM, Eric Anholt wrote:
Fixes piglit ARB_shader_objects/clear-with-deleted.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39577
---
src/mesa/drivers/common/meta.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/m
On 09/20/2011 04:42 PM, Paul Berry wrote:
This patch series enables support for gl_ClipDistance in the Intel
i965 driver. The first three patches are in mesa core (and hence
potentially affect all drivers); the rest are i965-specific.
For those of you who aren't concerned with the i965 driver,
Fixes piglit ARB_shader_objects/clear-with-deleted.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39577
---
src/mesa/drivers/common/meta.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 1b
https://bugs.freedesktop.org/show_bug.cgi?id=40860
Ian Romanick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
This is necessary for GLSL 1.30 compliance.
---
src/mesa/drivers/dri/intel/intel_context.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 2589ee5..30bf2b2 100644
--- a/src/mes
Previously, we conditionally set up the SF pipline stage with a
urb_entry_read_offset of 2 when clipping was in use, and 1 otherwise,
causing the clip distance VUE slots to be skipped if present. This
was an extremely minor savings (it saved the SF unit from reading 2
vec4s out of the URB, but it
When gl_ClipDistance is in use, the contents of the gl_ClipDistance
array just need to be copied directly into the clip distance VUE
slots, so we re-use the code that copies all other generic VUE slots
(this has been extracted to its own method). When gl_ClipDistance is
not in use, the vertex shad
When the vertex shader writes to gl_ClipDistance, we do clipping based
on clip distances rather than user clip planes, so don't waste push
constant space storing user clip planes that won't be used.
---
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp |2 +-
src/mesa/drivers/dri/i965/brw_vs.c
i965 requires gl_ClipDistance to be formatted as an array of 2 vec4's
(as opposed to an array of 8 floats), so enable the lowering pass that
performs this conversion.
---
src/mesa/drivers/dri/i965/brw_context.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drive
In order to support 8 clip distances, we need to properly decode when
the user sets the GL_CLIP_DISTANCE6 and GL_CLIP_DISTANCE7 enable
flags.
For clarity, this patch changes the names GL_CLIP_PLANE[0-5] in the
switch statement to the equivalent names GL_CLIP_DISTANCE[0-5], since
the GL_CLIP_PLANE
This patch assigns enumerated values for gl_ClipDistance in the
gl_vert_result and gl_frag_attrib enums, so that driver back-ends can
assign gl_ClipDistance to the appropriate hardware registers. It also
adjusts the functions _mesa_vert_result_to_frag_attrib() and
_mesa_frag_attrib_to_vert_result(
GLSL 1.30 requires us to use gl_ClipDistance for clipping if the
vertex shader contains a static write to it, and otherwise use
user-defined clipping planes. Since the driver needs to behave
differently in these two cases, we need a flag to record whether the
shader has written to gl_ClipDistance.
This patch series enables support for gl_ClipDistance in the Intel
i965 driver. The first three patches are in mesa core (and hence
potentially affect all drivers); the rest are i965-specific.
For those of you who aren't concerned with the i965 driver, you will
probably be most interested in look
Only one failure in piglit on gen6, which is texwrap with bordercolor
(as usual).
---
docs/relnotes-7.12.html |1 +
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |1 +
src/mesa/drivers/dri/intel/intel_context.c |3 +++
src/mesa/drivers/dri/intel/intel_
This doesn't cover support for this format as a renderbuffer yet. The
spec allows implementations to not support it, though it is something
we do want to support.
Only one failure in piglit on gen6, which is texwrap with bordercolor
(as usual).
---
docs/relnotes-7.12.html
https://bugs.freedesktop.org/show_bug.cgi?id=35268
--- Comment #6 from Nicholas Miell 2011-09-20 15:15:58 PDT
---
Also, the test case is wrong, the main executable is compiled PIC for no reason
and the shared object is compiled without PIC, which barely works on i386 and
won't even link on AMD64
On Tue, 20 Sep 2011 15:37:20 -0400, Matt Turner wrote:
> One more nail in the coffin of XF86VidMode.
>
> Signed-off-by: Matt Turner
> ---
> I'm not sure how to test this, but the translation from XF86VidMode
> Xrandr seems to be pretty straightforward. Almost certainly there's
> something wrong
https://bugs.freedesktop.org/show_bug.cgi?id=35268
--- Comment #5 from Nicholas Miell 2011-09-20 14:15:18 PDT
---
Mesa is explicitly allowed to use intial-exec, even when dlopen()ed.
See: http://www.redhat.com/archives/phil-list/2003-February/msg00077.html
--
Configure bugmail: https://bugs.fr
One more nail in the coffin of XF86VidMode.
Signed-off-by: Matt Turner
---
I'm not sure how to test this, but the translation from XF86VidMode
Xrandr seems to be pretty straightforward. Almost certainly there's
something wrong with it, as this is the first client-side X programming
I've done, and
On 09/20/2011 01:05 PM, Eric Anholt wrote:
On Tue, 20 Sep 2011 11:56:49 -0600, Brian Paul wrote:
From: Brian Paul
Use _mesa_set_enable() to avoid a redudant context lookup.
Need to disable the texture target in decompress_texture_image() so the
unit isn't still enabled after glGetTexImage() re
On Tue, 20 Sep 2011 11:56:49 -0600, Brian Paul wrote:
> From: Brian Paul
>
> Use _mesa_set_enable() to avoid a redudant context lookup.
> Need to disable the texture target in decompress_texture_image() so the
> unit isn't still enabled after glGetTexImage() returns. Arguably, the
> meta restor
The mismatch below caused ActiveProgram to be incorrectly saved/restored:
_meas_meta_begin:
line 465) ActiveShader := gl_shader_state::CurrentFragmentProgram
_mesa_meta_end:
line 741) gl_shader_state::ActiveProgram := ActiveShader
This patch fixes it to be:
_meas_meta
On 09/20/2011 10:40 AM, Michel Dänzer wrote:
On Don, 2011-09-15 at 13:01 -0600, Brian Paul wrote:
On 09/15/2011 10:08 AM, Michel Dänzer wrote:
On Don, 2011-09-15 at 09:01 -0600, Brian Paul wrote:
On 09/15/2011 04:55 AM, Michel Dänzer wrote:
On Mit, 2011-09-14 at 11:44 -0600, Brian Paul wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=41023
Alexandre Demers changed:
What|Removed |Added
AssignedTo|alexandre.f.dem...@gmail.co |mesa-dev@lists.freedesktop.
From: Brian Paul
Avoids an extra context lookup.
---
src/mesa/drivers/common/meta.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index be1953a..9703475 100644
--- a/src/mesa/drivers/common/meta.c
From: Brian Paul
Use _mesa_set_enable() to avoid a redudant context lookup.
Need to disable the texture target in decompress_texture_image() so the
unit isn't still enabled after glGetTexImage() returns. Arguably, the
meta restore code should do this, but it doesn't.
---
src/mesa/drivers/common
https://bugs.freedesktop.org/show_bug.cgi?id=41023
Alexandre Demers changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|mesa-dev@
https://bugs.freedesktop.org/show_bug.cgi?id=41023
--- Comment #2 from Alexandre Demers 2011-09-20
09:44:39 PDT ---
Created an attachment (id=51410)
View: https://bugs.freedesktop.org/attachment.cgi?id=51410
Review: https://bugs.freedesktop.org/review?bug=41023&attachment=51410
Initializing "
On Don, 2011-09-15 at 13:01 -0600, Brian Paul wrote:
> On 09/15/2011 10:08 AM, Michel Dänzer wrote:
> > On Don, 2011-09-15 at 09:01 -0600, Brian Paul wrote:
> >> On 09/15/2011 04:55 AM, Michel Dänzer wrote:
> >>> On Mit, 2011-09-14 at 11:44 -0600, Brian Paul wrote:
> On 09/14/2011 11:16 AM, Mi
https://bugs.freedesktop.org/show_bug.cgi?id=41023
Alexandre Demers changed:
What|Removed |Added
Summary|d3d1x: error when building |[bisected] d3d1x: error
On 19 September 2011 23:13, Kenneth Graunke wrote:
> builtin_stubs.cpp is only supposed to be used for builtin_compiler. It
> contains a stub version of _mesa_glsl_initialize_functions() that does
> nothing.
>
> libglsl.a already contains builtin_function.cpp, the generated file that
> contains
On 20 September 2011 01:05, Tolga Dalman wrote:
>
> I wouldn't exactly call it 'optimisation' :) However, I feel a bit uneasy
> about using the == operator on float variables
> as this could lead to unexpected errors.
>
> Best regards
> Tolga Dalman
>
Tolga, your uneasiness is certainly justified
From: Brian Paul
We now raise an GL_INVALID_ENUM in glBegin() if mode is illegal, as was
done in Yuanhan Liu's original patch.
Take geometry shaders support into account too.
---
src/mesa/main/api_validate.c | 31 ++-
src/mesa/main/api_validate.h |5 +
src/
On 09/20/2011 08:36 AM, Brian Paul wrote:
On 09/19/2011 08:39 PM, Yuanhan Liu wrote:
On Mon, Sep 19, 2011 at 08:09:09AM -0600, Brian Paul wrote:
On 09/19/2011 01:02 AM, Yuanhan Liu wrote:
According to opengl spec, trigger GL_INVALID_ENUM error if mode is
not
one of those valid primitive mode w
On Tue, 2011-09-20 at 16:35 +0200, Roland Scheidegger wrote:
> Am 20.09.2011 16:15, schrieb Keith Whitwell:
> > On Tue, 2011-09-20 at 16:02 +0200, Roland Scheidegger wrote:
> >> Am 20.09.2011 12:35, schrieb Keith Whitwell:
> >>> On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
> There was a dis
Am 20.09.2011 16:35, schrieb Roland Scheidegger:
> Am 20.09.2011 16:15, schrieb Keith Whitwell:
>> On Tue, 2011-09-20 at 16:02 +0200, Roland Scheidegger wrote:
>>> Am 20.09.2011 12:35, schrieb Keith Whitwell:
On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
> There was a discussion some mon
On 09/19/2011 08:39 PM, Yuanhan Liu wrote:
On Mon, Sep 19, 2011 at 08:09:09AM -0600, Brian Paul wrote:
On 09/19/2011 01:02 AM, Yuanhan Liu wrote:
According to opengl spec, trigger GL_INVALID_ENUM error if mode is not
one of those valid primitive mode while calling glBegin.
Signed-off-by: Yuanh
Am 20.09.2011 16:15, schrieb Keith Whitwell:
> On Tue, 2011-09-20 at 16:02 +0200, Roland Scheidegger wrote:
>> Am 20.09.2011 12:35, schrieb Keith Whitwell:
>>> On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
There was a discussion some months ago about using -fno-builtin-memcmp for
impro
On Tue, 2011-09-20 at 16:02 +0200, Roland Scheidegger wrote:
> Am 20.09.2011 12:35, schrieb Keith Whitwell:
> > On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
> >> There was a discussion some months ago about using -fno-builtin-memcmp for
> >> improving memcmp performance:
> >> http://lists.freed
On 09/19/2011 11:32 PM, Yuanhan Liu wrote:
Trigger GL_INVALID_ENUM error if the face paramter is not a valid value.
Trigger GL_INVALID_VALUE error if the GL_SHININESS value is out side
[0, ctx->Constant.MaxShiniess].
v2: fix the max shininess value.
v3: suggested by Brian, move the face check
Am 20.09.2011 12:35, schrieb Keith Whitwell:
> On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
>> There was a discussion some months ago about using -fno-builtin-memcmp for
>> improving memcmp performance:
>> http://lists.freedesktop.org/archives/mesa-dev/2011-June/009078.html
>>
>> Since then, wa
From: Nicholas Miell
Add support for NV_fog_distance to the NV10 and NV20 drivers.
[ Francisco Jerez: Fix fog coord. signedness for
GL_EYE_RADIAL_NV/GL_EYE_PLANE on nv20 ]
---
Nicholas Miell writes:
> This has not been tested on real hardware. I have no idea if it works.
The nv10 implementa
On Tue, Sep 20, 2011 at 02:33:08PM +0300, Alon Levy wrote:
> On Tue, Sep 20, 2011 at 12:32:21PM +0200, Luc Verhaegen wrote:
> > On Tue, Sep 20, 2011 at 12:18:15PM +0300, Alon Levy wrote:
> > > On Tue, Sep 13, 2011 at 10:49:33PM +0200, Luc Verhaegen wrote:
> > > > ...
> > > > deliver. So, with a de
Hi,
On 09/20/2011 12:57 PM, Luc Verhaegen wrote:
On Tue, Sep 20, 2011 at 11:41:48AM +0100, Daniel Stone wrote:
Hi,
On Tuesday, 20 September 2011, Luc Verhaegen wrote:
This sound like a rather redhat specific topic. How certain are you that
redhat is going to send you to FOSDEM, and if they d
On Tue, Sep 20, 2011 at 12:32:21PM +0200, Luc Verhaegen wrote:
> On Tue, Sep 20, 2011 at 12:18:15PM +0300, Alon Levy wrote:
> > On Tue, Sep 13, 2011 at 10:49:33PM +0200, Luc Verhaegen wrote:
> > > ...
> > > deliver. So, with a deadline of oktober 1st, i am now asking for 6
> > > people (basically
On Tue, Sep 20, 2011 at 12:12:17PM +0100, Chris Wilson wrote:
> On Tue, 13 Sep 2011 22:49:33 +0200, Luc Verhaegen wrote:
> > So... After our terrible showing in 2010, i now need more to convince
> > the FOSDEM organizers that we are worth of a DevRoom, that we can
> > deliver. So, with a deadlin
On Tue, 13 Sep 2011 22:49:33 +0200, Luc Verhaegen wrote:
> So... After our terrible showing in 2010, i now need more to convince
> the FOSDEM organizers that we are worth of a DevRoom, that we can
> deliver. So, with a deadline of oktober 1st, i am now asking for 6
> people (basically fill up s
On Tue, Sep 20, 2011 at 11:41:48AM +0100, Daniel Stone wrote:
> Hi,
>
> On Tuesday, 20 September 2011, Luc Verhaegen wrote:
> > This sound like a rather redhat specific topic. How certain are you that
> > redhat is going to send you to FOSDEM, and if they don't, are you coming
> > regardless?
>
Hi,
On Tuesday, 20 September 2011, Luc Verhaegen wrote:
> This sound like a rather redhat specific topic. How certain are you that
> redhat is going to send you to FOSDEM, and if they don't, are you coming
> regardless?
In much the same way that every RadeonHD talk was completely
Novell-specific
On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
> There was a discussion some months ago about using -fno-builtin-memcmp for
> improving memcmp performance:
> http://lists.freedesktop.org/archives/mesa-dev/2011-June/009078.html
>
> Since then, was it properly addressed in mesa or the flag is stil
On Tue, Sep 20, 2011 at 12:18:15PM +0300, Alon Levy wrote:
> On Tue, Sep 13, 2011 at 10:49:33PM +0200, Luc Verhaegen wrote:
> > ...
> > deliver. So, with a deadline of oktober 1st, i am now asking for 6
> > people (basically fill up saturday afternoon) to step up and promise to
> > hold a talk a
There was a discussion some months ago about using -fno-builtin-memcmp for
improving memcmp performance:
http://lists.freedesktop.org/archives/mesa-dev/2011-June/009078.html
Since then, was it properly addressed in mesa or the flag is still
recommended? If so, what about adding it in configure.a
Thanks for the info.
I'll post the bug as soon as it crashes again :)
David
2011/9/20 Michel Dänzer
> On Mon, 2011-09-19 at 11:29 +0200, David Mills wrote:
> >
> > I'm currently experiencing random hangs using mesa-git and r600g.
> >
> >
> > The computer seems to be still active, but the displ
On Tue, Sep 13, 2011 at 10:49:33PM +0200, Luc Verhaegen wrote:
> (after my short talk here at XDC chicago, let's get this out to
> everyone)
>
> It's time again to start planning for the next FOSDEM. After our poor
> showing in 2010 (where in the end openmoko got given half our time, as
> we ha
On Tue, 20 Sep 2011 00:17:37 -0700 (PDT)
Michal Krol wrote:
> - Original Message -
> > On Sun, 11 Sep 2011 13:05:38 +0200, Tolga Dalman
> > wrote:
> > > Hi Kenneth,
> > >
> > > On Fri, 9 Sep 2011 14:41:45 -0700
> > > Kenneth Graunke wrote:
> > >
> > > > - if (reg->type == BRW_REGIS
- Original Message -
> On Sun, 11 Sep 2011 13:05:38 +0200, Tolga Dalman
> wrote:
> > Hi Kenneth,
> >
> > On Fri, 9 Sep 2011 14:41:45 -0700
> > Kenneth Graunke wrote:
> >
> > > - if (reg->type == BRW_REGISTER_TYPE_F) {
> > > - return reg->imm.f == 0.0;
> > > + if (type == BRW_R
On Mon, 2011-09-19 at 11:29 +0200, David Mills wrote:
>
> I'm currently experiencing random hangs using mesa-git and r600g.
>
>
> The computer seems to be still active, but the display doesn't
> respond.
>
>
> I have the means to connect to the machine via ssh, to execute
> debugging commands
75 matches
Mail list logo
