headers
vehemens | 1 Oct 2007 03:40
Picon

RADEON RV350 Rendering Stalls

I'm seeing my RADEON RV350 stall (~1 FPS) when running the engine demo with 
the wire frame rendering style.  The other styles run ~140 FPS.

Switching to a RV250 results in ~160 FPS or better for all rendering styles.

This is with the MESA/DRI/ATI/X development master branches as of the last few 
days.  I don't have data on when the problem started.

Anyone else seeing this problem, or have any suggestions on where the cause 
might be?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 2 comments |
headers
Michel Dänzer | 1 Oct 2007 09:07

Re: RADEON RV350 Rendering Stalls


On Sun, 2007-09-30 at 18:40 -0700, vehemens wrote:
> I'm seeing my RADEON RV350 stall (~1 FPS) when running the engine demo with 
> the wire frame rendering style.  The other styles run ~140 FPS.
> 
> Switching to a RV250 results in ~160 FPS or better for all rendering styles.
> 
> This is with the MESA/DRI/ATI/X development master branches as of the last few 
> days.  I don't have data on when the problem started.
> 
> Anyone else seeing this problem, or have any suggestions on where the cause 
> might be?

*********************************WARN_ONCE*********************************
File r300_render.c function r300Fallback line 364
Software fallback:ctx->Line.SmoothFlag
***************************************************************************

Enable the driconf option disable_lowimpact_fallback to trade in
correctness for speed.

--

-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
bugzilla-daemon | 1 Oct 2007 15:37

[Bug 12614] segfault inside quadfunc_unfilled_rgba()

http://bugs.freedesktop.org/show_bug.cgi?id=12614

------- Comment #4 from ademar <at> mandriva.com.br  2007-10-01 06:39 PST -------
My git tree was from friday. Anyway, I tried with today's git, but no luck yet:

Starting program: /usr/games/neverball.bin 
[Thread debugging using libthread_db enabled]
[New Thread -1217902896 (LWP 5462)]
[New Thread -1220617328 (LWP 5465)]
Mesa: CPU vendor: GenuineIntel
Mesa: CPU name: Intel(R) Celeron(R) M CPU        410   <at>  1.46GHz
Mesa: MMX cpu detected.
Mesa: SSE cpu detected.
Mesa: Not testing OS support for SSE, leaving enabled.
Mesa: Mesa 7.0.2 DEBUG build Oct  1 2007 10:16:05
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1217902896 (LWP 5462)]
0xb6ad1fc7 in quadfunc_unfilled_rgba (ctx=0x81d8f80, v0=0, v1=1, v2=2, v3=3)
    at swrast_setup/ss_tritmp.h:201
201           GLubyte ef1 = VB->EdgeFlag[v1];
(gdb) bt
#0  0xb6ad1fc7 in quadfunc_unfilled_rgba (ctx=0x81d8f80, v0=0, v1=1, v2=2,
v3=3)
    at swrast_setup/ss_tritmp.h:201
#1  0xb6a4c37b in _tnl_render_quads_verts (ctx=0x81d8f80, start=0, count=4,
flags=55)
    at tnl/t_vb_rendertmp.h:338
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Whitwell | 1 Oct 2007 16:28

t_vp_build.c, vertex program generation

Looking back at the development of the fixed_function->vertex shader 
code, one of the things that we did was try to ensure that the generated 
vertex program had an output that matched exactly each input of the 
currently active fragment shader.

This served two purposes:
1) Some hardware really seemed to want this (r300?)
2) It allowed some minor optimizations of the generated shader.

I think that doing these things in t_vp_build.c was probably the wrong 
choice.

First of all, regarding (1), I think it is acceptable for an application 
to create and use vertex shaders that don't specify all the inputs of 
the fragment shader - it is up to GL to figure out where the extra 
inputs come from.  That same mechanism should cope with internally 
generated shaders also.

Regarding (2), if the optimizations (dead code removal based on fragprog 
inputs_read) are significant, they should be used in all vertex 
programs, not just those generated by t_vp_build.c.

In other words, both of these tasks probably should be handled elsewhere.

I'd like to do the following:

- remove dependency on fragprog.inputs_read from t_vp_build.c
- move t_vp_build.c and texenvprogram.c together somewhere, probably 
move t_vp_build.c out of the tnl/ module and into src/mesa/main.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Roland Scheidegger | 1 Oct 2007 17:50

Re: t_vp_build.c, vertex program generation

Keith Whitwell wrote:
> Looking back at the development of the fixed_function->vertex shader 
> code, one of the things that we did was try to ensure that the generated 
> vertex program had an output that matched exactly each input of the 
> currently active fragment shader.
> 
> This served two purposes:
> 1) Some hardware really seemed to want this (r300?)
> 2) It allowed some minor optimizations of the generated shader.
> 
> I think that doing these things in t_vp_build.c was probably the wrong 
> choice.
> 
> First of all, regarding (1), I think it is acceptable for an application 
> to create and use vertex shaders that don't specify all the inputs of 
> the fragment shader - it is up to GL to figure out where the extra 
> inputs come from.  That same mechanism should cope with internally 
> generated shaders also.
> 
> Regarding (2), if the optimizations (dead code removal based on fragprog 
> inputs_read) are significant, they should be used in all vertex 
> programs, not just those generated by t_vp_build.c.
> 
> In other words, both of these tasks probably should be handled elsewhere.
> 
> I'd like to do the following:
> 
> - remove dependency on fragprog.inputs_read from t_vp_build.c
> - move t_vp_build.c and texenvprogram.c together somewhere, probably 
> move t_vp_build.c out of the tnl/ module and into src/mesa/main.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Keith Whitwell | 1 Oct 2007 18:11

