_mesa_validate_pbo_teximage may fail, result the pbo not mapped.
If then unmap function is called, an abort would be triggered by
assert(obj->Pointer).
This would fix: https://bugs.freedesktop.org/show_bug.cgi?id=42268
NOTE: this is just for 7.11 stable branch
Signed-off-by: Yuanhan Liu
Cc: i..
i965's MUL instruction can't take an immediate value as its first
argument. So normally, if constant propagation wants to propagate a
constant into the first argument of a MUL instruction, it swaps the
order of the two arguments.
This doesn't work for 32-bit integer (and unsigned integer)
multipl
On Tue, Nov 01, 2011 at 05:57:36PM +0800, Yuanhan Liu wrote:
> According to bspec, MIPCnt(was set to intelObj->_MaxLevel) was used for
> min/mag filter mode determination. For a normal case with no mipmap like
> this:
>
> glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
> glT
Mesa attached the texture only to the depth attachment point
gl_framebuffer::Attachment[BUFFER_DEPTH]
and failed to attach it to the stencil attachment point
gl_framebuffer::Attachment[BUFFER_STENCIL]
Fixes Piglit test
ARB_framebuffer_object/same-attachment-glFramebufferTexture2D-GL_DEPTH
Add the following tests:
specs/ARB_framebuffer_object/same-attachment-glFramebufferRenderbuffer-GL_DEPTH_STENCIL_ATTACHMENT
specs/ARB_framebuffer_object/same-attachment-glFramebufferTexture2D-GL_DEPTH_STENCIL_ATTACHMENT
The test check that if an object is attached to the
GL_DEPTH
When glFramebufferTexture2D(attachment=GL_DEPTH_STENCIL_ATTACHMENT) was
the texture was attached only to the depth attachment point and not
the stencil attachment. So this series provides a test and a fix.
piglit
Chad Versace (1):
mesa: Fix
glFramebufferTexture(attachment=G
Please forgive if this is the wrong list for these questions or if they have
already been asked and answered.
I am trying to figure out where the unichrome driver went in the 7.12-devel
branch and if it is coming back. Anybody have some clues for me?_
Other than those two minor comments, the series looks good to me.
Reviewed-by: Brian Paul
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 11/01/2011 05:17 PM, Eric Anholt wrote:
This avoids going through the wrapper that has to rewrite the data for
packed depth/stencil. This isn't done in _swrast_read_stencil_span
because we don't want to map/unmap for each span.
v2: Move the unpack code to format_unpack.c.
---
src/mesa/main
On 11/01/2011 05:17 PM, Eric Anholt wrote:
This introduces two new span helper functions we'll want to use in
several palces as we move to MapRenderbuffer, which pull out integer
"places"
depth and stencil values from a renderbuffer mapping based on the
renderbuffer format.
v2: Use format_u
---
src/mesa/drivers/dri/intel/intel_blit.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_blit.c
b/src/mesa/drivers/dri/intel/intel_blit.c
index def226c..8d7693d 100644
--- a/src/mesa/drivers/dri/intel/intel_blit.c
+++ b/src/mesa/dr
The readpixels microbenchmark in mesa-demos goes from 47Mpix/sec on
1000x1000 to 450Mpix/sec. The 10x10 sizes stay about the same.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 87 +---
src/mesa/drivers/dri/intel/intel_fbo.h |2 +-
2 files changed, 81 insertions(+
Renderbuffer mapping handles flushing the batchbuffer if required, so
all we need to do is make sure any pending rendering has reached the
batchbuffer.
Reviewed-by: Brian Paul
---
src/mesa/drivers/dri/intel/intel_context.c| 10 +-
src/mesa/drivers/dri/intel/intel_context.h|
v2: Move _mesa_get_format_bytes out of the loop.
---
src/mesa/swrast/s_readpix.c | 57 ---
1 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpix.c
index 30c0c92..5f42202 100644
--- a/src/mes
This may be a bit slower than before because we're switching from
per-format compiled loops in GetRow to
_mesa_unpack_rgba_block_unpack's loop around a callback to unpack a
pixel. The solution there would be to make _mesa_unpack_rgba_block
fold the span loop into the format handlers.
(On the othe
Reviewed-by: Brian Paul
---
src/mesa/swrast/s_readpix.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpix.c
index 5e7e8ba..7ecc6bf 100644
--- a/src/mesa/swrast/s_readpix.c
+++ b/src/mesa/swrast/s_readpix.c
@@ -4
There doesn't appear to be any particular reason for this -- it's not
like the width is changing between the deref and the use.
Reviewed-by: Brian Paul
---
src/mesa/drivers/dri/radeon/radeon_tex_copy.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drive
Reviewed-by: Brian Paul
---
src/mesa/swrast/s_readpix.c | 72 +--
1 files changed, 42 insertions(+), 30 deletions(-)
diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpix.c
index 8559ab7..a372846 100644
--- a/src/mesa/swrast/s_readpix.c
++
None of the callgraph below this uses derived state (almost nothing
even dereferences the swrast context).
---
src/mesa/swrast/s_readpix.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpix.c
index 5f42202..46c464b 10
All the code using it is converted to MapRenderbuffer and the core
unpack functions.
Reviewed-by: Brian Paul
---
src/mesa/swrast/s_depth.c | 83 -
src/mesa/swrast/s_depth.h |5 ---
2 files changed, 0 insertions(+), 88 deletions(-)
diff --git a/s
In all of piglit, only two tests hit it (reading to RGBA float, where
GetRow would drop floats into place from R, RG, or RGB).
---
src/mesa/swrast/s_readpix.c | 90 ---
1 files changed, 0 insertions(+), 90 deletions(-)
diff --git a/src/mesa/swrast/s_readp
This avoids the wrapper, which should improve performance on packed
depth/stencil drivers.
Reviewed-by: Brian Paul
---
src/mesa/swrast/s_readpix.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpi
This introduces two new span helper functions we'll want to use in
several palces as we move to MapRenderbuffer, which pull out integer
depth and stencil values from a renderbuffer mapping based on the
renderbuffer format.
v2: Use format_unpack helper for stencil read.
---
src/mesa/swrast/s_depth
This should be useful in making more generic fast paths in the pixel
paths.
v2: Add note about PACK_SWAP_BYTES, and fix up for endianness by
synchronizing with memcpy_texture paths in texstore.c.
---
src/mesa/main/formats.c | 318 +++
src/mesa/main
The fast and slow paths were doing these separately before.
Reviewed-by: Brian Paul
---
src/mesa/swrast/s_readpix.c | 30 ++
1 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpix.c
index 587cabe..f6c
This avoids going through the wrapper that has to rewrite the data for
packed depth/stencil. This isn't done in _swrast_read_stencil_span
because we don't want to map/unmap for each span.
v2: Move the unpack code to format_unpack.c.
---
src/mesa/main/format_unpack.c | 58 ++
This also makes it handle 24/8 vs 8/24, fixing piglit
depthstencil-default_fb-readpixels-24_8 on i965. While here, avoid
incorrectly fast-pathing if packing->SwapBytes is set.
v2: Move the unpack code to format_unpack.c, fix BUFFER_DEPTH typo
---
src/mesa/main/format_unpack.c | 35
This reverts commit abaebcee787eeb8a89bf7a82ed4d1532fcde5e39.
The assertion I made was that "the zero-copy code in validation" would
zero copy. Of course, I deleted that check back in January because
the two sites that would trigger it (glTexImage() and this one) both
immediately bound their mt t
https://bugs.freedesktop.org/show_bug.cgi?id=38970
--- Comment #14 from ajax at nwnk dot net 2011-11-01 14:43:47
PDT ---
(In reply to comment #13)
> ajax/Ian, any idea?
Pretty sure the test is correct and Mesa is wrong. You simply happen to have
found the change that turned a bogus pass into a
https://bugs.freedesktop.org/show_bug.cgi?id=42487
--- Comment #1 from vincent 2011-11-01 14:20:05 PDT ---
Created attachment 53021
--> https://bugs.freedesktop.org/attachment.cgi?id=53021
Here is the image showing display artifact
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.
https://bugs.freedesktop.org/show_bug.cgi?id=42487
Bug #: 42487
Summary: Teapot visual artifact
Classification: Unclassified
Product: Mesa
Version: 7.11
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
On Tue, Nov 1, 2011 at 16:58, Chad Versace wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/01/2011 09:33 AM, Eric Anholt wrote:
> > This reverts commit abaebcee787eeb8a89bf7a82ed4d1532fcde5e39.
> >
> > The assertion I made was that "the zero-copy code in validation" would
> > z
---
src/glsl/linker.cpp | 192 ++-
1 files changed, 174 insertions(+), 18 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index e6012bf..d5d50b5 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1615,49 +1615,170 @@
This adds a function that takes an array of varyings from
glTranformFeedbackVaryingsEXT and generates gl_transform_feedback_info,
which is supposed to be consumed by drivers. Useful for ir_to_mesa
and glsl_to_tgsi.
v2:
- changes per Kenneth Graunke's comment
- expose the TFB varying parser in ir.h
From: Dan McCabe
Modify the linker to assign additional slots for varying
variables used by transform feedback. This is done after other
varyings are already assigned slots.
Since this is done after previous varying slot assignments,
the code needs to know how many varyings are already assigned
Hi everyone,
Here's what I think is complete GLSL linker code for EXT_transform_feedback.
What's missing in core Mesa is the implementation of
glGetTransformFeedbackVaryingEXT, but other than that I think we're all set.
The first patch is the Dan McCabe's patch with one bug fix.
The second patc
On Sat, 29 Oct 2011 11:43:37 -0600, Brian Paul wrote:
> On Fri, Oct 28, 2011 at 1:50 PM, Eric Anholt wrote:
> > In all of piglit, only two tests hit it (reading to RGBA float, where
> > GetRow would drop floats into place from R, RG, or RGB).
>
> So if an app does glReadPixels(format=GL_RGBA, ty
On 31 October 2011 18:07, Ian Romanick wrote:
> From: Ian Romanick
>
> This requires tracking a couple extra fields in ir_variable:
>
> * A flag to indicate that a variable had an initializer.
>
> * For non-const variables, a field to track the constant value of the
> variable's initializer.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/2011 09:33 AM, Eric Anholt wrote:
> This reverts commit abaebcee787eeb8a89bf7a82ed4d1532fcde5e39.
>
> The assertion I made was that "the zero-copy code in validation" would
> zero copy. Of course, I deleted that check back in January because
On 11/01/2011 02:57 AM, Yuanhan Liu wrote:
> Signed-off-by: Yuanhan Liu
> ---
> src/mesa/drivers/dri/intel/intel_tex_validate.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_tex_validate.c
> b/src/mesa/drivers/dri/intel/intel
On Mon, 31 Oct 2011 17:44:45 -0700, Paul Berry wrote:
> This patch ensures that gl_client_array::Integer is properly set to
> GL_TRUE for vertex attributes specified using glVertexAttribIPointer,
> and to GL_FALSE for vertex attributes specified using
> glVertexAttribPointer, so that the vertex at
This reverts commit abaebcee787eeb8a89bf7a82ed4d1532fcde5e39.
The assertion I made was that "the zero-copy code in validation" would
zero copy. Of course, I deleted that check back in January because
the two sites that would trigger it (glTexImage() and this one) both
immediately bound their mt t
https://bugs.freedesktop.org/show_bug.cgi?id=42480
--- Comment #4 from pejakm 2011-11-01 09:23:36 PDT ---
Forgot to mention, libdrm version is 2.4.27. Configure check did not pass with
version 2.4.26.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=42480
--- Comment #3 from pejakm 2011-11-01 09:18:39 PDT ---
I compile from clean tree every time (I'm using an Arch Linux's PKGBUILD
script).
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this m
https://bugs.freedesktop.org/show_bug.cgi?id=42480
--- Comment #2 from Alex Deucher 2011-11-01 09:15:41 PDT ---
Does running 'make clean' help?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee fo
https://bugs.freedesktop.org/show_bug.cgi?id=42480
Michel Dänzer changed:
What|Removed |Added
Attachment #53006|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=42480
Michel Dänzer changed:
What|Removed |Added
Attachment #53007|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=42480
--- Comment #1 from pejakm 2011-11-01 09:06:43 PDT ---
Created attachment 53007
--> https://bugs.freedesktop.org/attachment.cgi?id=53007
Compilation log error
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=42480
Bug #: 42480
Summary: pipe_r600.so compilation fails
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: N
On 31 October 2011 23:24, Kenneth Graunke wrote:
> On 10/31/2011 08:34 PM, Paul Berry wrote:
> > When converting an expression like "++x" to GLSL IR we were failing to
> > account for the possibility that x might be an unsigned integral type.
> > As a result the user would receive a bogus error m
On Tue, Nov 1, 2011 at 2:11 PM, Dave Airlie wrote:
>>
>> After wasting so much time on this topic, and conceding on most points, I'm
>> disappointed that the new pure integers formats were added without support
>> for converting to/from floats (my 2nd request above) which ended up causing
>> ob
>
> After wasting so much time on this topic, and conceding on most points, I'm
> disappointed that the new pure integers formats were added without support
> for converting to/from floats (my 2nd request above) which ended up causing
> obscures bugs in llvmpipe (my 1st request).
>
> I regret ha
- Original Message -
[...]
> Anyway, you guys are doing it, and it doesn't seem like Keith or Brian have
> an opinion, so as far as I'm concerned, feel free to decide among yourselves
> and start coding away in a branch.
>
> I only have two requirements:
>
> - there must be no regression
According to bspec, MIPCnt(was set to intelObj->_MaxLevel) was used for
min/mag filter mode determination. For a normal case with no mipmap like
this:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
hardware
Signed-off-by: Yuanhan Liu
---
src/mesa/drivers/dri/intel/intel_tex_validate.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_validate.c
b/src/mesa/drivers/dri/intel/intel_tex_validate.c
index 4012400..e2b8699 100644
--- a/src/m
On 11/01/2011 12:11 AM, José Fonseca wrote:
>
> MinGW uses MSVC's runtime DLLs for most of C runtime's functions, and
> there has same semantics for vsnprintf.
>
> Not sure how this worked until now -- maybe one of the internal
> vsnprintf implementations was taking precedence.
No objections her
On 10/31/2011 05:44 PM, Paul Berry wrote:
> This patch ensures that gl_client_array::Integer is properly set to
> GL_TRUE for vertex attributes specified using glVertexAttribIPointer,
> and to GL_FALSE for vertex attributes specified using
> glVertexAttribPointer, so that the vertex attributes can
On 10/31/2011 06:07 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> ---
> src/glsl/ir_variable.cpp | 11 ---
> 1 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/src/glsl/ir_variable.cpp b/src/glsl/ir_variable.cpp
> index 1ee84d2..bea0b2b
MinGW uses MSVC's runtime DLLs for most of C runtime's functions, and
there has same semantics for vsnprintf.
Not sure how this worked until now -- maybe one of the internal
vsnprintf implementations was taking precedence.
---
src/glsl/ralloc.c |8 +++-
1 files changed, 7 insertions(+),
59 matches
Mail list logo
