From: Rob Clark robclark@freedesktop.org
drmMalloc() is already calloc()
Signed-off-by: Rob Clark robclark@freedesktop.org --- Small micro-optimization that I noticed while doing some perf work.. I should probably look at promoting amdgpu's handle_table to core libdrm and replacing a couple of libdrm_freedreno's xf86drmHash tables over to that. There is still at least one hashtable (in some libdrm_freedreno patches I'm working on finalizing) where handle_table would not be appropriate (ie. key is a ptr).. but the answer there might be importing a better hashtable implementation into libdrm.
Related note, once I land a libdrm_freedreno patchset (hopefully tomorrow or over the weekend), I'll have interest in making a libdrm release so I can start landing mesa patches that will depend on that.. so if anyone else wants me to wait a few days so they can push something before the next libdrm release, please let me know.
xf86drmHash.c | 5 ----- 1 file changed, 5 deletions(-)
diff --git a/xf86drmHash.c b/xf86drmHash.c index b2fa414e..39900e7e 100644 --- a/xf86drmHash.c +++ b/xf86drmHash.c @@ -109,12 +109,7 @@ void *drmHashCreate(void) table = drmMalloc(sizeof(*table)); if (!table) return NULL; table->magic = HASH_MAGIC; - table->entries = 0; - table->hits = 0; - table->partials = 0; - table->misses = 0;
- for (i = 0; i < HASH_SIZE; i++) table->buckets[i] = NULL; return table; }
On Thursday, 2018-10-11 19:18:10 -0400, mesa-dev-bounces@lists.freedesktop.org wrote:
From: Rob Clark robclark@freedesktop.org
drmMalloc() is already calloc()
Sounds very much like an implementation detail, but everything relies on it already, so...
Reviewed-by: Eric Engestrom eric.engestrom@intel.com
Signed-off-by: Rob Clark robclark@freedesktop.org
Small micro-optimization that I noticed while doing some perf work.. I should probably look at promoting amdgpu's handle_table to core libdrm and replacing a couple of libdrm_freedreno's xf86drmHash tables over to that. There is still at least one hashtable (in some libdrm_freedreno patches I'm working on finalizing) where handle_table would not be appropriate (ie. key is a ptr).. but the answer there might be importing a better hashtable implementation into libdrm.
Related note, once I land a libdrm_freedreno patchset (hopefully tomorrow or over the weekend), I'll have interest in making a libdrm release so I can start landing mesa patches that will depend on that.. so if anyone else wants me to wait a few days so they can push something before the next libdrm release, please let me know.
xf86drmHash.c | 5 ----- 1 file changed, 5 deletions(-)
diff --git a/xf86drmHash.c b/xf86drmHash.c index b2fa414e..39900e7e 100644 --- a/xf86drmHash.c +++ b/xf86drmHash.c @@ -109,12 +109,7 @@ void *drmHashCreate(void) table = drmMalloc(sizeof(*table)); if (!table) return NULL; table->magic = HASH_MAGIC;
table->entries = 0;
table->hits = 0;
table->partials = 0;
table->misses = 0;
for (i = 0; i < HASH_SIZE; i++) table->buckets[i] = NULL; return table;
}
-- 2.17.1
mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, 12 Oct 2018 at 00:18, Rob Clark robdclark@gmail.com wrote:
From: Rob Clark robclark@freedesktop.org
drmMalloc() is already calloc()
Signed-off-by: Rob Clark robclark@freedesktop.org
For the patch Reviewed-by: Emil Velikov emil.velikov@collabora.com
Small micro-optimization that I noticed while doing some perf work.. I should probably look at promoting amdgpu's handle_table to core libdrm and replacing a couple of libdrm_freedreno's xf86drmHash tables over to that. There is still at least one hashtable (in some libdrm_freedreno patches I'm working on finalizing) where handle_table would not be appropriate (ie. key is a ptr).. but the answer there might be importing a better hashtable implementation into libdrm.
Please remember to nuke some of the existing hash implementations, if you want to add new one. The more (nuked) the better.
Related note, once I land a libdrm_freedreno patchset (hopefully tomorrow or over the weekend), I'll have interest in making a libdrm release so I can start landing mesa patches that will depend on that.. so if anyone else wants me to wait a few days so they can push something before the next libdrm release, please let me know.
There's nothing urgent on my end.
Thanks Emil
dri-devel@lists.freedesktop.org
-
Emil Velikov -
Eric Engestrom -
Rob Clark