---
src/gallium/drivers/softpipe/sp_tex_sample.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c
b/src/gallium/drivers/softpipe/sp_tex_sample.c
index 72629a0..9b0e54e1 100644
---
Hi,
I found some problem with glsl_to_tgsi: remove_output_reads function.
It's replacing outputs with temps, producing incorrect results with
relative addressing. You can see it e.g. with
vs-varying-array-mat2-col-rd.shader_test. Here is a dump:
VERT
DCL IN[0]
DCL OUT[0], POSITION
DCL
I am guessing there is no type info because TGSI shaders are allowed
to use uint, sint, and float instructions on the same register without
type conversions (it would be possible to generate such usage with
GL_ARB_shader_bit_enconding, also GL_NV_gpu_program4 has typeless
registers too). I think
On 13.11.2011 17:10, Marek Olšák wrote:
I am guessing there is no type info because TGSI shaders are allowed
to use uint, sint, and float instructions on the same register without
type conversions (it would be possible to generate such usage with
GL_ARB_shader_bit_enconding, also
On 13.11.2011 17:32, Christoph Bumiller wrote:
On 13.11.2011 17:10, Marek Olšák wrote:
I am guessing there is no type info because TGSI shaders are allowed
to use uint, sint, and float instructions on the same register without
type conversions (it would be possible to generate such usage with
Emit MOVA* instruction only when AR is used.
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
Tested on evergreen: no regressions, fixes some variable-indexing tests.
v2: use BC_INST macro for instruction selection
src/gallium/drivers/r600/r600_asm.c| 35
On 11/13/2011 09:06 AM, Dave Airlie wrote:
Hi guys,
Just been looking at llvmpipe integer support and it seems like we
lose some information about the type of data stored into temporaries,
after st_glsl_to_cpp we no longer know what type the temporaries are,
and llvm would really like to
On Sat, Nov 12, 2011 at 12:54:37PM -0800, Ian Romanick wrote:
On 11/09/2011 01:10 AM, Yuanhan Liu wrote:
The original comments just tell me that I'm doing wrong. Here I sent a
patch for comments and explanation, and I may then try to write the code
to process those built-in uniform variables.
On Fri, Nov 11, 2011 at 08:53:13AM -0800, Eric Anholt wrote:
On Thu, 3 Nov 2011 10:16:06 +0800, Yuanhan Liu yuanhan@linux.intel.com
wrote:
On Wed, Nov 02, 2011 at 02:18:46PM -0700, Eric Anholt wrote:
On Wed, 2 Nov 2011 11:12:07 +0800, Yuanhan Liu
yuanhan@linux.intel.com wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=42895
Bug #: 42895
Summary: FreeDesktop account request
Classification: Unclassified
Product: Mesa
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=42895
--- Comment #1 from nobled nob...@dreamwidth.org 2011-11-13 21:23:28 PST ---
Created attachment 53497
-- https://bugs.freedesktop.org/attachment.cgi?id=53497
ssh public key
--
Configure bugmail:
diff --git a/src/mesa/drivers/dri/radeon/radeon_chipset.h b/src/mesa/drivers/dri/radeon/radeon_chipset.h
index 445e085..10cf348 100644
--- a/src/mesa/drivers/dri/radeon/radeon_chipset.h
+++ b/src/mesa/drivers/dri/radeon/radeon_chipset.h
@@ -1,7 +1,5 @@
#ifndef _RADEON_CHIPSET_H
#define
Vadim Girlin vadimgirlin at gmail.com writes:
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index c4cc922..7414c73 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
[...]
@@ -1201,6 +1202,36 @@ static int
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The MapRenderbuffer work introduced a lot depthstencil bugs on gen7, which
uses separate stencil.
Once these patches get committed, I'll post the long-awaited HiZ series.
Chad Versace (6):
intel: Refactor intel_map_renderbuffer()
intel: Fix
The function already implements 3 cases (map through GTT, blit to
a temporary, and detile stencil buffer to temporary), and a 4th will be
added soon: scatter/gather for depthstencil buffers using separate
stencil. For sanity's sake, this factors each case out into its own
function.
CC: Eric
If a window system stencil buffer had a region with odd height, then the
calculated y offset needed for software detiling was off by one. The bug
existed in intel_{map,unmap}_renderbuffer_s8() and in the intel_span.c
accessors.
Fixes the following Piglit tests on gen7:
For a depthstencil buffer with separate stencil,
intel_renderbuffer::region is null. (The regions are kept in hidden depth
and stencil buffers). Since the region is null, intel_map_renderbuffer()
assumed there was no data and returned a null map pointer, which in turn
was dereferenced (!) by
This patch fixes three interrelated bugs.
Fixes many depthstencil Piglit tests on gen7, too many to list.
1. Don't map the depthstencil buffer twice
--
Place a guard in intel_renderbuffer_map() to prevent a renderbuffer from
being mapped twice. This
18 matches
Mail list logo
