Hi Eric,
BSpec says VS and WM should fall to single thread to avoid racing if
use scratch space.
Thanks
Zou Nanhai
>>-Original Message-
>>From: mesa-dev-bounces+nanhai.zou=intel@lists.freedesktop.org
>>[mailto:mesa-dev-bounces+nanhai.zou=intel@lists.freedesktop.org] On
>>
On 04/14/2011 11:57 PM, Zou, Nanhai wrote:
> Eric,
> I think for gen6 most of the DP read in the pipeline should go through
> constant cache instead of other caches. Maybe we should implement an
> gen6_const_read_message.
> That is better for performance.
> Thanks
> Zou Nanhai
Probab
On 04/15/2011 12:00 AM, Zou, Nanhai wrote:
> Hi Eric,
> BSpec says VS and WM should fall to single thread to avoid racing if
> use scratch space.
>
> Thanks
> Zou Nanhai
Hrm. Do you have a volume/section reference? I thought that scratch
space was done (or could be done) on a per-thread
I think that probably not single thread.
But Bspec says to recalculate max vs and wm thread if using scratch to avoid
use out scrach space and to avoid deadlock.
I don't know what the deadlock means there.
Thanks
Zou Nanhai
>>-Original Message-
>>From: mesa-dev-bounces+nanhai.zou=inte
Thanks. I'm committing this with a minor change. The line:
dst[col*4+3] |= alphaORoperand;
can be:
dst[col*4+3] = 0xff;
since alphaORoperand is known to be 0xff at this point.
-Brian
On 04/14/2011 10:31 AM, Pierre-Eric Pelloux-Prayer wrote:
Updated patch as I was told that
https://bugs.freedesktop.org/show_bug.cgi?id=36242
--- Comment #1 from Michel Dänzer 2011-04-15 08:00:11 PDT
---
(In reply to comment #1)
> Is there a way or a parameter to disable building that driver [vmwgfx]?
--disable-gallium-svga
--
Configure bugmail: https://bugs.freedesktop.org/userpre
On Fri, 15 Apr 2011 15:14:14 +0800, "Zou, Nanhai" wrote:
>
> I think that probably not single thread.
> But Bspec says to recalculate max vs and wm thread if using scratch to avoid
> use out scrach space and to avoid deadlock.
> I don't know what the deadlock means there.
You really need to q
Hi Marek,
Back on Jan 10 you removed the per-vertex array max_index field
(commit cdca3c58aa2d9549f5188910e2a77b438516714f). I believe this was
a mistake.
I noticed today that the piglit draw-instanced-divisor test is
failing. A bisection points to Jose's commit
17bbc1f0425b3768e26473ecc
Hi,
I'm having trouble running any OpenGL ES programs from mesa-demos. It
seems to be identical to what was reported here
http://comments.gmane.org/gmane.comp.video.mesa3d.devel/22575
I'm using a Sandy Bridge system. Direct Rendering is working.
Mesa was configured with
./configure --prefix=/usr
On 15.04.2011 18:04, Brian Paul wrote:
>
> Hi Marek,
>
> Back on Jan 10 you removed the per-vertex array max_index field
> (commit cdca3c58aa2d9549f5188910e2a77b438516714f). I believe this was
> a mistake.
>
> I noticed today that the piglit draw-instanced-divisor test is
> failing. A bisection p
On Sat, Apr 16, 2011 at 2:20 AM, Matt Turner wrote:
> Hi,
> I'm having trouble running any OpenGL ES programs from mesa-demos. It
> seems to be identical to what was reported here
> http://comments.gmane.org/gmane.comp.video.mesa3d.devel/22575
>
> I'm using a Sandy Bridge system. Direct Rendering
The 095-recursive-define test case was triggering infinite recursion
with the following test case:
#define A(a, b) B(a, b)
#define C A(0, C)
C
Here's what as happening:
1. "C" was pushed onto the active list to expand the C node
2. While expanding the "0" argument, t
https://bugs.freedesktop.org/show_bug.cgi?id=36242
--- Comment #2 from Alexandre Demers 2011-04-15
12:11:33 PDT ---
(In reply to comment #1)
> (In reply to comment #1)
> > Is there a way or a parameter to disable building that driver [vmwgfx]?
>
> --disable-gallium-svga
Yes, of course. The kin
On Fri, Apr 15, 2011 at 2:39 PM, Chia-I Wu wrote:
> On Sat, Apr 16, 2011 at 2:20 AM, Matt Turner wrote:
>> Hi,
>> I'm having trouble running any OpenGL ES programs from mesa-demos. It
>> seems to be identical to what was reported here
>> http://comments.gmane.org/gmane.comp.video.mesa3d.devel/225
On 04/15/2011 07:20 PM, Christoph Bumiller wrote:
On 15.04.2011 18:04, Brian Paul wrote:
Hi Marek,
Back on Jan 10 you removed the per-vertex array max_index field
(commit cdca3c58aa2d9549f5188910e2a77b438516714f). I believe this was
a mistake.
I noticed today that the piglit draw-instance
On 04/15/2011 01:41 PM, José Fonseca wrote:
On 04/15/2011 07:20 PM, Christoph Bumiller wrote:
On 15.04.2011 18:04, Brian Paul wrote:
Hi Marek,
Back on Jan 10 you removed the per-vertex array max_index field
(commit cdca3c58aa2d9549f5188910e2a77b438516714f). I believe this was
a mistake.
I n
On 04/15/2011 08:51 PM, Brian Paul wrote:
On 04/15/2011 01:41 PM, José Fonseca wrote:
On 04/15/2011 07:20 PM, Christoph Bumiller wrote:
On 15.04.2011 18:04, Brian Paul wrote:
Hi Marek,
Back on Jan 10 you removed the per-vertex array max_index field
(commit cdca3c58aa2d9549f
On 04/15/2011 09:14 PM, José Fonseca wrote:
On 04/15/2011 08:51 PM, Brian Paul wrote:
On 04/15/2011 01:41 PM, José Fonseca wrote:
On 04/15/2011 07:20 PM, Christoph Bumiller wrote:
On 15.04.2011 18:04, Brian Paul wrote:
Hi Marek,
Back on Jan 10 you removed the per-vertex ar
Hi Brian,
The main reason for removal of pipe_vertex_buffer::max_index was its direct
dependence on pipe_draw_info. The vertex buffer field was directly computed
from the parameters of pipe_draw_info instead of being a completely
independent state. So we ended up doing this in st/mesa:
set_vertex
Nice straightforward fix. Thanks, Carl.
Reviewed-and-tested-by: Kenneth Graunke
(I tested this with piglit -t glsl -t gtf...no regressions.)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/15/2011 12:03 PM, Carl Worth wrote:
> The 095-recursive-define test case was triggering infinite recursion
> with the following test case:
>
> #define A(a, b) B(a, b)
> #define C A(0, C)
> C
>
> Here's what as happening:
>
>
On 04/15/2011 02:17 PM, José Fonseca wrote:
On 04/15/2011 09:14 PM, José Fonseca wrote:
On 04/15/2011 08:51 PM, Brian Paul wrote:
On 04/15/2011 01:41 PM, José Fonseca wrote:
On 04/15/2011 07:20 PM, Christoph Bumiller wrote:
On 15.04.2011 18:04, Brian Paul wrote:
Hi Marek,
Back on Jan 10
On 04/15/2011 03:33 PM, Marek Olšák wrote:
Hi Brian,
The main reason for removal of pipe_vertex_buffer::max_index was its
direct dependence on pipe_draw_info. The vertex buffer field was
directly computed from the parameters of pipe_draw_info instead of being
a completely independent state. So w
https://bugs.freedesktop.org/show_bug.cgi?id=36182
Thomas Kowaliczek changed:
What|Removed |Added
CC||linuxdon...@linuxdonald.de
--
Confi
https://bugs.freedesktop.org/show_bug.cgi?id=36282
Summary: glxgears segfault with swrast
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=36282
--- Comment #1 from Andrew Randrianasulu 2011-04-15 20:09:40
PDT ---
Created an attachment (id=45688)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45688)
config.log from Mesa's source tree
I used ./autogen.sh first, then make distclean
This patch series cleans out the last vestiges of fixed-function fog
support with ARB_fragment_program. We talked about doing this quite
some time ago, but we decided to hold off. The thinking at the time
was that there was still a chance that someone might add support for
the fixed-function fog
From: Ian Romanick
This patch fixes two bugs related to fog in the fixed-function
fragment shader generation code.
Fog was only lowered to instructions if MRTs were used. The fragment
shader assembler always lowers "fog option" code to instructions, and
many drivers (e.g., r300) expect this.
W
From: Ian Romanick
---
src/mesa/swrast/s_context.c | 15 ---
src/mesa/tnl/t_context.c| 12
2 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/src/mesa/swrast/s_context.c b/src/mesa/swrast/s_context.c
index 491fcfc..b3e3968 100644
--- a/src/mesa/swras
From: Ian Romanick
---
src/mesa/drivers/dri/i965/brw_program.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index b5ec55b..6674f16 100644
--- a/src/mesa/drivers/dri/i965/brw_program
From: Ian Romanick
---
src/mesa/drivers/dri/i915/i915_fragprog.c |9 -
src/mesa/drivers/dri/i915/i915_state.c|4 ++--
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index 7
From: Ian Romanick
All drivers expect this to always be GL_NONE. Don't let there be any
opportunity for a bad value to leak out and infect some unsuspecting
driver. If any driver for hardware that had fixed-function
per-fragment fog (i915 and perhaps some r300-ish) was ever going to
add support
From: Ian Romanick
---
src/mesa/drivers/dri/i915/i915_state.c | 55
1 files changed, 0 insertions(+), 55 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_state.c
b/src/mesa/drivers/dri/i915/i915_state.c
index 5c7c0c3..05fc26f 100644
--- a/src/mesa/dri
From: Ian Romanick
Fragment programs are generated by core Mesa for fixed-function.
Because of this, there's no reason to handle cases where there is no
fragment program for fog.
---
src/mesa/drivers/dri/i915/i915_state.c | 31 +--
1 files changed, 5 insertions(+),
From: Ian Romanick
---
src/mesa/drivers/dri/i915/i915_context.h |5 -
src/mesa/drivers/dri/i915/i915_fragprog.c |2 +-
src/mesa/drivers/dri/i915/i915_state.c|2 --
3 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_context.h
b/src/
From: Ian Romanick
None of this ever gets used. Fog is always calculated by a fragment
program. Even though the fixed-function fog unit is never used, state
updates are still sent to the hardware. Removing those spurious state
updates can't hurt performance.
---
src/mesa/drivers/dri/i915/i915
36 matches
Mail list logo