Re: t_vp_build.c, vertex program generation

Roland Scheidegger wrote:
> Keith Whitwell wrote:
>> Looking back at the development of the fixed_function->vertex shader 
>> code, one of the things that we did was try to ensure that the generated 
>> vertex program had an output that matched exactly each input of the 
>> currently active fragment shader.
>>
>> This served two purposes:
>> 1) Some hardware really seemed to want this (r300?)
>> 2) It allowed some minor optimizations of the generated shader.
>>
>> I think that doing these things in t_vp_build.c was probably the wrong 
>> choice.
>>
>> First of all, regarding (1), I think it is acceptable for an application 
>> to create and use vertex shaders that don't specify all the inputs of 
>> the fragment shader - it is up to GL to figure out where the extra 
>> inputs come from.  That same mechanism should cope with internally 
>> generated shaders also.
>>
>> Regarding (2), if the optimizations (dead code removal based on fragprog 
>> inputs_read) are significant, they should be used in all vertex 
>> programs, not just those generated by t_vp_build.c.
>>
>> In other words, both of these tasks probably should be handled elsewhere.
>>
>> I'd like to do the following:
>>
>> - remove dependency on fragprog.inputs_read from t_vp_build.c
>> - move t_vp_build.c and texenvprogram.c together somewhere, probably
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Oct 2007 18:54

[Bug 12614] segfault inside quadfunc_unfilled_rgba()

http://bugs.freedesktop.org/show_bug.cgi?id=12614

------- Comment #5 from ademar <at> mandriva.com.br  2007-10-01 09:56 PST -------
A simple check for the validity of VB->EdgeFlag workarounded the problem,
without major consequences so far:

--- mesa-7.0-git-2007-10-01/src/mesa/swrast_setup/ss_tritmp.h.orig   2007-09-29
15:01:47.000000000 -0300
+++ mesa-7.0-git-2007-10-01/src/mesa/swrast_setup/ss_tritmp.h   2007-10-01
13:40:17.000000000 -0300
 <at>  <at>  -198,6 +198,8  <at>  <at>  static void TAG(quadfunc)( GLcontext *ct
 {
    if (IND & SS_UNFILLED_BIT) {
       struct vertex_buffer *VB = &TNL_CONTEXT(ctx)->vb;
+         if (!VB->EdgeFlag)
+                 return;
       GLubyte ef1 = VB->EdgeFlag[v1];
       GLubyte ef3 = VB->EdgeFlag[v3];
       VB->EdgeFlag[v1] = 0;

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 2 Oct 2007 19:41

[Bug 12652] RV370 [FireGL V3100 (PCIE)] Xorg Crash with Option "DRI" "false"

http://bugs.freedesktop.org/show_bug.cgi?id=12652

jcristau <at> debian.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|xorg-driver-ati <at> lists.x.org |mesa3d-
                   |                            |dev <at> lists.sourceforge.net
          QAContact|xorg-team <at> lists.x.org       |

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 2 Oct 2007 21:38

[Bug 12614] segfault inside quadfunc_unfilled_rgba()

http://bugs.freedesktop.org/show_bug.cgi?id=12614

------- Comment #6 from cmatsuoka <at> gmail.com  2007-10-02 12:40 PST -------
The following patch is needed to fix a problem in
generic_read_RGBA_span_RGB565_MMX (x86/read_rgba_span_x86.S) that causes a
crash with Neverball and Metisse in the ATI 9250 card after the previous
workaround is applied:

diff -rud a/Mesa-7.0.1-mdv/src/mesa/x86/read_rgba_span_x86.S
Mesa-7.0.1-mdv/src/mesa/x86/read_rgba_span_x86.S
--- a/Mesa-7.0.1-mdv/src/mesa/x86/read_rgba_span_x86.S  2007-06-21
19:10:55.000000000 -0300
+++ Mesa-7.0.1-mdv/src/mesa/x86/read_rgba_span_x86.S    2007-10-02
15:36:32.000000000 -0300
 <at>  <at>  -587,17 +587,17  <at>  <at> 
        movq    prescale, %mm6
        movq    scale, %mm7
  */
-       pushl   MASK_565_H
-       pushl   MASK_565_L
+       pushl   $MASK_565_H
+       pushl   $MASK_565_L
        movq    (%esp), %mm5
-       pushl   PRESCALE_H
-       pushl   PRESCALE_L
+       pushl   $PRESCALE_H
+       pushl   $PRESCALE_L
        movq    (%esp), %mm6
-       pushl   SCALE_H
-       pushl   SCALE_L
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 3 Oct 2007 12:50

[Bug 12614] segfault inside quadfunc_unfilled_rgba()

http://bugs.freedesktop.org/show_bug.cgi?id=12614

cmatsuoka <at> gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cmatsuoka <at> gmail.com

------- Comment #7 from cmatsuoka <at> gmail.com  2007-10-03 03:52 PST -------
Some extra information available at
http://helllabs.org/blog/20071002/mesa-quiz-spot-the-bug-with-patch

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 0 comments |

Gmane