Lift region-related functions up to the pipe interface.

Some of these functions probably should be driver-private.
Note: intel_buffer_object is in p_state.h and should be fixed/removed.
There are just a few i915 dependencies in intel_region.c

1 files changed, 9 insertions, 5 deletions

diff --git a/src/mesa/drivers/dri/i915pipe/intel_mipmap_tree.h b/src/mesa/drivers/dri/i915pipe/intel_mipmap_tree.h
index ecdb7be244..09b2e362fc 100644
--- a/src/mesa/drivers/dri/i915pipe/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i915pipe/intel_mipmap_tree.h
@@ -28,14 +28,18 @@
 #ifndef INTEL_MIPMAP_TREE_H
 #define INTEL_MIPMAP_TREE_H
 
-#include "intel_regions.h"
+#include "intel_context.h"
+#include "main/glheader.h"
 
-/* A layer on top of the intel_regions code which adds:
+struct pipe_region;
+
+
+/* A layer on top of the pipe_regions code which adds:
  *
  * - Code to size and layout a region to hold a set of mipmaps.
  * - Query to determine if a new image fits in an existing tree.
  * - More refcounting 
- *     - maybe able to remove refcounting from intel_region?
+ *     - maybe able to remove refcounting from pipe_region?
  * - ?
  *
  * The fixed mipmap layout of intel hardware where one offset
@@ -45,7 +49,7 @@
  * independent offset.
  *
  * In an ideal world, each texture object would be associated with a
- * single bufmgr buffer or 2d intel_region, and all the images within
+ * single bufmgr buffer or 2d pipe_region, and all the images within
  * the texture object would slot into the tree as they arrive.  The
  * reality can be a little messier, as images can arrive from the user
  * with sizes that don't fit in the existing tree, or in an order
@@ -103,7 +107,7 @@ struct intel_mipmap_tree
 
    /* The data is held here:
     */
-   struct intel_region *region;
+   struct pipe_region *region;
 
    /* These are also refcounted:
     */