This patch enables the multisampling parameters
GL_SAMPLE_ALPHA_TO_COVERAGE and GL_SAMPLE_ALPHA_TO_ONE, which allow
the fragment shader's alpha output to be converted into a sample
coverage mask and ignored for blending. i965 supports these
parameters through the BLEND_STATE structure.
The GL spe
This patch enables glSampleCoverage() functionality, which allows the
client program to specify that only a portion of the samples be lit up
when performing multisampled rendering. i965 supports
glSampleCoverage() through the 3DSTATE_SAMPLE_MASK command packet,
which allows the driver to specify a
https://bugs.freedesktop.org/show_bug.cgi?id=51335
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 06/21/2012 08:30 AM, Olivier Galibert wrote:
On Wed, Jun 20, 2012 at 01:44:14PM +0100, Roland Scheidegger wrote:
A lot of code I just glossed over it, but seems to look ok other than
the (performance) implications this might have.
Actually whether there's a performance implication is not ob
The GLSL linker code in assign_varying_locations() counts up the
number of varying variables and checks the count against the
ctx->Const.MaxVarying limit.
I know we've had problems with this in the past but I think there's
another issue.
In the case of fragment shaders we're also counting va
It was only no-oping the clear() function, not actual triangle
rasterization. Move the no_rast field from lp_context down into
lp_rasterizer so it's accessible where it's needed.
---
src/gallium/drivers/llvmpipe/lp_clear.c |3 --
src/gallium/drivers/llvmpipe/lp_context.c |6
sr
On 06/22/2012 12:18 PM, Brian Paul wrote:
> So that formats such as "%llx" are understood.
> ---
> src/mesa/main/imports.h | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
> index c0b6cec..9fb6ae8 100644
> --
So that formats such as "%llx" are understood.
---
src/mesa/main/imports.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index c0b6cec..9fb6ae8 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
On 06/22/2012 11:13 AM, Kenneth Graunke wrote:
On 06/22/2012 10:07 AM, Jose Fonseca wrote:
Looks good.
Alternatively we could
#ifdef __MINGW32__
#define fprintf __mingw_fprintf()
#endif
in an header like imports.hpp so it can be used everywhere in mesa.
Jose
I generally prefer tha
i965 hardware doesn't do centroid interpolation correctly on unlit
pixels, causing incorrect values for derivatives near triangle edges.
To work around this problem, after doing centroid interpolation, we
replace the centroid-interpolated values for unlit pixels with
non-centroid-interpolated value
In order to compute centroid varyings correctly, the fragment shader
needs to be able to load the current pixel/sample mask into a flag
register. This patch adds an opcode to the fragment shader back-end
to do this; the opcode gets translated into the instruction
mov(1) f0<1>UW g1.14<0,1,0>UW
This patch causes the fragment shader to be configured correctly (and
the correct code to be generated) for centroid interpolation. This
required two changes: brw_compute_barycentric_interp_modes() needs to
determine when centroid barycentric coordinates need to be included in
the pixel shader thr
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 23 +++
src/mesa/drivers/dri/i965/brw_fs.h |2 ++
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 43efd68..c3f851e 100644
--- a/
To save time, we only instruct the clip stage of the pipeline to
compute noperspective barycentric coordinates if those coordinates are
needed by the fragment shader. Previously, we would determine whether
the coordinates were needed by seeing whether the fragment shader used
the BRW_WM_NONPERSPEC
This bitfield tells the back-ends which of a fragment shader's inputs
require centroid interpolation. It is only set for GLSL fragment
shaders, since assembly fragment shaders don't support centroid
interpolation.
---
src/glsl/ir_set_program_inouts.cpp |6 +-
src/mesa/main/mtypes.h
This patch series implements centroid interpolation on i965. Patch
1 is the only one of interest to non-intel folks--it modifies the
GLSL front-end to record (in struct gl_fragment_program) which
fragment shader inputs need to be centroid interpolated.
The remaining patches implement the i965 bac
On Fri, Jun 22, 2012 at 10:02 AM, Vadim Girlin wrote:
> r600g: avoid unnecessary shader exports
> r600g: enable DUAL_EXPORT mode when possible
>
> First patch fixes the lockups with DUAL_EXPORT mode for me, also AFAICS it
> fixes some depth/stencil tests, though I'm not sure why, haven't looked
https://bugs.freedesktop.org/show_bug.cgi?id=51328
Javantea changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Le vendredi 22 juin 2012 18:17:24 Andy Furniss a écrit :
> Brian Paul wrote:
> > Can you see if the patch/info on bug
> > https://bugs.freedesktop.org/show_bug.cgi?idQ335 helps?
>
> Yes editing src/mesa/x86/Makefile.am to add -I$(top_srcdir)/include \
>
> fixed it, thanks.
>
> Git apply complained
https://bugs.freedesktop.org/show_bug.cgi?id=51335
Laurent carlier changed:
What|Removed |Added
Attachment #63353|0 |1
is obsolete|
Brian Paul wrote:
Can you see if the patch/info on bug
https://bugs.freedesktop.org/show_bug.cgi?id=51335 helps?
Yes editing src/mesa/x86/Makefile.am to add -I$(top_srcdir)/include \
fixed it, thanks.
Git apply complained when I tried to use the actual patch (save as on
the link)
bash-3.2
On 06/22/2012 10:07 AM, Jose Fonseca wrote:
> Looks good.
>
> Alternatively we could
>
> #ifdef __MINGW32__
> #define fprintf __mingw_fprintf()
> #endif
>
> in an header like imports.hpp so it can be used everywhere in mesa.
>
> Jose
I generally prefer that approach. Keeps all the platf
Looks good.
Alternatively we could
#ifdef __MINGW32__
#define fprintf __mingw_fprintf()
#endif
in an header like imports.hpp so it can be used everywhere in mesa.
Jose
- Original Message -
> ---
> src/mesa/program/prog_print.c | 13 +++--
> 1 files changed, 11 insertio
https://bugs.freedesktop.org/show_bug.cgi?id=51335
Laurent carlier changed:
What|Removed |Added
Attachment #63350|0 |1
is obsolete|
On Fri, Jun 22, 2012 at 10:02 AM, Vadim Girlin wrote:
> It seems DUAL_EXPORT on evergreen may be enabled when all CBs use 16-bit
> export
> mode (EXPORT_4C_16BPC), also there should be at least one CB, and the PS
> shouldn't export depth/stencil.
>
> Signed-off-by: Vadim Girlin
Reviewed-by: Jero
---
src/mesa/program/prog_print.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/mesa/program/prog_print.c b/src/mesa/program/prog_print.c
index 46f1df0..be67b93 100644
--- a/src/mesa/program/prog_print.c
+++ b/src/mesa/program/prog_print.c
@@ -970,9 +970
On Fri, Jun 22, 2012 at 10:02 AM, Vadim Girlin wrote:
> In some cases TGSI shader has more color outputs than the number of CBs,
> so it seems we need to limit the number of color exports. This requires
> different shader variants depending on the nr_cbufs, but on the other hand
> we are doing les
On 06/22/2012 09:43 AM, Andy Furniss wrote:
I have an atypical and old x86 LFS setup but could build OK a couple
of days ago.
make distclean
git clean -dfx
git pull
LDFLAGS="-L/home/andy/Src/Xorg-git/modular/lib" ./autogen.sh
--prefix=/home/andy/Src/Xorg-git/modular --enable-debug --disable-egl
I have an atypical and old x86 LFS setup but could build OK a couple of
days ago.
make distclean
git clean -dfx
git pull
LDFLAGS="-L/home/andy/Src/Xorg-git/modular/lib" ./autogen.sh
--prefix=/home/andy/Src/Xorg-git/modular --enable-debug --disable-egl
--enable-texture-float --enable-gallium-g
https://bugs.freedesktop.org/show_bug.cgi?id=51335
--- Comment #2 from Laurent carlier 2012-06-22 08:19:35
PDT ---
Created attachment 63350
--> https://bugs.freedesktop.org/attachment.cgi?id=63350
Possible fix
Possible fix, see
http://lists.freedesktop.org/archives/mesa-dev/2012-June/023158.h
https://bugs.freedesktop.org/show_bug.cgi?id=51335
--- Comment #1 from U. Artie Eoff 2012-06-22
08:11:05 PDT ---
Created attachment 63349
--> https://bugs.freedesktop.org/attachment.cgi?id=63349
bisect/compile log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=51335
Bug #: 51335
Summary: Compile Error: GL/gl.h: No such file or directory
Classification: Unclassified
Product: Mesa
Version: git
Platform: All
OS/Version: Linux (All)
S
https://bugs.freedesktop.org/show_bug.cgi?id=51328
Paul Berry changed:
What|Removed |Added
CC||stereotype...@gmail.com
--- Comment #1 from
It seems DUAL_EXPORT on evergreen may be enabled when all CBs use 16-bit export
mode (EXPORT_4C_16BPC), also there should be at least one CB, and the PS
shouldn't export depth/stencil.
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/evergreen_state.c | 46 ++
In some cases TGSI shader has more color outputs than the number of CBs,
so it seems we need to limit the number of color exports. This requires
different shader variants depending on the nr_cbufs, but on the other hand
we are doing less exports, which are very costly.
Signed-off-by: Vadim Girlin
r600g: avoid unnecessary shader exports
r600g: enable DUAL_EXPORT mode when possible
First patch fixes the lockups with DUAL_EXPORT mode for me, also AFAICS it
fixes some depth/stencil tests, though I'm not sure why, haven't looked
into it (possibly unexpected color exports were written over t
Building fail when GL headers are not installed in the system,
so add inclusion of these headers.
---
src/mesa/x86-64/Makefile.am |1 +
src/mesa/x86/Makefile.am|1 +
2 files changed, 2 insertions(+)
diff --git a/src/mesa/x86-64/Makefile.am b/src/mesa/x86-64/Makefile.am
index 79cbb53..
https://bugs.freedesktop.org/show_bug.cgi?id=51328
Bug #: 51328
Summary: _mesa_unpack_uint_z_row and _mesa_unpack_depth_span
are slow
Classification: Unclassified
Product: Mesa
Version: git
Platform: All
OS/Ver
On Don, 2012-06-21 at 17:31 -0400, Zack Rusin wrote:
> On Thursday, June 21, 2012 11:19:39 AM Michel Dänzer wrote:
> > BTW, recent versions of emacs no longer seem to provide the dirvars
> > package, but I think they support another similar mechanism instead.
> > Would be great if somebody who kno
39 matches
Mail list logo
