[Bug 5459] Quake 4 darkness

2006-01-06 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=5459  
 




--- Additional Comments From [EMAIL PROTECTED]  2006-01-06 18:49 ---
(In reply to comment #2)
 I'm not able to test this myself on r300 hardware currently.  How does the 
 test
 case fail? ie. complete blackness, or just the wrong image?

First one was black and second darkish.
However, I tested this again on r480 and got different results.
Some more testing reveals that sometimes it works and sometimes not.
Im suspecting undefined z or w component is leaking into to the tex instruction,
thus causing random behaviour.

 
 Also, are you able to turn on the dump_program() call at the end of
 translate_fragment_shader() and post the output please?

I have been able to reproduce this with another program:
!!ARBfp1.0\n
ATTRIB i0 = fragment.color;
TEMP t0, t1;
MOV t0, i0;
TEX result.color, t0, texture[0], 2D;
END

I either get zero visible fragments with this or then it works as expected.

output:

pc=1*
Mesa program:
-
  0: MOV TEMP[0], INPUT[1];
  1: TEX  OUTPUT[0], TEMP[0], texture[0], 2D
  2: END;
Hardware program


tex:
8081

NODE 0: alu_offset: 0, tex_offset: 0, alu_end: 0, tex_end: -1
NODE 1: alu_offset: 1, tex_offset: 0, alu_end: 1, tex_end: 0
00011230
00050a80
00050a80
000111b0
03860800
1c020802
00011270
00040889
00040889
000111f0
00860800
01020802
  
 
 
--   
Configure bugmail: https://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: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: persistant problems with drm + mga

2006-01-06 Thread David Mulcahy
Hello again

Just for the record I have downgraded to debian stable just to check a few 
things and the speed difference is definitely noticeable.  glxgears cogs fly 
in debian stable and in blender a simple textured round shape moves with no 
delay/jitter.  with latest X and 2.4.15 kernel the same shape shows 
noticeable delay/jitter.  Seems like a performance regression to me (but I am 
no expert).

Dave


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[r300] Fragment program ops + questions

2006-01-06 Thread Rune Petersen
I've been having some fun with fragment shader and found allot of ops 
missing. someone might be interested in some more ops.


Fragment ops added:
- ABS
- CMP
- DP4
- DPH
- DST
- EX2
- FLR
- FRC
- LG2
- MAX
- MIN
- RCP
- SGE
- SLT
- XPD

Fragment ops still missing:
- COS
- KIL
- LIT
- SCS
- SIN

They all pass the basic test in Mesa/progs/fp though Humus demos 
(www.humus.ca) still are far from looking proper.


Now the Questions:

- Missing Commit from r300.sf.net:
When trying to Implement the KIL ops I found a commit by Ben Skeggs on 
r300.sf.net that was lost in the Mesa tree:


http://sourceforge.net/mailarchive/forum.php?thread_id=7728162forum_id=42268

At the very least the changes for r300_reg.h should be included in Mesa.

- whats with the DP3 op?

if (fpi-DstReg.WriteMask  WRITEMASK_W) {
/* I assume these need to share the same alu slot */
sync_streams(rp);
emit_arith(rp, PFS_OP_DP4, dest, WRITEMASK_W,
pfs_zero, pfs_zero, pfs_zero,
flags);
}
emit_arith(rp, PFS_OP_DP3, t_dst(rp, fpi-DstReg),
fpi-DstReg.WriteMask  WRITEMASK_XYZ,
t_src(rp, fpi-SrcReg[0]),
t_src(rp, fpi-SrcReg[1]),
pfs_zero, flags);

Why is DP4 called for W and why does DP3 excluding W?
I don't see how it can conform to the specs:

  tmp0 = VectorLoad(op0);
  tmp1 = VectorLoad(op1);
  dot = (tmp0.x * tmp1.x) + (tmp0.y * tmp1.y) + (tmp0.z * tmp1.z);
  result.x = dot;
  result.y = dot;
  result.z = dot;
  result.w = dot;
Index: r300_fragprog.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_fragprog.c,v
retrieving revision 1.16
diff -u -r1.16 r300_fragprog.c
--- r300_fragprog.c 20 Nov 2005 17:52:40 -  1.16
+++ r300_fragprog.c 6 Jan 2006 15:47:45 -
@@ -763,7 +763,10 @@

switch (fpi-Opcode) {
case OPCODE_ABS:
-   ERROR(unknown fpi-Opcode %d\n, fpi-Opcode);
+   // test:
+   emit_arith(rp, PFS_OP_MAD, t_dst(rp, fpi-DstReg), 
fpi-DstReg.WriteMask,
+   t_src(rp, 
fpi-SrcReg[0]), pfs_one, pfs_zero, 
+   flags | PFS_FLAG_ABS);
break;
case OPCODE_ADD:
emit_arith(rp, PFS_OP_MAD, t_dst(rp, fpi-DstReg), 
fpi-DstReg.WriteMask,
@@ -773,6 +776,13 @@
flags);
break;
case OPCODE_CMP:
+   //test:
+   emit_arith(rp, PFS_OP_CMP, t_dst(rp, fpi-DstReg), 
fpi-DstReg.WriteMask,
+   t_src(rp, 
fpi-SrcReg[2]),
+   t_src(rp, 
fpi-SrcReg[1]),
+   t_src(rp, 
fpi-SrcReg[0]),
+   flags);
+   break;
case OPCODE_COS:
ERROR(unknown fpi-Opcode %d\n, fpi-Opcode);
break;
@@ -792,13 +802,108 @@
pfs_zero, flags);
break;
case OPCODE_DP4:
+   //test:
+   emit_arith(rp, PFS_OP_DP4, t_dst(rp, fpi-DstReg),
+   fpi-DstReg.WriteMask,
+   t_src(rp, 
fpi-SrcReg[0]),
+   t_src(rp, 
fpi-SrcReg[1]),
+   pfs_zero, flags);
+   break;
case OPCODE_DPH:
+   //test:
+   src0 = t_src(rp, fpi-SrcReg[0]);
+   src1 = t_src(rp, fpi-SrcReg[1]);
+   dest = t_dst(rp, fpi-DstReg);
+   
+   temp = get_temp_reg(rp);
+   
+   if (fpi-DstReg.WriteMask  WRITEMASK_W) {
+   /* I assume these need to share the same alu 
slot */
+   sync_streams(rp);
+   emit_arith(rp, PFS_OP_DP4, temp, WRITEMASK_W, 
+   pfs_zero, 
pfs_zero, pfs_zero,
+   0);
+   }
+   emit_arith(rp, PFS_OP_DP3, temp,
+   WRITEMASK_XYZ,
+   src0,
+  

[Bug 5422] i915: ARB_f_p local parameters don't always take effect

2006-01-06 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=5422  
 

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2006-01-05 21:56 ---
I've added a test program for the basic ProgramLocalParam functionality to
Mesa/progs/fp.  The test works fine as far as I can tell, so I'm going to close
the bug.  Please reopen and upload a test program if you still have a problem.  

 
 
--   
Configure bugmail: https://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: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [r300] Fragment program ops + questions

2006-01-06 Thread Ben Skeggs
Am Freitag, den 06.01.2006, 17:22 +0100 schrieb Rune Petersen:
 - Missing Commit from r300.sf.net:
 When trying to Implement the KIL ops I found a commit by Ben Skeggs on 
 r300.sf.net that was lost in the Mesa tree:
 
 http://sourceforge.net/mailarchive/forum.php?thread_id=7728162forum_id=42268
 
 At the very least the changes for r300_reg.h should be included in Mesa.
That commit fixed quite a few issues, and added all the remaining
opcodes with the exception of the trig opcodes, and LIT.  Though, there
are a few things I'd like to clean up in that code soon.  Also, The
depth-write support in there didn't work at all if I recall.

 
 - whats with the DP3 op?
 
   if (fpi-DstReg.WriteMask  WRITEMASK_W) {
   /* I assume these need to share the same alu slot */
   sync_streams(rp);
   emit_arith(rp, PFS_OP_DP4, dest, WRITEMASK_W,
   pfs_zero, pfs_zero, pfs_zero,
   flags);
   }
   emit_arith(rp, PFS_OP_DP3, t_dst(rp, fpi-DstReg),
   fpi-DstReg.WriteMask  WRITEMASK_XYZ,
   t_src(rp, fpi-SrcReg[0]),
   t_src(rp, fpi-SrcReg[1]),
   pfs_zero, flags);
Okay, if I recall this properly, it would appear to be correct.  Though,
some other parts of the code in Mesa CVS may cause it to fail in some
circumstances.  In my tests, the code from r300.sf.net CVS seemed to
produce the correct output for DP3.

 
 Why is DP4 called for W and why does DP3 excluding W?
The programmable fragment unit on r300 is split into two separate units.
One of them performs operations on the XYZ components of a register, the
other on the W component.  However, there needs to be interaction
between the two units.  An ALU instruction looks roughly like this:

FPI0: XYZ opcode + input swizzling
FPI1: XYZ register selection (inputs and output)
FPI2: W opcode + input swizzling
FPI3: W register selection (inputs and output)

So, when you tell r300 to perform a DP4 operation in the W unit.  It
takes the XYZ components from the registers mentioned in FPI1, and the W
component from the registers mentioned in FPI3.

Thus, you get the following for the DP4 in the code fragment above:
dot = (X from FPI1) + (Y from FPI1) + (Z from FPI1) + (W from FPI3)
= (X from FPI1) + (Y from FPI1) + (Z from FPI1) + (0 * 0)
.. because all FPI3 is pfs_zero...^^^
= the same result as the DP3 in the XYZ unit.

That's also why the DP3 and DP4 are forced into the same ALU slot as per
the comment.  It made register selection a little easier to deal with.

Sorry for the bad explanation, and some of it is possibly incorrect.
It's been a while since I looked at it.  For even more information,
check out the comments in r300_reg.h above the fragment program stuff,
it explains this a little more in depth.

Cheers,
Ben Skeggs.

 I don't see how it can conform to the specs:
 
tmp0 = VectorLoad(op0);
tmp1 = VectorLoad(op1);
dot = (tmp0.x * tmp1.x) + (tmp0.y * tmp1.y) + (tmp0.z * tmp1.z);
result.x = dot;
result.y = dot;
result.z = dot;
result.w = dot;


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 5459] Quake 4 darkness

2006-01-06 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=5459  
 




--- Additional Comments From [EMAIL PROTECTED]  2006-01-05 21:00 ---
I'm not able to test this myself on r300 hardware currently.  How does the test
case fail? ie. complete blackness, or just the wrong image?

Also, are you able to turn on the dump_program() call at the end of
translate_fragment_shader() and post the output please?  
 
 
--   
Configure bugmail: https://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: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 2418] Lockup using linux-core on radeon

2006-01-06 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=2418  
 




--- Additional Comments From [EMAIL PROTECTED]  2006-01-04 20:41 ---
Created an attachment (id=4236)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=4236action=view)
Proposed fix

