[Bug 7178] Mesa 1.5, i810 1.6.0 and xorg-server 1.1.0 crash for any GLX app
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=7178 --- Additional Comments From [EMAIL PROTECTED] 2006-06-11 03:00 --- Weird, the X driver says direct rendering enabled, but AIGLX says it's not. Does LIBGL_DEBUG=verbose glxinfo give any interesting output? -- 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. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Doom3 causes VBO leak
Tilman Sauerbeck [2006-05-22 19:42]:
[...]
I found out that the buffer in question was allocated by
r300BufferData(). Now, the proper call to radeon_mm_free() would have
been made by r300DeleteBuffer(), but that function was never called.
From looking at the code I think this means that it's an application
error.
Now the question is, should Mesa call the DeleteBuffer callback for
all buffers that are still alive when the context is destroyed or should
r300 be able to cope with it the way it currently is?
Here's a patch that deletes all VBOs that are still alive when the
context is destroyed.
Because r300DeleteBuffer() calls radeon_mm_free(), which depends on
ctx-DriverCtx, we now cannot set DriverCtx to NULL before destroying
the Mesa context however.
Is this a problem? There's lots of driver calls in free_share_state()
that might depend on DriverCtx not being NULL, so I don't think I'm
adding new evil code here.
Comments?
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
? progs/vp/arbvptorus.c
? progs/vp/vp-tris
Index: src/mesa/drivers/dri/r300/r300_context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.c,v
retrieving revision 1.54
diff -u -p -r1.54 r300_context.c
--- src/mesa/drivers/dri/r300/r300_context.c11 Jun 2006 09:12:27 -
1.54
+++ src/mesa/drivers/dri/r300/r300_context.c11 Jun 2006 10:31:35 -
@@ -385,8 +385,12 @@ static void r300FreeGartAllocations(r300
if (r300-rmm-u_list[i].ptr == NULL) {
continue;
}
-
- assert(r300-rmm-u_list[i].pending);
+
+ /* check whether this buffer is still in use */
+ if (!r300-rmm-u_list[i].pending) {
+ continue;
+ }
+
assert(r300-rmm-u_list[i].h_pending == 0);
tries = 0;
Index: src/mesa/drivers/dri/r300/radeon_context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/radeon_context.c,v
retrieving revision 1.12
diff -u -p -r1.12 radeon_context.c
--- src/mesa/drivers/dri/r300/radeon_context.c 2 Jun 2006 01:52:54 -
1.12
+++ src/mesa/drivers/dri/r300/radeon_context.c 11 Jun 2006 10:31:36 -
@@ -202,9 +202,13 @@ GLboolean radeonInitContext(radeonContex
void radeonCleanupContext(radeonContextPtr radeon)
{
/* free the Mesa context */
- radeon-glCtx-DriverCtx = NULL;
_mesa_destroy_context(radeon-glCtx);
+ /* the above call might result in calls to functions that depend on
+* the DriverCtx.
+*/
+ radeon-glCtx-DriverCtx = NULL;
+
if (radeon-state.scissor.pClipRects) {
FREE(radeon-state.scissor.pClipRects);
radeon-state.scissor.pClipRects = 0;
Index: src/mesa/main/context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/main/context.c,v
retrieving revision 1.276
diff -u -p -r1.276 context.c
--- src/mesa/main/context.c 15 May 2006 15:26:04 - 1.276
+++ src/mesa/main/context.c 11 Jun 2006 10:31:40 -
@@ -887,6 +887,20 @@ free_shared_state( GLcontext *ctx, struc
#endif
#if FEATURE_ARB_vertex_buffer_object
+ /* Free vertex buffer objects */
+ while (1) {
+ GLuint name = _mesa_HashFirstEntry(ss-BufferObjects);
+ if (name) {
+ struct gl_buffer_object *bufObj = (struct gl_buffer_object *)
+_mesa_HashLookup(ss-BufferObjects, name);
+ ASSERT(bufObj);
+ ctx-Driver.DeleteBuffer(ctx, bufObj);
+ _mesa_HashRemove(ss-BufferObjects, name);
+ }
+ else {
+ break;
+ }
+ }
_mesa_DeleteHashTable(ss-BufferObjects);
#endif
pgpp3FXHtlOgv.pgp
Description: PGP signature
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
On 6/11/06, Rune Petersen [EMAIL PROTECTED] wrote: Another thing: I think we need an up-to-date list of what is working and what is still missing. I have a small list for my own enjoyment, but it is far from complete: http://megahurts.dk/rune/r300_status.html Yes such things is usefull. Between i already done individual component swizzling for fragment program. I got few others things pending that i need to finish on fragment program... Jerome Glisse -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6677] New: radeon driver with mobility radeon X600 SE
http://bugzilla.kernel.org/show_bug.cgi?id=6677 Summary: radeon driver with mobility radeon X600 SE Kernel Version: 2.6.17-rc6 Status: NEW Severity: low Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: Distribution: ubuntu 6.06 dapper drake Hardware Environment: ASUS M9V (ATI mobility radeon X600 SE) Software Environment: X 7.0.0, drm 1.0.1 20051102, radeon 1.24.0 20060225, DRI library 1.2.0 Problem Description: In Xorg.0.log, the driver recognizes the chip, but there's a message Unknown ID 5462, please report. Assuming plain R300. output to standard error. Despite this, it works fine. Steps to reproduce: --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Jerome Glisse wrote: On 6/11/06, Rune Petersen [EMAIL PROTECTED] wrote: Another thing: I think we need an up-to-date list of what is working and what is still missing. I have a small list for my own enjoyment, but it is far from complete: http://megahurts.dk/rune/r300_status.html Yes such things is usefull. Between i already done individual component swizzling for fragment program. I got few others things pending that i need to finish on fragment program... Great, Just remember to update the TODO in fragprog.c. Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
Aapo Tahkola wrote: On Wed, 07 Jun 2006 17:49:00 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Wed, 07 Jun 2006 10:51:08 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sat, 3 Jun 2006 05:04:04 +0200 Jacek Poplawski [EMAIL PROTECTED] wrote: I am trying to run http://maniadrive.raydium.org/ on Radeon 9800 with Mesa CVS. 3D view in the menu background works, but when I want to play I see: *WARN_ONCE* File r300_vertexprog.c function r300_translate_vertex_shader line 564 Ran out of temps, num temps 13, us 12 *** Can the driver only use 13 temps natively? I was under the impression that there was 32 or 64 vertex temps. r300 - r480 only have 14. A good optimizer can make sure that the limits are never really hit. Ok, but How do you find there numbers? I can only find reports like this (X850: 32 vp temps): http://www.delphi3d.net/hardware/viewreport.php?report=1412 Remove fallback, craft test app that uses 15 temps and see if it works. Be aware though that you need to beat it hard to get reliable results. I guess there's some capacitance in the circuits... I found the 3dsmax viewset in SPECViewperf 8.1 which uses 15 temps. increasing the temps count to 15 I can run the viewset multiple times without lockup or visible errors. I think the safest safest way is to set it to 15 and if an app hits the fallback do a test to see if the app can run without fallback. Rune Petersen Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Kernel lockup when starting second X on MGA G200
Hello, As the subject mentions I seem to get a kernel lockup when starting a second X on a Matrox G200 card under Fedora Core 5. I have filed bugs with logs here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193854 and here: https://bugs.freedesktop.org/show_bug.cgi?id=7173 In the RH bugzilla Mike Harris suggested that I should also cc the DRI folks just in case it was a kernel bug. -- Sitsofe | http://sucs.org/~sits/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7178] Mesa 1.5, i810 1.6.0 and xorg-server 1.1.0 crash for any GLX app
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=7178 --- Additional Comments From [EMAIL PROTECTED] 2006-06-11 12:48 --- [EMAIL PROTECTED] ~ $ LIBGL_DEBUG=verbose glxinfo name of display: :0.0 X connection to :0.0 broken (explicit kill or server shutdown). and that's inside of a screen session so I'd have the output after X crashed. I have mesa xorg-server both compiled with debug turned on. Any other packages I need with the debug information to find what you are looking for? -- 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. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
On Sun, 11 Jun 2006 15:01:15 +0200
Rune Petersen [EMAIL PROTECTED] wrote:
Aapo Tahkola wrote:
On Wed, 07 Jun 2006 17:49:00 +0200
Rune Petersen [EMAIL PROTECTED] wrote:
Aapo Tahkola wrote:
On Wed, 07 Jun 2006 10:51:08 +0200
Rune Petersen [EMAIL PROTECTED] wrote:
Aapo Tahkola wrote:
On Sat, 3 Jun 2006 05:04:04 +0200
Jacek Poplawski [EMAIL PROTECTED] wrote:
I am trying to run http://maniadrive.raydium.org/ on Radeon
9800 with Mesa CVS.
3D view in the menu background works, but when I want to play I
see:
*WARN_ONCE*
File r300_vertexprog.c function r300_translate_vertex_shader
line 564 Ran out of temps, num temps 13, us 12
***
Can the driver only use 13 temps natively?
I was under the impression that there was 32 or 64 vertex temps.
r300 - r480 only have 14. A good optimizer can make sure that the
limits are never really hit.
Ok, but How do you find there numbers?
I can only find reports like this (X850: 32 vp temps):
http://www.delphi3d.net/hardware/viewreport.php?report=1412
Remove fallback, craft test app that uses 15 temps and see if it
works. Be aware though that you need to beat it hard to get
reliable results. I guess there's some capacitance in the
circuits...
I found the 3dsmax viewset in SPECViewperf 8.1 which uses 15 temps.
increasing the temps count to 15 I can run the viewset multiple times
without lockup or visible errors.
I think the safest safest way is to set it to 15 and if an app hits
the fallback do a test to see if the app can run without fallback.
Try this.
It should start working again when you move MOV R14, R0; more
closer to the instruction that reads R14.
--
Aapo Tahkola
/*
* A lit, rotating torus via vertex program
*/
#include assert.h
#include string.h
#include stdio.h
#include stdlib.h
#include math.h
#define GL_GLEXT_PROTOTYPES
#include GL/glut.h
static float Xrot = 0.0, Yrot = 0.0, Zrot = 0.0;
static GLboolean Anim = GL_TRUE;
static void Idle( void )
{
Xrot += .3;
Yrot += .4;
Zrot += .2;
glutPostRedisplay();
}
static void Display( void )
{
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
glPushMatrix();
glRotatef(Xrot, 1, 0, 0);
glRotatef(Yrot, 0, 1, 0);
glRotatef(Zrot, 0, 0, 1);
glutSolidTorus(0.75, 2.0, 10, 20);
glPopMatrix();
glutSwapBuffers();
}
static void Reshape( int width, int height )
{
glViewport( 0, 0, width, height );
glMatrixMode( GL_PROJECTION );
glLoadIdentity();
glFrustum( -2.0, 2.0, -2.0, 2.0, 5.0, 25.0 );
glMatrixMode( GL_MODELVIEW );
glLoadIdentity();
glTranslatef( 0.0, 0.0, -12.0 );
}
static void Key( unsigned char key, int x, int y )
{
(void) x;
(void) y;
switch (key) {
case ' ':
Xrot = Yrot = Zrot = 0;
break;
case 'a':
Anim = !Anim;
if (Anim)
glutIdleFunc(Idle);
else
glutIdleFunc(NULL);
break;
case 'z':
Zrot -= 5.0;
break;
case 'Z':
Zrot += 5.0;
break;
case 27:
exit(0);
break;
}
glutPostRedisplay();
}
static void SpecialKey( int key, int x, int y )
{
const GLfloat step = 3.0;
(void) x;
(void) y;
switch (key) {
case GLUT_KEY_UP:
Xrot -= step;
break;
case GLUT_KEY_DOWN:
Xrot += step;
break;
case GLUT_KEY_LEFT:
Yrot -= step;
break;
case GLUT_KEY_RIGHT:
Yrot += step;
break;
}
glutPostRedisplay();
}
static void Init( void )
{
GLint errno;
GLuint prognum;
/* borrowed from an nvidia demo:
* c[0..3] = modelview matrix
* c[4..7] = invtrans modelview matrix
* c[32] = light pos
* c[35] = diffuse color
*/
static const char prog[] =
!!ARBvp1.0\n
TEMP R0, R1; \n
TEMP R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15; \n
#Simple transform and diffuse lighting\n
# object x MVP - clip\n
DP4 result.position.x, state.matrix.mvp.row[0], vertex.position ;\n
DP4 result.position.y, state.matrix.mvp.row[1], vertex.position ;\n
DP4 result.position.z, state.matrix.mvp.row[2], vertex.position ;\n
DP4 result.position.w, state.matrix.mvp.row[3], vertex.position ;\n
# normal x MV-1T - lighting normal\n
DP3 R1.x, state.matrix.modelview.invtrans.row[0], vertex.normal ;\n
DP3 R1.y, state.matrix.modelview.invtrans.row[1], vertex.normal;\n
DP3 R1.z, state.matrix.modelview.invtrans.row[2], vertex.normal;\n
DP3 R0, program.local[32], R1; # L.N\n
#if 0
MUL result.color.xyz, R0, program.local[35] ; # col = L.N * diffuse\n
#else
MOV R14, R0;\n
MOV R2, vertex.position;\n
MOV R3, vertex.position;\n
Re: how to disable vertex programs?
Aapo Tahkola wrote: On Sun, 11 Jun 2006 15:01:15 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Wed, 07 Jun 2006 17:49:00 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Wed, 07 Jun 2006 10:51:08 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sat, 3 Jun 2006 05:04:04 +0200 Jacek Poplawski [EMAIL PROTECTED] wrote: I am trying to run http://maniadrive.raydium.org/ on Radeon 9800 with Mesa CVS. 3D view in the menu background works, but when I want to play I see: *WARN_ONCE* File r300_vertexprog.c function r300_translate_vertex_shader line 564 Ran out of temps, num temps 13, us 12 *** Can the driver only use 13 temps natively? I was under the impression that there was 32 or 64 vertex temps. r300 - r480 only have 14. A good optimizer can make sure that the limits are never really hit. Ok, but How do you find there numbers? I can only find reports like this (X850: 32 vp temps): http://www.delphi3d.net/hardware/viewreport.php?report=1412 Remove fallback, craft test app that uses 15 temps and see if it works. Be aware though that you need to beat it hard to get reliable results. I guess there's some capacitance in the circuits... I found the 3dsmax viewset in SPECViewperf 8.1 which uses 15 temps. increasing the temps count to 15 I can run the viewset multiple times without lockup or visible errors. I think the safest safest way is to set it to 15 and if an app hits the fallback do a test to see if the app can run without fallback. Try this. It should start working again when you move MOV R14, R0; more closer to the instruction that reads R14. Gave it a try: 23 or less instructions between the two MOV instructions and it works. Translates into VSF_MAX_FRAGMENT_TEMPS being 17. The card is an X800 XT. Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7189] New: Kernel hang on ACPI resume if X has been loaded (even after stopping X, and unloading the modules). Radeon 7000
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=7189 Summary: Kernel hang on ACPI resume if X has been loaded (even after stopping X, and unloading the modules). Radeon 7000 Product: DRI Version: XOrg 6.7.0 Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Here is a weird bug - not sure whether it is a kernel bug or an X bug. It really should be filed under Xorg 6.9.0, but this isn't listed as an option above. Basically, starting X, then stopping it, then doing an ACPI suspend fails to resume, IFF X has loaded drm. Here is the most useful set of experiments: TEST 1) Boot up with linux single. Very few modules are loaded. echo 3 /proc/acpi/sleep. It sleeps (and resumes) happily, and repeatedly. TEST 2) Restart, to avoid bias. Again, boot up with linux single. modprobe drm; modprobe radeon echo 3 /proc/acpi/sleep. It sleeps (and resumes) happily, and repeatedly. TEST 3) linux single modprobe drm; modprobe radeon startx STOP x [drm and radeon modules are automatically removed when X shuts down] echo 3 /proc/acpi/sleep Result: it suspends fine, but will not wake up! Pressing Fn-F4 spins up the HDD and CPU fan, but nothing else. TEST 4) Running X, but without the Load dri line is fine. Test 5) Running X, with load dri, AND with Mesa installed is fine. My conclusion is that something in Xorg does something to the graphics card which interferes with resume. Versions: Xorg: 6.9.0 Kernel: 2.6.12, or 2.6.16.20 Hardware: IBM Thinkpad X22, Rage 7000 card. (radeon driver) This does not happen with a Thinkpad A22p, with similar (Rage128) hardware. -- 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. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI + Radeon_Driver = Black screen (when startx)
On Fri, 9 Jun 2006 22:49:53 +0200 [EMAIL PROTECTED] wrote: Hi I have a probleme with the DRI : Ok, I have followed step to step the tutorial for build DRI and mesa?. So If I load in my xorg.conf ?the DRI and the radeon driver?, when I type startx there are a Black screen? and I can?t make a CTRL + ATL + DEL for shut down the X ? I must restart the PC?. But if I load in my xorg.conf ONLY driver radeon (without DRI) the startx work Ok there my xorg.conf: http://rapidshare.de/files/22461482/xorg.conf.txt.html According to your xorg.conf you are using vesa driver not ati. I think your xf86-video-ati and drm might be lacking benh's memory mapping fixes which could cause it to hang the card. Can you update xorg to 7.1? Setting GARTSize to some value might also prevent immediate lock, though it will not fix the problem entirely. -- Aapo Tahkola -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
On Mon, 12 Jun 2006 00:56:36 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sun, 11 Jun 2006 15:01:15 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Wed, 07 Jun 2006 17:49:00 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Wed, 07 Jun 2006 10:51:08 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sat, 3 Jun 2006 05:04:04 +0200 Jacek Poplawski [EMAIL PROTECTED] wrote: I am trying to run http://maniadrive.raydium.org/ on Radeon 9800 with Mesa CVS. 3D view in the menu background works, but when I want to play I see: *WARN_ONCE* File r300_vertexprog.c function r300_translate_vertex_shader line 564 Ran out of temps, num temps 13, us 12 *** Can the driver only use 13 temps natively? I was under the impression that there was 32 or 64 vertex temps. r300 - r480 only have 14. A good optimizer can make sure that the limits are never really hit. Ok, but How do you find there numbers? I can only find reports like this (X850: 32 vp temps): http://www.delphi3d.net/hardware/viewreport.php?report=1412 Remove fallback, craft test app that uses 15 temps and see if it works. Be aware though that you need to beat it hard to get reliable results. I guess there's some capacitance in the circuits... I found the 3dsmax viewset in SPECViewperf 8.1 which uses 15 temps. increasing the temps count to 15 I can run the viewset multiple times without lockup or visible errors. I think the safest safest way is to set it to 15 and if an app hits the fallback do a test to see if the app can run without fallback. Try this. It should start working again when you move MOV R14, R0; more closer to the instruction that reads R14. Gave it a try: 23 or less instructions between the two MOV instructions and it works. Translates into VSF_MAX_FRAGMENT_TEMPS being 17. The card is an X800 XT. You cannot count it based on how many instructions are between them, those are there just to increase the time that temp needs to hold its value before its read. You need to add and initialize new temps if you want to test higher temps. _mesa_print_program is probably useful. -- Aapo Tahkola -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
