gl_texture_image::InternalFormat is actually the user requested internal
format, not what the texture actually is. Thus, even though we don't
support 32-bit depth buffers, we need to recognize the enumeration here.
Otherwise, it wrongly returns the color read buffer instead of the depth
read
intelEmitCopyBlit already checks for this, so the check is redundant and
unnecessary. This consolidates the logic (which will soon change).
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
According to the Sandybridge PRM, Volume 1, Part 5, Section 1.9.15,
Gen6's blitter supports Y-tiled buffers as well as X-tiled. Pitch is
specified in 512-byte granularity for X-tiled, but 128-byte for Y-tiled.
Gen5 and earlier unfortunately only support X-tiled buffers.
Fixes a software
From: José Fonseca jfons...@vmware.com
Also, only flush when going from HW TNL to SW TNL, given it is impossible
for the buffers resulting from SWTNL to be ever referred by HW TNL path.
---
src/gallium/drivers/svga/svga_context.h |3 ---
src/gallium/drivers/svga/svga_pipe_draw.c | 23
Make sure that the upload manager doesn't upload data that's not
dirty. This speeds up the viewperf test proe-04/1 a factor 5 or so on svga.
Also introduce an u_upload_unmap() function that can be used
instead of u_upload_flush() so that we can pack
even more data in upload buffers. With this we
This enables us to pack more data into single upload buffers.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
src/gallium/drivers/svga/svga_context.c |8
src/gallium/drivers/svga/svga_draw.c|4 ++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git
Stream user buffer contents rather than trying to maintain persistent
host / hardware copies.
Resulting negative array offsets are not allowed by the hardware,
(well, at least not according to header files), so adjust index bias
to make all array offsets positive.
Signed-off-by: Thomas Hellstrom
From: José Fonseca jfons...@vmware.com
---
src/gallium/drivers/svga/svga_resource_buffer.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_resource_buffer.h
b/src/gallium/drivers/svga/svga_resource_buffer.h
index 2ae44d2..69d6f72
From: Brian Paul bri...@vmware.com
Viewperf uses some unusual vertex arrays where the stride is less
than the element size. In this case, the stride was 4 while the
element size was 12. The difference of 8 bytes causes us to miss
uploading the tail bit of the array data.
Typically the stride
From: Brian Paul bri...@vmware.com
See preceeding commit for more info.
---
src/gallium/drivers/svga/svga_pipe_draw.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_pipe_draw.c
b/src/gallium/drivers/svga/svga_pipe_draw.c
index
If a user-buffer was referenced twice by a draw command, the affected ranges
were uploaded separately, with only the last one being referenced by the
hardware. Make sure we upload only a single range.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
Hmm.
Forgive my ignorance, but isn't memcmp() on structs pretty prone to give
incorrect != results, given that there may be padding between members in
structs and that IIRC gcc struct assignment is member-wise.
What happens if there's padding between the jit_context and variant
members of
On Wed, 29 Jun 2011 23:04:04 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
According to the Sandybridge PRM, Volume 1, Part 5, Section 1.9.15,
Gen6's blitter supports Y-tiled buffers as well as X-tiled. Pitch is
specified in 512-byte granularity for X-tiled, but 128-byte for Y-tiled.
On Wed, 2011-06-29 at 16:16 -0700, Corbin Simpson wrote:
Okay, so maybe I'm failing to recognize the exact situation here, but
wouldn't it be possible to mark the FS state with a serial number and
just compare those? Or are these FS states not CSO-cached?
No, the struct being compared is
On Thu, 2011-06-30 at 03:36 +0200, Roland Scheidegger wrote:
Ok in fact there's a gcc bug about memcmp:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
In short gcc's memcmp builtin is totally lame and loses to glibc's
memcmp (including call overhead, no knowledge about alignment etc.) even
Great work Roland! And thanks Ajax to finding this hot spot.
We use memcmp a lot -- all CSO caching, so we should use this everywhere.
We should also code a sse2 version with intrinsics for x86-64, which is
guaranteed to always have SSE2.
Jose
- Original Message -
Actually I ran some
- Original Message -
Hmm.
Forgive my ignorance, but isn't memcmp() on structs pretty prone to
give
incorrect != results, given that there may be padding between members
in
structs and that IIRC gcc struct assignment is member-wise.
There's no alternative to bitwise comparison on
- Original Message -
On Thu, 2011-06-30 at 03:36 +0200, Roland Scheidegger wrote:
Ok in fact there's a gcc bug about memcmp:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
In short gcc's memcmp builtin is totally lame and loses to glibc's
memcmp (including call overhead, no
On Thu, Jun 30, 2011 at 12:04 AM, Kenneth Graunke kenn...@whitecape.org wrote:
gl_texture_image::InternalFormat is actually the user requested internal
format, not what the texture actually is. Thus, even though we don't
support 32-bit depth buffers, we need to recognize the enumeration here.
https://bugs.freedesktop.org/show_bug.cgi?id=37177
--- Comment #3 from Mark van Rossum mvanr...@inf.ed.ac.uk 2011-06-30 05:34:57
PDT ---
Confirmed for me on Fedora 15 with Mathematica 7
on VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated
Graphics Controller (rev 0c).
On Thu, 2011-06-30 at 03:27 -0700, Jose Fonseca wrote:
- Original Message -
On Thu, 2011-06-30 at 03:36 +0200, Roland Scheidegger wrote:
Ok in fact there's a gcc bug about memcmp:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
In short gcc's memcmp builtin is totally lame
On Thu, 2011-06-30 at 03:36 +0200, Roland Scheidegger wrote:
Ok in fact there's a gcc bug about memcmp:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
In short gcc's memcmp builtin is totally lame and loses to glibc's
memcmp (including call overhead, no knowledge about alignment etc.) even
Am 30.06.2011 12:14, schrieb Jose Fonseca:
- Original Message -
Hmm.
Forgive my ignorance, but isn't memcmp() on structs pretty prone to
give
incorrect != results, given that there may be padding between members
in
structs and that IIRC gcc struct assignment is member-wise.
https://bugs.freedesktop.org/show_bug.cgi?id=37177
--- Comment #4 from Ivan Iakoupov vox...@gmail.com 2011-06-30 07:43:07 PDT ---
I did a bisect and it worked prior to this commit:
commit dea5e57861ec998cb7ee913a8819752cb9fa946b
Author: Eric Anholt
Date: Mon Feb 14 18:57:49 2011 -0800
On Wed, 2011-06-29 at 16:29 +0400, Vadim Girlin wrote:
---
There is ~20% fps boost with the etqw timenetdemo after this patch.
Btw, it seems that bad performance without that patch is caused by the
occlusion queries, so probably they need some fixes too. I've added some
counters to check it
Am 30.06.2011 16:14, schrieb Adam Jackson:
On Thu, 2011-06-30 at 03:36 +0200, Roland Scheidegger wrote:
Ok in fact there's a gcc bug about memcmp:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
In short gcc's memcmp builtin is totally lame and loses to glibc's
memcmp (including call
On Thu, 2011-06-30 at 17:53 +0200, Roland Scheidegger wrote:
Am 30.06.2011 16:14, schrieb Adam Jackson:
On Thu, 2011-06-30 at 03:36 +0200, Roland Scheidegger wrote:
Ok in fact there's a gcc bug about memcmp:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
In short gcc's memcmp builtin
On Thu, 30 Jun 2011 06:28:13 -0600, Brian Paul brian.e.p...@gmail.com wrote:
On Thu, Jun 30, 2011 at 12:04 AM, Kenneth Graunke kenn...@whitecape.org
wrote:
gl_texture_image::InternalFormat is actually the user requested internal
format, not what the texture actually is. Thus, even though
https://bugs.freedesktop.org/show_bug.cgi?id=38842
Summary: Various valid GLX attributes are rejected by MESA
glxChooseFBConfig
Product: Mesa
Version: 7.10
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Commit 2699fce0d69db5158427c8b6c8194b2eefc5e58b:
The first chunk (/common.py) looks really strange.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Otherwise PIPE_FORMAT_X8B8G8R8_UNORM and friends would fail.
NOTE: This is a candidate for the 7.10 and 7.11 branches.
---
src/mesa/state_tracker/st_format.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
NOTE: This is a candidate for the 7.11 branch.
---
src/mesa/state_tracker/st_format.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 3260297..d1995f1 100644
---
Commit b46dc45ceef3deb17ba2b0b4300eeb93e9cf7833 claimed that
NEW_POLYGONSTIPPLE is gratuitous, but somehow just changed comments
and whitespace instead of actually removing the flag.
While we're at it, 3DSTATE_PS doesn't appear to need NEW_LINE or
NEW_POLYGON either (those are in 3DSTATE_WM).
Hi,
this patch series implements ARB_depth_buffer_float in Mesa and Gallium. There
is complete r600g/r600-r700 support in my private branch, which passes the same
tests that pass for Z24S8. Softpipe has only sampler support. This has turned
out to be not so trivial, so it's possible I missed
Using GL_NONE as DataType of Z32_FLOAT_X24S8, not sure what I should put there.
The spec says the type is n/a.
---
src/mesa/main/fbobject.c | 19 +++
src/mesa/main/formats.c | 29 +
src/mesa/main/formats.h |3 +++
---
src/mesa/main/texfetch.c | 16
src/mesa/main/texfetch_tmp.h | 23 +++
2 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/texfetch.c b/src/mesa/main/texfetch.c
index 4b85bc3..72283eb 100644
--- a/src/mesa/main/texfetch.c
---
src/mesa/main/pack.c | 35 ---
1 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index a232a51..c284c7d 100644
--- a/src/mesa/main/pack.c
+++ b/src/mesa/main/pack.c
@@ -1971,7 +1971,8 @@
---
src/mesa/main/pack.c | 27 +--
1 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index c284c7d..d42ae7b 100644
--- a/src/mesa/main/pack.c
+++ b/src/mesa/main/pack.c
@@ -4827,6 +4827,20 @@
---
src/mesa/main/texstore.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index f1de31a..cdac214 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1002,15 +1002,17 @@
---
src/mesa/main/texstore.c | 68 +-
1 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index cdac214..7e2cafc 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@
---
src/mesa/main/mipmap.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c
index f2724db..8a811cb 100644
--- a/src/mesa/main/mipmap.c
+++ b/src/mesa/main/mipmap.c
@@ -706,6 +706,17 @@ do_row(GLenum
---
src/mesa/state_tracker/st_cb_clear.c |6 --
src/mesa/state_tracker/st_extensions.c | 11 +++
src/mesa/state_tracker/st_format.c | 19 +++
3 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_clear.c
---
src/mesa/state_tracker/st_cb_drawpixels.c | 64 +
src/mesa/state_tracker/st_cb_readpixels.c | 43 +++
2 files changed, 98 insertions(+), 9 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
The suffix of 64 means it returns uint64_t.
---
src/gallium/auxiliary/util/u_pack_color.h | 64 +
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_pack_color.h
b/src/gallium/auxiliary/util/u_pack_color.h
index
---
src/gallium/auxiliary/util/u_surface.c | 35 +++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_surface.c
b/src/gallium/auxiliary/util/u_surface.c
index 4c5cc4d..8fcf6b9 100644
---
And make pipe_put_tile_rgba_format no-op like the other Z formats.
---
src/gallium/auxiliary/util/u_tile.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_tile.c
b/src/gallium/auxiliary/util/u_tile.c
index
---
src/mesa/main/depthstencil.c | 322 +++---
src/mesa/main/depthstencil.h |5 +
src/mesa/main/framebuffer.c | 10 +-
3 files changed, 313 insertions(+), 24 deletions(-)
diff --git a/src/mesa/main/depthstencil.c b/src/mesa/main/depthstencil.c
index
https://bugs.freedesktop.org/show_bug.cgi?id=5002
Trevor Forbes t...@internode.on.net changed:
What|Removed |Added
CC|
On 06/30/2011 05:29 PM, Marek Olšák wrote:
---
src/mesa/main/depthstencil.c | 322
+++---
src/mesa/main/depthstencil.h |5 +
src/mesa/main/framebuffer.c | 10 +-
3 files changed, 313 insertions(+), 24 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=37177
Jason Tibbitts ti...@math.uh.edu changed:
What|Removed |Added
CC||ti...@math.uh.edu
--
On 06/30/2011 05:29 PM, Marek Olšák wrote:
Hi,
this patch series implements ARB_depth_buffer_float in Mesa and Gallium.
There is complete r600g/r600-r700 support in my private branch, which passes
the same tests that pass for Z24S8. Softpipe has only sampler support. This
has turned out
https://bugs.freedesktop.org/show_bug.cgi?id=5002
--- Comment #8 from Trevor Forbes t...@internode.on.net 2011-06-30 21:39:59
PDT ---
I also keep running into this problem with workstations running NVIDIA drivers
180. Try running Googleearth from a remote server for example..
Some people are
52 matches
Mail list logo
