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 message Could not
implicitly convert operands to arithmetic
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(+),
On 10/31/2011 06:07 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/ir_variable.cpp | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/src/glsl/ir_variable.cpp
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 be
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 here.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
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
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
- 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 on
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 having
On Tue, Nov 1, 2011 at 2:11 PM, Dave Airlie airl...@gmail.com 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
On 31 October 2011 23:24, Kenneth Graunke kenn...@whitecape.org 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
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:
https://bugs.freedesktop.org/show_bug.cgi?id=42480
--- Comment #1 from pejakm pej...@gmail.com 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/show_bug.cgi?id=42480
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
Attachment #53007|application/octet-stream|text/plain
https://bugs.freedesktop.org/show_bug.cgi?id=42480
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
Attachment #53006|application/octet-stream|text/plain
https://bugs.freedesktop.org/show_bug.cgi?id=42480
--- Comment #2 from Alex Deucher ag...@yahoo.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=42480
--- Comment #3 from pejakm pej...@gmail.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=42480
--- Comment #4 from pejakm pej...@gmail.com 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
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 to
On Mon, 31 Oct 2011 17:44:45 -0700, Paul Berry stereotype...@gmail.com 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,
On 11/01/2011 02:57 AM, Yuanhan Liu wrote:
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
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
-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
the
On Sat, 29 Oct 2011 11:43:37 -0600, Brian Paul brian.e.p...@gmail.com wrote:
On Fri, Oct 28, 2011 at 1:50 PM, Eric Anholt e...@anholt.net 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
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
From: Dan McCabe zen3d.li...@gmail.com
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
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
---
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
On Tue, Nov 1, 2011 at 16:58, Chad Versace c...@chad-versace.us 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=38970
--- Comment #14 from ajax at nwnk dot net a...@nwnk.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
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 to
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 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
The fast and slow paths were doing these separately before.
Reviewed-by: Brian Paul bri...@vmware.com
---
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
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 +++
This avoids the wrapper, which should improve performance on packed
depth/stencil drivers.
Reviewed-by: Brian Paul bri...@vmware.com
---
src/mesa/swrast/s_readpix.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/src/mesa/swrast/s_readpix.c
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
All the code using it is converted to MapRenderbuffer and the core
unpack functions.
Reviewed-by: Brian Paul bri...@vmware.com
---
src/mesa/swrast/s_depth.c | 83 -
src/mesa/swrast/s_depth.h |5 ---
2 files changed, 0 insertions(+), 88
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
Reviewed-by: Brian Paul bri...@vmware.com
---
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
---
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 bri...@vmware.com
---
src/mesa/drivers/dri/radeon/radeon_tex_copy.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff
Reviewed-by: Brian Paul bri...@vmware.com
---
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
+++
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
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
---
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 bri...@vmware.com
---
src/mesa/drivers/dri/intel/intel_context.c| 10 +-
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
---
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
+++
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
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.
---
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
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
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
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
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);
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)
55 matches
Mail list logo
