In intel_map_renderbuffer_s8(), detile and copy the stencil buffer into
the temporary buffer only if the renderbuffer is mapped in read mode. If
the caller never going to read the bits but just clobber them, then it's
wasted effort to detile the stencil buffer.
CC: Eric Anholt
Signed-off-by: Chad
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 happene
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 MapRen
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:
general/depthstencil-de
When gathering the temporary buffer's pixles into the gem buffer, we had
the two buffers juxtaposed. Oops.
Fixes the following Piglit tests on gen7:
general/GL_SELECT - alpha-test enabled
general/GL_SELECT - depth-test enabled
general/GL_SELECT - no test function
general/GL_SELECT - sc
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 Anhol
-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 intel
Vadim Girlin 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 r600_b
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 _RADEON_CH
https://bugs.freedesktop.org/show_bug.cgi?id=42895
--- Comment #1 from nobled 2011-11-13 21:23:28 PST ---
Created attachment 53497
--> https://bugs.freedesktop.org/attachment.cgi?id=53497
ssh public key
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
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
S
On Fri, Nov 11, 2011 at 08:53:13AM -0800, Eric Anholt wrote:
> On Thu, 3 Nov 2011 10:16:06 +0800, Yuanhan Liu
> 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
> > > wrote:
> > > > On Tue, Nov 01, 2011 at 05:57:36PM +0
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 varia
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
Emit MOVA* instruction only when AR is used.
Signed-off-by: Vadim Girlin
---
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
src/gallium/drivers/r600/r600_a
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
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 GL_NV_gpu_
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 GL
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 O
---
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
--- a/src/gallium/drivers/softpipe/sp_tex_samp
This will disallow moving them to the trans slot in merge_inst_groups
Signed-off-by: Vadim Girlin
---
Tested on evergreen: no regressions, fixes ~20 tests.
src/gallium/drivers/r600/r600_asm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/r600/r
21 matches
Mail list logo
