https://bugs.freedesktop.org/show_bug.cgi?id=5002
--- Comment #8 from Trevor Forbes 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 getting around it by
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
https://bugs.freedesktop.org/show_bug.cgi?id=37177
Jason Tibbitts changed:
What|Removed |Added
CC||ti...@math.uh.edu
--
Configure bugmail
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 a/src/mesa/
https://bugs.freedesktop.org/show_bug.cgi?id=5002
Trevor Forbes changed:
What|Removed |Added
CC||t...@internode.on.net
--
Configure bugma
---
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 ab6
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 e3
---
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
--- a/src/gallium/auxiliary/util/u_surf
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 5378f2d..d2df
---
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
b/src/mesa/state_tracker/st_cb_drawpi
---
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
b/src/mesa/s
---
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 datatyp
---
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
@@ -42
---
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 @@ memcpy_texture(st
---
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 @@ _mesa_unpack_depth_spa
---
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 @@ extract_uint_in
---
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
++
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/imag
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 so
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).
Cc:
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
--- a/src/mesa/state
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
b/src/mesa/
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
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
On Thu, 30 Jun 2011 06:28:13 -0600, Brian Paul wrote:
> On Thu, Jun 30, 2011 at 12:04 AM, Kenneth Graunke
> 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 buffe
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 memcm
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 cal
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
https://bugs.freedesktop.org/show_bug.cgi?id=37177
--- Comment #4 from Ivan Iakoupov 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
intel: Use the curre
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 mem
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.) ev
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 t
https://bugs.freedesktop.org/show_bug.cgi?id=37177
--- Comment #3 from Mark van Rossum 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).
--
Configure bugmail:
On Thu, Jun 30, 2011 at 12:04 AM, Kenneth Graunke 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.
> Otherwise, it wro
- 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 overhe
- 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
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
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.) ev
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 poo
On Wed, 29 Jun 2011 23:04:04 -0700, Kenneth Graunke
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.
To support Y-tiling,
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 str
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
---
src/gallium/drivers/svga/svga_pipe_draw.c | 101
We currently always treat contents of user-buffers as volatile so
we don't need to take any particular action when the state tracker
announces that the contents has changed.
Signed-off-by: Thomas Hellstrom
---
.../drivers/svga/svga_resource_buffer_upload.c | 17 ++---
1 files c
From: Brian Paul
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 78f5aa1..358ef82 100644
-
From: Brian Paul
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 is >= the element s
From: José Fonseca
---
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 100644
--- a/src/gallium/
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
This enables us to pack more data into single upload buffers.
Signed-off-by: Thomas Hellstrom
---
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 a/src/gallium/drivers/svga
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 c
From: José Fonseca
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 +++
The main purpose of this patch series is to make sure we always and only upload
the parts of user-buffers that are referenced by the next draw call.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/me
51 matches
Mail list logo
