glsl/link,i965: Make ImageAccess four-state

[mesa.git] / src / mesa / main / hash.c

diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c
index e352a46aa4bc2f8ee4caa7dc4e5767e6f37940f7..9a6d5ed5edbd1942c29dccd5dd5a93ca6c21328b 100644 (file)
--- a/src/mesa/main/hash.c
+++ b/src/mesa/main/hash.c
@@ -34,79 +34,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include "errors.h"
 #include "glheader.h"
-#include "imports.h"
 #include "hash.h"
 #include "util/hash_table.h"
 
-/**
- * Magic GLuint object name that gets stored outside of the struct hash_table.
- *
- * The hash table needs a particular pointer to be the marker for a key that
- * was deleted from the table, along with NULL for the "never allocated in the
- * table" marker.  Legacy GL allows any GLuint to be used as a GL object name,
- * and we use a 1:1 mapping from GLuints to key pointers, so we need to be
- * able to track a GLuint that happens to match the deleted key outside of
- * struct hash_table.  We tell the hash table to use "1" as the deleted key
- * value, so that we test the deleted-key-in-the-table path as best we can.
- */
-#define DELETED_KEY_VALUE 1
-
-/**
- * The hash table data structure.  
- */
-struct _mesa_HashTable {
-   struct hash_table *ht;
-   GLuint MaxKey;                        /**< highest key inserted so far */
-   mtx_t Mutex;                /**< mutual exclusion lock */
-   GLboolean InDeleteAll;                /**< Debug check */
-   /** Value that would be in the table for DELETED_KEY_VALUE. */
-   void *deleted_key_data;
-};
-
-/** @{
- * Mapping from our use of GLuint as both the key and the hash value to the
- * hash_table.h API
- *
- * There exist many integer hash functions, designed to avoid collisions when
- * the integers are spread across key space with some patterns.  In GL, the
- * pattern (in the case of glGen*()ed object IDs) is that the keys are unique
- * contiguous integers starting from 1.  Because of that, we just use the key
- * as the hash value, to minimize the cost of the hash function.  If objects
- * are never deleted, we will never see a collision in the table, because the
- * table resizes itself when it approaches full, and thus key % table_size ==
- * key.
- *
- * The case where we could have collisions for genned objects would be
- * something like: glGenBuffers(&a, 100); glDeleteBuffers(&a + 50, 50);
- * glGenBuffers(&b, 100), because objects 1-50 and 101-200 are allocated at
- * the end of that sequence, instead of 1-150.  So far it doesn't appear to be
- * a problem.
- */
-static bool
-uint_key_compare(const void *a, const void *b)
-{
-   return a == b;
-}
-
-static uint32_t
-uint_hash(GLuint id)
-{
-   return id;
-}
-
-static uint32_t
-uint_key_hash(const void *key)
-{
-   return uint_hash((uintptr_t)key);
-}
-
-static void *
-uint_key(GLuint id)
-{
-   return (void *)(uintptr_t) id;
-}
-/** @} */
 
 /**
  * Create a new hash table.
@@ -230,36 +162,6 @@ _mesa_HashLookupLocked(struct _mesa_HashTable *table, GLuint key)
 }
 
 
-/**
- * Lock the hash table mutex.
- *
- * This function should be used when multiple objects need
- * to be looked up in the hash table, to avoid having to lock
- * and unlock the mutex each time.
- *
- * \param table the hash table.
- */
-void
-_mesa_HashLockMutex(struct _mesa_HashTable *table)
-{
-   assert(table);
-   mtx_lock(&table->Mutex);
-}
-
-
-/**
- * Unlock the hash table mutex.
- *
- * \param table the hash table.
- */
-void
-_mesa_HashUnlockMutex(struct _mesa_HashTable *table)
-{
-   assert(table);
-   mtx_unlock(&table->Mutex);
-}
-
-
 static inline void
 _mesa_HashInsert_unlocked(struct _mesa_HashTable *table, GLuint key, void *data)
 {