For those interested in VDPAU, I've created a new mailing list,
vd...@lists.freedesktop.org.
http://lists.freedesktop.org/mailman/listinfo/vdpau
-- Aaron
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/lis
Draw module (aaline, aapoint, and pstipple stages) will also be broken with
PIPE_SHADER_CAP_OUTPUT_READ=1.
llvmpipe too, has analysis which rely on outputs not being read.
Nothing of the above matters to r600, of course.
Nevertheless, I can't help thinking that PIPE_SHADER_CAP_OUTPUT_READ is a
https://bugs.freedesktop.org/show_bug.cgi?id=46376
--- Comment #1 from libo 2012-02-21 19:20:05 UTC ---
The bug also exists when run the case with LIBGL_ALWAYS_SOFTWARE=1.
Some mesa xdemos and EGL cases such as opengles2/es2_info also has this bug.
--
Configure bugmail: https://bugs.freedeskt
We always mapped the query buffer in begin_query, causing stalls
if the buffer was busy.
This commit reworks it such that the query buffer is only mapped
in get_query_result as it's supposed to be.
The query buffer is no longer treated as a ring buffer. Instead, the results
are just appended and
---
src/gallium/drivers/r600/evergreen_hw_context.c |4 ++--
src/gallium/drivers/r600/r600_hw_context.c |8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index
---
src/gallium/drivers/r600/evergreen_hw_context.c | 15 +--
src/gallium/drivers/r600/r600_hw_context.c |2 +-
src/gallium/drivers/r600/r600_hw_context_priv.h |1 +
3 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_con
---
src/gallium/drivers/r600/evergreen_hw_context.c | 31 +-
src/gallium/drivers/r600/r600_hw_context.c |4 +-
src/gallium/drivers/r600/r600_hw_context_priv.h |1 +
3 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen
---
src/gallium/drivers/r600/evergreen_hw_context.c | 21 -
src/gallium/drivers/r600/evergreen_state.c | 16
src/gallium/drivers/r600/r600.h |3 ---
src/gallium/drivers/r600/r600_state_common.c| 21 +
4 fil
---
src/gallium/drivers/r600/evergreen_hw_context.c | 16
src/gallium/drivers/r600/r600_hw_context.c |4 ++--
src/gallium/drivers/r600/r600_hw_context_priv.h |1 +
3 files changed, 3 insertions(+), 18 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_
---
src/gallium/drivers/r600/evergreen_hw_context.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src/gallium/drivers/r600/evergreen_hw_context.c
index 75fca22..a58570e 100644
--- a/src/gallium/drivers/r600/ever
---
src/gallium/drivers/r600/r600_pipe.c | 37 +
1 files changed, 15 insertions(+), 22 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index b2b79cd..53f9bd6 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
It may happen if util_slab_create has not been called.
---
src/gallium/auxiliary/util/u_slab.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_slab.c
b/src/gallium/auxiliary/util/u_slab.c
index 21bf2d7..f9f5ef6 100644
--- a/src/gallium/
---
src/gallium/drivers/r600/r600_hw_context.c | 36 ---
src/gallium/drivers/r600/r600_pipe.c | 27 +---
2 files changed, 38 insertions(+), 25 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw
---
src/gallium/drivers/r600/evergreen_hw_context.c | 16
src/gallium/drivers/r600/r600_hw_context.c | 18 --
src/gallium/drivers/r600/r600_pipe.c| 16
3 files changed, 16 insertions(+), 34 deletions(-)
diff --git a/src/gall
---
src/gallium/drivers/r600/evergreen_hw_context.c |2 --
src/gallium/drivers/r600/r600_hw_context.c |2 --
src/gallium/drivers/r600/r600_hw_context_priv.h |2 ++
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c
b/src
Hi everyone,
Besides the cleanups, there are fixes for create_context fail paths and rework
of queries. The rework is the most important, because it eliminates buffer_map
calls (and therefore buffer_wait) in begin_query.
There are no piglit regressions on Evergreen.
Please review.
Marek Olšák
The ralloc string appending functions were originally intended for
simple, non-hot-path uses like printing to an info log.
Cuts Unigine Tropics load time by around 20% (6 seconds).
Signed-off-by: Kenneth Graunke
---
src/glsl/glcpp/glcpp-parse.y | 48 ++---
Both callers of rewrite_tail immediately compute the new total string
length by adding the (known) length of the existing string plus the
length of the newly appended text. Unfortunately, callers generally
won't know the length of the new text, as it's printf-formatted.
Since ralloc already compu
Marek Olšák [2012-02-21 21:36]:
> Hi Tilman,
>
> Thanks for the info. I didn't consider outputs to be readable, sorry.
> A quick fix would be to move the outputs to temps. There is a GLSL pass
> for that and it can be enabled by reporting
> PIPE_SHADER_CAP_OUTPUT_READ --> 0 in r600_pipe.c. Can you
GBM needs the buffer format in order to communicate with DRM and clients
for things like scanout.
So track the DRI format requested in the various back ends and use it to
return the DRI format back to GBM when requested. GBM will then map
this into the GBM surface type (which is in turn based on
https://bugs.freedesktop.org/show_bug.cgi?id=40059
Kenneth Graunke changed:
What|Removed |Added
Version|git |8.0
--- Comment #5 from Kenneth Graunk
Hi Tilman,
Thanks for the info. I didn't consider outputs to be readable, sorry.
A quick fix would be to move the outputs to temps. There is a GLSL pass
for that and it can be enabled by reporting
PIPE_SHADER_CAP_OUTPUT_READ --> 0 in r600_pipe.c. Can you try that and
see if it helps?
To Vadim: No
Tilman Sauerbeck [2012-02-12 11:31]:
> Marek Olšák [2012-01-23 13:32]:
> > For ARB_color_buffer_float. Most hardware can't do it and st/mesa is
> > the perfect place for a fallback.
>
> This breaks lighting in Heroes of Newerth on my rv730:
> http://files.code-monkey.de/frag_color_clamp_bad.png
https://bugs.freedesktop.org/show_bug.cgi?id=40059
Kenneth Graunke changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|i...@freed
On Sun, 19 Feb 2012 13:31:33 +0800, Liu Aleaxander wrote:
> On Sun, Feb 19, 2012 at 8:54 AM, Eric Anholt wrote:
> > On Sat, 18 Feb 2012 23:07:32 +0800, Liu Aleaxander
> > wrote:
> >> + /*
> >> + * gl_PointCoord is a FS instead of VS builtin variable, thus is not
> >> + * included in c->
On 02/14/2012 08:46 PM, Eric Anholt wrote:
This reduces recomputation of state based on non-clipping-related
transform changes, and is a step toward removing VUE map
recomputation.
This looks fantastic. There's really no point in doing all this
computation over and over. Compile time makes f
On 02/14/2012 08:46 PM, Eric Anholt wrote:
With this and the previous patch, 640x480 nexuiz is running 0.169118%
+/- 0.0863696% faster (n=121). On a VS state change microbenchmark,
performance is increased 8.28645% +/- 0.460478% (n=52).
---
To those who saw me throwing my hands in the air sayi
On Tue, 21 Feb 2012 10:39:11 -0800, Kenneth Graunke
wrote:
> Fixes GPU hangs in OilRush, which does depth buffer clears with MRT.
Reviewed-by: Eric Anholt
pgpmDr7oriDD7.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesk
Fixes GPU hangs in OilRush, which does depth buffer clears with MRT.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_eu_emit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_em
Am 21.02.2012 16:08, schrieb Jose Fonseca:
> - Original Message -
>> On 02/21/2012 02:22 AM, Jose Fonseca wrote:
>>> Your series is a huge step forward already. But I wonder if we
>>> could go just a bit further and not add
>>> MAX_VIEWPORT_WIDTH/HEIGHT and MAX_RENDERBUFFER_SIZE defines.
Sorry that I send the patch twice, the network connection here was
terrifying bad just now.
On 2/21/12, Liu Aleaxander wrote:
> This patch(the way to fix this issue) is a little weird, as we already
> fallbacked to swrast when handling gl_PointSize(in vertex shader).
> Sounds that we didn't fallb
This patch(the way to fix this issue) is a little weird, as we already
fallbacked to swrast when handling gl_PointSize(in vertex shader).
Sounds that we didn't fallback enough;) This patch servers as fixing the
gl_PointSize issue on Pineview platform.
Since the patch is a little weird, I thought a
This patch(the way to fix this issue) is a little weird, as we already
fallbacked to swrast when handling gl_PointSize(in vertex shader).
Sounds that we didn't fallback enough;) This patch servers as fixing the
gl_PointSize issue on Pineview platform.
Since the patch is a little weird, I thought a
- Original Message -
> On 02/21/2012 02:22 AM, Jose Fonseca wrote:
> > Your series is a huge step forward already. But I wonder if we
> > could go just a bit further and not add MAX_VIEWPORT_WIDTH/HEIGHT
> > and MAX_RENDERBUFFER_SIZE defines.
> >
> > Would it be possible to derive these li
On 02/21/2012 02:22 AM, Jose Fonseca wrote:
Your series is a huge step forward already. But I wonder if we could go just a
bit further and not add MAX_VIEWPORT_WIDTH/HEIGHT and MAX_RENDERBUFFER_SIZE
defines.
Would it be possible to derive these limits from the maximum texture size?
Either th
On 02/21/2012 01:30 AM, Jose Fonseca wrote:
Shouldn't malloc be passed zoomedWidth instead of width?
Oops, yes. I'll fix that patch.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-
https://bugs.freedesktop.org/show_bug.cgi?id=45292
Sven Eden changed:
What|Removed |Added
CC||yamakuz...@gmx.net
--
Configure bugmail: ht
https://bugs.freedesktop.org/show_bug.cgi?id=45292
--- Comment #5 from Sven Eden 2012-02-21 03:42:29 PST ---
Created attachment 57383
--> https://bugs.freedesktop.org/attachment.cgi?id=57383
Re-insert neccessary typedef for ID3D10Include
Hi!
I have been able to get past this error with the at
Throw out all the old and now unneeded stuff.
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/decode.c |2 +-
src/gallium/state_trackers/vdpau/device.c | 10 +-
src/gallium/state_trackers/vdpau/mixer.c |8 +-
src/gallium/state_trackers/vd
BTW, besides the remarks I made, the series looks great. Quite a nice cleanup.
Jose
- Original Message -
> From: Brian Paul
>
> ---
> src/mesa/main/config.h | 40
>
> src/mesa/swrast/s_chan.h |8
> src/mesa/swrast/swrast.h |
Your series is a huge step forward already. But I wonder if we could go just a
bit further and not add MAX_VIEWPORT_WIDTH/HEIGHT and MAX_RENDERBUFFER_SIZE
defines.
Would it be possible to derive these limits from the maximum texture size?
Either the driver reported max texture size, or just de
https://bugs.freedesktop.org/show_bug.cgi?id=46376
Bug #: 46376
Summary: display window will be black when run mesa demo gloss
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: All
OS/Version: Linux (All)
Shouldn't malloc be passed zoomedWidth instead of width?
Jose
- Original Message -
> From: Brian Paul
>
> ---
> src/mesa/swrast/s_zoom.c | 16 ++--
> 1 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/swrast/s_zoom.c b/src/mesa/swrast/s_zoom.c
>
43 matches
Mail list logo
