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.c    11 Jun 2006 09:12:27 -0000      
1.54
+++ src/mesa/drivers/dri/r300/r300_context.c    11 Jun 2006 10:31:35 -0000
@@ -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 -0000       
1.12
+++ src/mesa/drivers/dri/r300/radeon_context.c  11 Jun 2006 10:31:36 -0000
@@ -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 -0000      1.276
+++ src/mesa/main/context.c     11 Jun 2006 10:31:40 -0000
@@ -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
 

Attachment: pgpp3FXHtlOgv.pgp
Description: PGP signature

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to