I think you might squash the attached diff into your patch.
Andreas.
2013/6/28 Ian Romanick i...@freedesktop.org
From: Ian Romanick ian.d.roman...@intel.com
Commit bab755a made the implementation a no-op, and it was only ever
enabled by software rasterizers.
Signed-off-by: Ian Romanick
https://bugs.freedesktop.org/show_bug.cgi?id=66149
Gordon Jin gordon@intel.com changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=66149
--- Comment #6 from Andreas Boll andreas.boll@gmail.com ---
(In reply to comment #4)
The issue can't be reproduced with 9.1 branch.
When will 9.1.4 release? Thanks!
It's planned to be released on monday.
https://bugs.freedesktop.org/show_bug.cgi?id=56710
--- Comment #14 from Jon TURNEY jon.tur...@dronecode.org.uk ---
(In reply to comment #13)
Could you still reproduce this bug?
Appears to be fixed to me.
--
You are receiving this mail because:
You are the QA Contact for the bug.
The rules were writing files to e.g. util/u_indices_gen.py, but in an
out-of-tree build this directory doesn't exist in the build directory. So,
create the directories just in case.
Note: This patch is a candidate for the 9.0 and 9.1 branches.
Signed-off-by: Ross Burton ross.bur...@intel.com
On 06/27/2013 06:20 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
This copy of the source file is only used for GEN = 3, so remove the
dead code.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/dri/i915/intel_extensions.c | 79
https://bugs.freedesktop.org/show_bug.cgi?id=56710
Andreas Boll andreas.boll@gmail.com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
2013/6/28 Ross Burton ross.bur...@intel.com
The rules were writing files to e.g. util/u_indices_gen.py, but in an
out-of-tree build this directory doesn't exist in the build directory. So,
create the directories just in case.
Note: This patch is a candidate for the 9.0 and 9.1 branches.
I
The rules were writing files to e.g. util/u_indices_gen.py, but in an
out-of-tree build this directory doesn't exist in the build directory. So,
create the directories just in case.
Note: This patch is a candidate for the 9.0 and 9.1 branches.
Signed-off-by: Ross Burton ross.bur...@intel.com
On 06/27/2013 07:20 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
In Mesa, this extension is implemented purely in software. Drivers may
*optionally* provide optimized paths.
NOTE: This has the side effect of enabling the extension in the radeon,
r200, and nouveau
On 06/27/2013 07:20 PM, Ian Romanick wrote:
This is my annual extension clean up blob. I don't expect much here to
be controversial (or even interesting to read) except patches 12, 17,
18, and 21.
LGTM.
Just a minor formatting comment on #19. And I second Kenneth's comment
on #20.
For
There is an open bug report about this issue:
https://bugs.freedesktop.org/show_bug.cgi?id=60197
Matt, could you take a look at this?
Which patch do you prefer?
2013/6/28 Ross Burton ross.bur...@intel.com
The rules were writing files to e.g. util/u_indices_gen.py, but in an
out-of-tree build
---
src/gallium/drivers/svga/svga_tgsi.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi.c
b/src/gallium/drivers/svga/svga_tgsi.c
index 56529c6..29fbe84 100644
--- a/src/gallium/drivers/svga/svga_tgsi.c
+++
On 28 June 2013 14:57, Andreas Boll andreas.boll@gmail.com wrote:
There is an open bug report about this issue:
https://bugs.freedesktop.org/show_bug.cgi?id=60197
Matt, could you take a look at this?
Which patch do you prefer?
Quentin's patch is more generic as it uses $(dir), so merge
- Original Message -
Safer in case the PIPE_SHADER_x tokens get renumbered (as Marek
wanted to do).
Renumbering PIPE_SHADER_x seems a pure time waster -- there is much more code
that expects the current order -- and I see no benefit.
This patch looks good nevertheles.
---
Looks good to me
- Original Message -
---
src/gallium/drivers/svga/svga_tgsi.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi.c
b/src/gallium/drivers/svga/svga_tgsi.c
index 56529c6..29fbe84 100644
---
PathV1.h has been removed. In theory this can go back before llvm 3.4, but I
haven't done the research to find out how far back.
Signed-off-by: Aaron Watry awa...@gmail.com
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 12
1 file changed, 12 insertions(+)
diff --git
The renumbering only makes sense for the GLSL linker and the only
reason for doing that in gallium too is that PIPE_SHADER_x must be
equal to MESA_SHADER_x.
Marek
On Fri, Jun 28, 2013 at 4:32 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
Safer in case the
https://bugs.freedesktop.org/show_bug.cgi?id=66029
--- Comment #4 from Klemens Baum klemensb...@gmail.com ---
Sent: http://lists.freedesktop.org/archives/mesa-dev/2013-June/041160.html
--
You are receiving this mail because:
You are the assignee for the bug.
- Original Message -
See my explanation in mtypes.h.
---
src/gallium/include/pipe/p_defines.h |7 ---
src/glsl/linker.cpp| 16
src/mesa/drivers/dri/i965/brw_shader.cpp |8 ++--
src/mesa/main/mtypes.h
From: Roland Scheidegger srol...@vmware.com
b04a295a4a0cd2defe352b3193b5fa79ca8fc9fc removed seemingly unnecessary
code in get_query. Turns out this code could in fact be reached - while
timestamps are always binned, if there are no bins (which happens if fb
size is 0) then the rasterization
On 06/28/2013 08:53 AM, Jose Fonseca wrote:
- Original Message -
See my explanation in mtypes.h.
---
src/gallium/include/pipe/p_defines.h |7 ---
src/glsl/linker.cpp| 16
src/mesa/drivers/dri/i965/brw_shader.cpp |8
Disregard this patch... Looks like Tom already pushed a fix last night.
--Aaron
On Fri, Jun 28, 2013 at 9:41 AM, Aaron Watry awa...@gmail.com wrote:
PathV1.h has been removed. In theory this can go back before llvm 3.4, but I
haven't done the research to find out how far back.
Signed-off-by:
On 06/13/2013 05:25 AM, Marek Olšák wrote:
Hi everyone,
this series adds a new GLSL compiler optimization pass which eliminates unused
and set-but-unused built-in varyings and adds a few improvements to the GLSL
linker in the process.
Before I show you how it works, I wanna say that there
On 06/28/2013 08:42 AM, Ian Romanick wrote:
On 06/13/2013 05:25 AM, Marek Olšák wrote:
Hi everyone,
this series adds a new GLSL compiler optimization pass which
eliminates unused and set-but-unused built-in varyings and adds a few
improvements to the GLSL linker in the process.
Before I show
On 06/13/2013 05:25 AM, Marek Olšák wrote:
This eliminates built-in varyings such as gl_Color, gl_SecondaryColor,
gl_TexCoord, and gl_FogFragCoord if they are unused by the next stage or
not written at all (e.g. gl_TexCoord elements). The gl_TexCoord array is
broken down into separate vec4s if
https://bugs.freedesktop.org/show_bug.cgi?id=66149
--- Comment #7 from Ian Romanick i...@freedesktop.org ---
Eva, can you clarify for me. 9.1 works correctly, but master does not? If the
bug still exists on master, the bug should not be closed.
--
You are receiving this mail because:
You are
On Fri, Jun 28, 2013 at 5:42 PM, Ian Romanick i...@freedesktop.org wrote:
On 06/13/2013 05:25 AM, Marek Olšák wrote:
Hi everyone,
this series adds a new GLSL compiler optimization pass which eliminates
unused and set-but-unused built-in varyings and adds a few improvements to
the GLSL
On 12.06.2013 00:04, Grigori Goronzy wrote:
Allows MSAA colorbuffers, which have a CMASK automatically and don't
need any further special handling, to be fast cleared. Instead
of clearing the buffer, set the clear color and the CMASK to the
cleared state.
Fast clear is used only when all bound
Friendly ping regarding this patch :-)
--Myles
On Wed, Jun 19, 2013 at 12:47 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
Any word on this?
Thanks,
Myles
On Mon, Jun 17, 2013 at 12:09 PM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
Sure. I was under the impression
From: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
lib/Target/R600/Processors.td |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/Target/R600/Processors.td b/lib/Target/R600/Processors.td
index 81f407e..a0735d4
Looks good.
- Original Message -
From: Roland Scheidegger srol...@vmware.com
b04a295a4a0cd2defe352b3193b5fa79ca8fc9fc removed seemingly unnecessary
code in get_query. Turns out this code could in fact be reached - while
timestamps are always binned, if there are no bins (which
On 06/28/2013 10:55 AM, Marek Olšák wrote:
On Fri, Jun 28, 2013 at 5:42 PM, Ian Romanick i...@freedesktop.org wrote:
On 06/13/2013 05:25 AM, Marek Olšák wrote:
Hi everyone,
this series adds a new GLSL compiler optimization pass which eliminates
unused and set-but-unused built-in varyings and
On Fri, Jun 28, 2013 at 03:05:04PM -0400, alexdeuc...@gmail.com wrote:
From: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Committed, thanks!
-Tom
---
lib/Target/R600/Processors.td |3 +++
1 files changed, 3 insertions(+), 0
This patch adds texture() for isamplerCubeArray and usamplerCubeArray,
which were entirely missing.
It also makes texture() with a LOD bias fragment shader specific. The
main GLSL specification explicitly says that texturing with LOD bias
should not be allowed for vertex shaders.
Affects
We were incorrectly computing the buffer offset when using the
instances. The buffer offset is always equal to:
start_instance * stride + (instance_num / instance_divisor) *
stride
We were completely ignoring the start instance quite
often producing instances that completely wrong, e.g. if
start
On Wed, Jun 19, 2013 at 06:28:21PM +0200, Michel Dänzer wrote:
These patches implement enough of local memory support to allow radeonsi
to use that for computing derivatives, as suggested by Tom.
They also almost allow test/CodeGen/R600/local-memory.ll to generate
code for SI. Right now it
Eric Anholt e...@anholt.net writes:
This brings over the batch-wrap-prevention and aperture space checking
code from the normal brw_draw.c path, so that we don't need to flush the
batch every time.
There's a risk here if the intel_emit_post_sync_nonzero_flush() call isn't
high enough up in
On Sat, Jun 29, 2013 at 7:22 AM, Kenneth Graunke kenn...@whitecape.org wrote:
This patch adds texture() for isamplerCubeArray and usamplerCubeArray,
which were entirely missing.
It also makes texture() with a LOD bias fragment shader specific. The
main GLSL specification explicitly says that
The __DRI_USE_INVALIDATE extension was added in May 11th, 2010 by commit
4258e3a2e1c327. At this point, it's unlikely that anyone's using the
right mix of new and old components to hit this path. Deleting it
removes an untested code path and cleans up the driver a bit.
Cc: Kristian Høgsberg
+void
+brw_blorp_blit_program::manual_blend_linear(unsigned num_samples)
+{
+ if (key-tex_layout == INTEL_MSAA_LAYOUT_CMS)
+ mcs_fetch();
This won't work. The MCS value we fetch has to match up with the pixel
that we're sampling from. Since this function samples from
Current implementation of ext_framebuffer_multisample_blit_scaled in
i965/blorp uses nearest filtering for multisample scaled blits. Using
nearest filtering produces blocky artifacts and negates the benefits
of MSAA. That is the reason why extension was not enabled on i965.
This patch implements
https://bugs.freedesktop.org/show_bug.cgi?id=66346
Priority: medium
Bug ID: 66346
Keywords: regression
CC: bri...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: shader_query.cpp:49: error: invalid conversion from
Anuj,
Yeah -- multisample textures on Gen7 are currently UMS for color. If
you wanted to enable support for CMS, it should be reasonably
straightforward, but requires some tweaks in the shader backend.
This looks like a really nice quality improvement -- for the series:
Acked-by: Chris Forbes
44 matches
Mail list logo