Looks like this might do the trick (thanks OgreBoy !)
  
 
 
--   
Configure bugmail: https://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: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 5459] Quake 4 darkness

2006-01-06 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=5459  
 




--- Additional Comments From [EMAIL PROTECTED]  2006-01-07 05:04 ---
Okay, the disassembly of the fragment program doesn't turn up any obvious
mistakes in the program generation.

I'll try and convince Xorg to play nice with radeon again on Sunday and take a
closer look.  
 
 
--   
Configure bugmail: https://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: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 5531] New: DRI enabled freezes X when running any opengl app

2006-01-06 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=5531  
 
   Summary: DRI enabled freezes X when running any opengl app
   Product: DRI
   Version: unspecified
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: General
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]


Hi, 
   
I have an ATI Radeon Mobility 16MB on a Thinkpad T30, when I enable DRI and 
run any app that needs acceleration X freezes, even when running glxgears. 
This has happened since xorg 6.7. At the moment I'm using 6.9.  
 
 
--   
Configure bugmail: https://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: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 5297] Udev appears to create, rename and remove the device /dev/vcc/a7

2006-01-06 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=5297  
 

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-01-07 07:55 ---
i don't see what this has to do with DRI...  
 
 
--   
Configure bugmail: https://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: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: ATI AIW Radeon 9800 Pro - LockUp

2006-01-06 Thread Adam K Kirchhoff

Benjamin Herrenschmidt wrote:


On Thu, 2006-01-05 at 11:05 +0100, Jerome Glisse wrote:
 


On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
   


On Thu, 2006-01-05 at 02:30 +0100, Jerome Glisse wrote:
 


On 1/5/06, Jon [EMAIL PROTECTED] wrote:
   


I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing
with r300 DRI module. I tried Quake3 (wont get past beginning of opening
game video, locks computer solid) and Xmoto (lasts for a few seconds
than computer locks) GLXGears runs fine and for a long time, no
freezing. (10755 frames in 5.0 sec = 2151 FPS etc) I'm using FreeBSD 6.0
Stable, I just built from cvs at freedesktop.org Mesa3D ,DRM kernel
module and the r300 DRI module.
Is their anything I can test or do?
-- Thanks
 


I have been trying to track down the issue during last few month.
No success so far, maybe i am not a good hunter ;). Anyway could
you test to first run an xserver with fglrx (no need for the drm module)
and then run a server with r300 and see if you still have lockup
(you shouldn't) thus i know you probably face the same lockup as
i do.
   


Have you tried checking what's going on with the card memory map ?
(values of MC_AGP_LOCATION, MC_FB_LOCATION, CONFIG_MEMSIZE,
CONFIG_APER_SIZE, HDP control and how they are munged by X and DRI ?
There is definitely a bug or two lurking around when we have
CONFIG_APER_SIZE smaller than CONFIG_MEMSIZE that might be causing those
lockups).
 


So far i have quite ignored such things. I will take a closer look
to that, i haven't even tested your patch on that. I will give it
a try.
   



You may have to hack the kernel DRM too so that it puts the same values
in there, currently, it's broken too.

Ben.

 



Is it safe to say that this is only a problem for cards with 256 bit 
memory interfaces?  From http://en.wikipedia.org/wiki/Radeon_9700_core:


Radeon 9700 275 256-bit
Radeon 9800 325 256-bit
Radeon 9700 Pro 325 256-bit
Radeon 9800 Pro 380 256-bit
Radeon 9800 XT  412 256-bit


Do all these experience the same lockups?

Then with the X300 - X850, I think it's only the X800 and X850 cards 
have 256-bit interfaces, correct?  Do X800 cards experience the same 
lockups?


Adam



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: ATI AIW Radeon 9800 Pro - LockUp

2006-01-06 Thread Alex Deucher
On 1/6/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote:
 Benjamin Herrenschmidt wrote:

 On Thu, 2006-01-05 at 11:05 +0100, Jerome Glisse wrote:
 
 
 On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
 
 
 On Thu, 2006-01-05 at 02:30 +0100, Jerome Glisse wrote:
 
 
 On 1/5/06, Jon [EMAIL PROTECTED] wrote:
 
 
 I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing
 with r300 DRI module. I tried Quake3 (wont get past beginning of opening
 game video, locks computer solid) and Xmoto (lasts for a few seconds
 than computer locks) GLXGears runs fine and for a long time, no
 freezing. (10755 frames in 5.0 sec = 2151 FPS etc) I'm using FreeBSD 6.0
 Stable, I just built from cvs at freedesktop.org Mesa3D ,DRM kernel
 module and the r300 DRI module.
 Is their anything I can test or do?
 -- Thanks
 
 
 I have been trying to track down the issue during last few month.
 No success so far, maybe i am not a good hunter ;). Anyway could
 you test to first run an xserver with fglrx (no need for the drm module)
 and then run a server with r300 and see if you still have lockup
 (you shouldn't) thus i know you probably face the same lockup as
 i do.
 
 
 Have you tried checking what's going on with the card memory map ?
 (values of MC_AGP_LOCATION, MC_FB_LOCATION, CONFIG_MEMSIZE,
 CONFIG_APER_SIZE, HDP control and how they are munged by X and DRI ?
 There is definitely a bug or two lurking around when we have
 CONFIG_APER_SIZE smaller than CONFIG_MEMSIZE that might be causing those
 lockups).
 
 
 So far i have quite ignored such things. I will take a closer look
 to that, i haven't even tested your patch on that. I will give it
 a try.
 
 
 
 You may have to hack the kernel DRM too so that it puts the same values
 in there, currently, it's broken too.
 
 Ben.
 
 
 

 Is it safe to say that this is only a problem for cards with 256 bit
 memory interfaces?  From http://en.wikipedia.org/wiki/Radeon_9700_core:

 Radeon 9700 275 256-bit
 Radeon 9800 325 256-bit
 Radeon 9700 Pro 325 256-bit
 Radeon 9800 Pro 380 256-bit
 Radeon 9800 XT  412 256-bit


 Do all these experience the same lockups?

I think 9500s have the same problem.


 Then with the X300 - X850, I think it's only the X800 and X850 cards
 have 256-bit interfaces, correct?  Do X800 cards experience the same
 lockups?


no problems on my pcie x800

Alex

 Adam





---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: ATI AIW Radeon 9800 Pro - LockUp

2006-01-06 Thread Rune Petersen

Adam K Kirchhoff wrote:
Then with the X300 - X850, I think it's only the X800 and X850 cards 
have 256-bit interfaces, correct?  Do X800 cards experience the same 
lockups?


My X800 XT is working fine, the only real problem I have with lockups 
are with Quake 3 and is unrelated.



Rune Petersen


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: ATI AIW Radeon 9800 Pro - LockUp

2006-01-06 Thread Adam K Kirchhoff

Alex Deucher wrote:


On 1/6/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote:
 


Benjamin Herrenschmidt wrote:

   


On Thu, 2006-01-05 at 11:05 +0100, Jerome Glisse wrote:


 


On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:


   


On Thu, 2006-01-05 at 02:30 +0100, Jerome Glisse wrote:


 


On 1/5/06, Jon [EMAIL PROTECTED] wrote:


   


I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing
with r300 DRI module. I tried Quake3 (wont get past beginning of opening
game video, locks computer solid) and Xmoto (lasts for a few seconds
than computer locks) GLXGears runs fine and for a long time, no
freezing. (10755 frames in 5.0 sec = 2151 FPS etc) I'm using FreeBSD 6.0
Stable, I just built from cvs at freedesktop.org Mesa3D ,DRM kernel
module and the r300 DRI module.
Is their anything I can test or do?
-- Thanks


 


I have been trying to track down the issue during last few month.
No success so far, maybe i am not a good hunter ;). Anyway could
you test to first run an xserver with fglrx (no need for the drm module)
and then run a server with r300 and see if you still have lockup
(you shouldn't) thus i know you probably face the same lockup as
i do.


   


Have you tried checking what's going on with the card memory map ?
(values of MC_AGP_LOCATION, MC_FB_LOCATION, CONFIG_MEMSIZE,
CONFIG_APER_SIZE, HDP control and how they are munged by X and DRI ?
There is definitely a bug or two lurking around when we have
CONFIG_APER_SIZE smaller than CONFIG_MEMSIZE that might be causing those
lockups).


 


So far i have quite ignored such things. I will take a closer look
to that, i haven't even tested your patch on that. I will give it
a try.


   


You may have to hack the kernel DRM too so that it puts the same values
in there, currently, it's broken too.

Ben.



 


Is it safe to say that this is only a problem for cards with 256 bit
memory interfaces?  From http://en.wikipedia.org/wiki/Radeon_9700_core:

Radeon 9700 275 256-bit
Radeon 9800 325 256-bit
Radeon 9700 Pro 325 256-bit
Radeon 9800 Pro 380 256-bit
Radeon 9800 XT  412 256-bit


Do all these experience the same lockups?
   



I think 9500s have the same problem.

 


I have a 9550 which doesn't experience the lockups.


Then with the X300 - X850, I think it's only the X800 and X850 cards
have 256-bit interfaces, correct?  Do X800 cards experience the same
lockups?

   



no problems on my pcie x800

 



Oh well...  Thought I saw a pattern.

Adam




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: ATI AIW Radeon 9800 Pro - LockUp

2006-01-06 Thread Benjamin Herrenschmidt

 Is it safe to say that this is only a problem for cards with 256 bit 
 memory interfaces?  From http://en.wikipedia.org/wiki/Radeon_9700_core:
 
 Radeon 9700   275 256-bit
 Radeon 9800   325 256-bit
 Radeon 9700 Pro   325 256-bit
 Radeon 9800 Pro   380 256-bit
 Radeon 9800 XT412 256-bit
 
 
 Do all these experience the same lockups?
 
 Then with the X300 - X850, I think it's only the X800 and X850 cards 
 have 256-bit interfaces, correct?  Do X800 cards experience the same 
 lockups?

Interesting... could be a bandwidth setting issue too then.

Ben.




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: ATI AIW Radeon 9800 Pro - LockUp

2006-01-06 Thread Alex Deucher
On 1/6/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote:
 Alex Deucher wrote:

 On 1/6/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote:
 
 
 Benjamin Herrenschmidt wrote:
 
 
 
 On Thu, 2006-01-05 at 11:05 +0100, Jerome Glisse wrote:
 
 
 
 
 On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
 
 
 
 
 On Thu, 2006-01-05 at 02:30 +0100, Jerome Glisse wrote:
 
 
 
 
 On 1/5/06, Jon [EMAIL PROTECTED] wrote:
 
 
 
 
 I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing
 with r300 DRI module. I tried Quake3 (wont get past beginning of 
 opening
 game video, locks computer solid) and Xmoto (lasts for a few seconds
 than computer locks) GLXGears runs fine and for a long time, no
 freezing. (10755 frames in 5.0 sec = 2151 FPS etc) I'm using FreeBSD 
 6.0
 Stable, I just built from cvs at freedesktop.org Mesa3D ,DRM kernel
 module and the r300 DRI module.
 Is their anything I can test or do?
 -- Thanks
 
 
 
 
 I have been trying to track down the issue during last few month.
 No success so far, maybe i am not a good hunter ;). Anyway could
 you test to first run an xserver with fglrx (no need for the drm module)
 and then run a server with r300 and see if you still have lockup
 (you shouldn't) thus i know you probably face the same lockup as
 i do.
 
 
 
 
 Have you tried checking what's going on with the card memory map ?
 (values of MC_AGP_LOCATION, MC_FB_LOCATION, CONFIG_MEMSIZE,
 CONFIG_APER_SIZE, HDP control and how they are munged by X and DRI ?
 There is definitely a bug or two lurking around when we have
 CONFIG_APER_SIZE smaller than CONFIG_MEMSIZE that might be causing those
 lockups).
 
 
 
 
 So far i have quite ignored such things. I will take a closer look
 to that, i haven't even tested your patch on that. I will give it
 a try.
 
 
 
 
 You may have to hack the kernel DRM too so that it puts the same values
 in there, currently, it's broken too.
 
 Ben.
 
 
 
 
 
 Is it safe to say that this is only a problem for cards with 256 bit
 memory interfaces?  From http://en.wikipedia.org/wiki/Radeon_9700_core:
 
 Radeon 9700 275 256-bit
 Radeon 9800 325 256-bit
 Radeon 9700 Pro 325 256-bit
 Radeon 9800 Pro 380 256-bit
 Radeon 9800 XT  412 256-bit
 
 
 Do all these experience the same lockups?
 
 
 
 I think 9500s have the same problem.
 
 
 
 I have a 9550 which doesn't experience the lockups.

the 9550 is actually a stripped down 9600 based chip.  the original
9500s were more like the 9700s.

Alex


 Then with the X300 - X850, I think it's only the X800 and X850 cards
 have 256-bit interfaces, correct?  Do X800 cards experience the same
 lockups?
 
 
 
 
 no problems on my pcie x800
 
 
 

 Oh well...  Thought I saw a pattern.

 Adam





---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: ATI AIW Radeon 9800 Pro - LockUp

2006-01-06 Thread Jerome Glisse
On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 Have you tried checking what's going on with the card memory map ?
 (values of MC_AGP_LOCATION, MC_FB_LOCATION, CONFIG_MEMSIZE,
 CONFIG_APER_SIZE, HDP control and how they are munged by X and DRI ?
 There is definitely a bug or two lurking around when we have
 CONFIG_APER_SIZE smaller than CONFIG_MEMSIZE that might be causing those
 lockups).

It seems to be related to card memory map, with your patch
(radeon mem fix) i have no lockups (at least no during last
10 minutes) but as i update many things and have tweaks
in many place i will double check that...

In the mean time if more people could test with your patch
(even if their regression with it on some hardware) see if
this fix the lockup for them.

I will also take a closer look at fglrx dump on this configuration.

best,
Jerome Glisse


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: ATI AIW Radeon 9800 Pro - LockUp

2006-01-06 Thread Jerome Glisse
On 1/7/06, Jerome Glisse [EMAIL PROTECTED] wrote:
 On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
 
  Have you tried checking what's going on with the card memory map ?
  (values of MC_AGP_LOCATION, MC_FB_LOCATION, CONFIG_MEMSIZE,
  CONFIG_APER_SIZE, HDP control and how they are munged by X and DRI ?
  There is definitely a bug or two lurking around when we have
  CONFIG_APER_SIZE smaller than CONFIG_MEMSIZE that might be causing those
  lockups).

 It seems to be related to card memory map, with your patch
 (radeon mem fix) i have no lockups (at least no during last
 10 minutes) but as i update many things and have tweaks
 in many place i will double check that...

 In the mean time if more people could test with your patch
 (even if their regression with it on some hardware) see if
 this fix the lockup for them.

More people testing benh patch on radeon 9800 (or any other
radeon that used to lockup) are welcome:

http://lists.freedesktop.org/archives/xorg/2005-December/011679.html
http://lists.freedesktop.org/archives/xorg/2005-December/011717.html

It really seems to fix it. I have been on ut2004 for several minutes
without a lockups while it used lockup pretty fast the card before.
I will give a look a fglrx way to setup all this.

best,
Jerome Glisse


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: ATI AIW Radeon 9800 Pro - LockUp

2006-01-06 Thread Benjamin Herrenschmidt

 More people testing benh patch on radeon 9800 (or any other
 radeon that used to lockup) are welcome:
 
 http://lists.freedesktop.org/archives/xorg/2005-December/011679.html
 http://lists.freedesktop.org/archives/xorg/2005-December/011717.html
 
 It really seems to fix it. I have been on ut2004 for several minutes
 without a lockups while it used lockup pretty fast the card before.
 I will give a look a fglrx way to setup all this.

Again, you really want to also check what the kernel DRI does though as
it may stomp over your settings. There are lurking bugs in both sides
(which is why I can't merge those patches as-is). I'll work on an
attempt at fixing both sides soon.

Ben.




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: ATI AIW Radeon 9800 Pro - LockUp

2006-01-06 Thread Boris Peterbarg

Jerome Glisse wrote:

On 1/7/06, Jerome Glisse [EMAIL PROTECTED] wrote:


On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:


Have you tried checking what's going on with the card memory map ?
(values of MC_AGP_LOCATION, MC_FB_LOCATION, CONFIG_MEMSIZE,
CONFIG_APER_SIZE, HDP control and how they are munged by X and DRI ?
There is definitely a bug or two lurking around when we have
CONFIG_APER_SIZE smaller than CONFIG_MEMSIZE that might be causing those
lockups).


It seems to be related to card memory map, with your patch
(radeon mem fix) i have no lockups (at least no during last
10 minutes) but as i update many things and have tweaks
in many place i will double check that...

In the mean time if more people could test with your patch
(even if their regression with it on some hardware) see if
this fix the lockup for them.



More people testing benh patch on radeon 9800 (or any other
radeon that used to lockup) are welcome:

http://lists.freedesktop.org/archives/xorg/2005-December/011679.html
http://lists.freedesktop.org/archives/xorg/2005-December/011717.html

It really seems to fix it. I have been on ut2004 for several minutes
without a lockups while it used lockup pretty fast the card before.
I will give a look a fglrx way to setup all this.

best,
Jerome Glisse

A bit late to the discussion, but I have a radeon 9800 pro and with r300 
and no ati drivers it works really great for a couple of hours straight 
inside some 3d games.

...
Then it locks up.
I don't think a 10 minute test is enough. People don't use 3d programs, 
and especially not games for 10 minutes.
I didn't try the patch yet. I'll try it sometime during the week and 
report what happens.


Boris Peterbarg


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel